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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message