Date: Wed, 12 Jun 2002 23:17:31 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Taylor <davidt@yadt.co.uk> Cc: freebsd-current@freebsd.org Subject: Re: looking for warn quota tools Message-ID: <3D0838FB.13B6DA3E@mindspring.com> References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> <3D0677C2.ED706536@mindspring.com> <20020613004244.GA89486@gattaca.yadt.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
David Taylor wrote:
> > FWIW: It's kind of a dumb idea to send email warning about a
> > condition which is caused by having too much email. We did
> > this on the InterJet, and it was actually a pretty dumb thing
> > to do; you end up with a recursive problem that's unsolvable
> > -- you basically have to let certain cenders be "priviledged"
> > for the delivery of the messages, which means hacking both
> > the MDA ("deliver") and "warnquota".
>
> In that case, why not just hack pop3d/imapd/whatever to display a
> 'virtual' e-mail of some type when the user connects. It could be
> complicated to avoid simply generating a new message every time the user
> connects without storing the time the last warning was received, I guess.
I already suggested that at the end of my email from which you are
quoting. 8-).
> > Another issue is that quota enforcement only occurs *after*
> > you exceed the quota, not *when* you exceed the quota. This
> > is because email messages must be treated as atomic units; so
> > if you are within 3k of a 100k quota, and you get an 80k message,
> > you can't not accept it.
>
> Why not? I can't see how you can't just bounce it. You may have accepted
> it, but that doesn't guaranteee delivery, just that you won't drop it on
> the floor.
The quotas in the Cyrus IMAP are implemented differently than you
appear to believe they are. I've already indicated why messages
must be treated as atomic units, and that quotas are enforced after
the fact, because that's often the only time that you can have an
accurate size measurement available.
Your idea of bouncing the message to the sender is flawed, unless
you are willing to drop the message on the floor.
Consider the case of two accounts. The first account is over quota.
It sends a message to the second account. The message would put
that account over quota (this scenario is to pay homage to your idea
that you could bounce instead of determine after the fact; even so,
if both accounts are over quota, the same logic applies). So you
bounce the message back to the first account. Only the first account
can not accept the bounce, because it is over quota.
Thus you must explicitly allow administrative messages to bypass
quota, in your scenario, if you accept responsibility for a message
that it turns out that it's impossible for you to deliver.
So... you avoid being screwed at one level, only to be screwed as
a result of a cascade failure.
> > The way "HotMail" handles this condition is to drop email that
> > it has accepted to delivery, if it can't be delivered to the
> > user because of them being over quota. But since it has
> > already accepted the email for delivery (by sending "250 OK"
> > to the remote SMTP client or MTA, it has pledged to deliver
> > the message, or give failure notification, so the message
>
> So why not give failure notification?
I thought I made this clear: because the addresses are responded
to as valid before the message size is known. The only recourse
is to fail the message atomically, regardless of the number of
recipients, after the size is known -- after the "DATA" command,
the "354 Continue" response, and the acceptance of data, followed
by the ".", but *before* you return a "250 OK" or, in your suggested
case, a "451 One of the recipients specified has exceeded quota".
Please see RFC-1870 "SMTP Service Extension for Message Size
Declaration" and RFC-2821 "Simple Mail Transfer Protocol (SMTP)".
It's only in the case that the "SIZE" extension is utilized, the
sender has not lied, and another delivery does not complete
simultaneously before the message is complete, that permits you
to do what you want. Even so, it rtequires the much tighter
MSA/MTA/MDA coupling I described previously.
For this to work, you would have to serialize access to maildrops
by receiver SMTPs (this is an intractable problem), AND you would
need to reject mail sent without the "SIZE" extension, or mail
whose actual size exceeded that specified by the "SIZE" extension
(you are not permitted to do this last, since the "SIZE" extension
is defined, by standard, to be advisory, not regulatory). This is
on top of the other coupling requirements.
Your performance would go into the toilet very quickly, if you did
this, particularly your agregate througput for a random (standard)
message load.
--
It's possible to construct examples, but this is not a mailing list
for discussion of SMTP server and protocol issues. Probably it
would be a good idea to take this discussion to http://www.imc.org/ ,
one of the mailing lists specific to your SMTP server software, or
one of the IETF lists, e.g. http://www.imc.org/ietf-smtp/index.html ;
the archive hoted there goes all the way back to 27 Dec 1990.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D0838FB.13B6DA3E>