Timo Sirainen wrote, On 10/17/2008 06:37 PM:

On Oct 17, 2008, at 3:39 PM, Sotiris Tsimbonis wrote:

...

When I send an email to this account, sendmail accepts the email and tries to deliver it. Deliver fails to save in INBOX and returns an error, but the email stays in sendmail's queue..

Any suggestions on how to avoid this and produce a 5xx error for overquota users before accepting the email would be greatly appreciated..

That should be the default. "quota_full_tempfail" setting controls it, do you have it commented out in the config file? (unfortunately lda section isn't listed with dovecot -n)

Sorry, I forgot to include this part.. Unfortunately I've set it to no, that's the problem..

protocol lda { postmaster_address = postmaster@forthnet.gr mail_plugins = quota quota_full_tempfail = no sendmail_path = /usr/sbin/sendmail auth_socket_path = /var/run/dovecot/auth-master }

Sotiris.

Timo Sirainen wrote, On 10/18/2008 01:31 PM:

On Fri, 2008-10-17 at 22:30 +0300, Sotiris Tsimbonis wrote:

...

...

That should be the default. "quota_full_tempfail" setting controls it, do you have it commented out in the config file? (unfortunately lda section isn't listed with dovecot -n)

Sorry, I forgot to include this part.. Unfortunately I've set it to no, that's the problem..

protocol lda { postmaster_address = postmaster@forthnet.gr mail_plugins = quota quota_full_tempfail = no

Well, the problem is again deliver's own stupid configuration parsing. It doesn't know that quota_full_tempfail is a boolean setting, so it treats "no" as "yes". Just remove/comment out the setting entirely and it should work.

Yeap, it worked now!

deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: msgid=200810181856.m9IIu6rc005273@mx-mstr-07.forthnet.gr: save failed to INBOX: Quota exceeded (mailbox for user is full) deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: msgid=200810181856.m9IIu6rc005273@mx-mstr-07.forthnet.gr: rejected: Quota exceeded (mailbox for user is full) deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: Sending a rejection to stsimb.t157.forthnet.gr: Quota exceeded (mailbox for user is full)

Thanks Timo! Sot.

http://hg.dovecot.org/dovecot-1.1/rev/f8e6d1922280 also fixes this. And hopefully v1.3 will have rewritten config handling which finally gets rid of these kind of problems.

Charles Marcus a écrit :

On 10/18/2008 3:04 PM, Sotiris Tsimbonis wrote:

...

deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: msgid=200810181856.m9IIu6rc005273@mx-mstr-07.forthnet.gr: save failed to INBOX: Quota exceeded (mailbox for user is full) deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: msgid=200810181856.m9IIu6rc005273@mx-mstr-07.forthnet.gr: rejected: Quota exceeded (mailbox for user is full) deliver(stsimb.t157.forthnet.gr): Oct 18 21:56:30 Info: Sending a rejection to stsimb.t157.forthnet.gr: Quota exceeded (mailbox for user is full)

I'm by no means sure, but this looks like you are BOUNCING a message due to over quota AFTER having already ACCEPTED it... can you confirm/deny this?

yes he does. I hope he has a good spam filter! sending bounces to forged senders isn't a good practice...

On 10/19/2008, Sotiris Tsimbonis (tsimbonis@forthnet.gr) wrote:

But how do we move the rejection at smtp level using sendmail+dovecot lda?

Thats a sendmail question, so the only answer I can give is...

switch to postfix... ;)

--

Best regards,

Charles

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sun, 19 Oct 2008, Sotiris Tsimbonis wrote:

But how do we move the rejection at smtp level using sendmail+dovecot lda?

When a recipient is valid, the mail is queued locally, then the delivery attempt is made. That means that the SMTP dialogue has been closed already, before the MDA is invoked. sendmail has quite a strict separation between MTA and MDA, or to put it in other words it supports only the basic Unix-style /var/mail/system_user mboxes natively.

About "Switch to postfix":

How handles postfix the situation, when you mail to an alias with several recipients, one of them is overquota? Is the mail tempfailed for all of them?

==

Well, you could deploy a milter that verifies the recipients at RCPT TO stage. Depending on your config it may be difficult to map recipient addresses to the particular mail storage (esp. if probed on mail relays).

If you have a strict naming policy, you can put all users over quota into the access DB and update them regularily - thus avoding the milter.

Bye,

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI/FNkVJMDrex4hCIRAts4AJwKhz7XsnO++lkgGtea2O+gw+RgYQCgq9uD iyG3qlVh0mx4sDTxQTvAqiU= =e/K4 -----END PGP SIGNATURE-----

On 10/20/2008 01:11 PM, Sotiris Tsimbonis wrote:

The problem is, that with Maildir it can be very costly to calculate the actual mail usage on every mail delivery attempt..

If I could somehow access dovecot's maildirsize, where the size is already calculated and updated on delivery and retrieval, things would be better..

After reading http://wiki.dovecot.org/Quota/Maildir and the standard Maildir++ specification, it's quite easy to get maildirsize after all..

See http://stsimb.irc.gr/2008/10/20/milter-quota-for-maildir/

So now I can bounce messages using a milter at smtp level :)

Sot.

Sotiris Tsimbonis a écrit :

I confirm, that the above config does produce bounces (possibly forged i.e. backscatter) and it's bad ..

But how do we move the rejection at smtp level using sendmail+dovecot lda?

for that you need to detect over quota during the smtp transaction, but in general, MTAs queue mail first, and deliver later.

There is no "perfect" way to deal with this issue. even if you use a milter (or policy server or proxy_filter...), you will find it hard to take into account mail that is still in the MTA queue (for that, you would need to detect which mail was delivered since you started counting, ... etc). really not something you should go for.

You can however mitigate the problem.

• you can populate an access list to reject mail to users who are over quota. you need some way to remove them from the list once they purge their mailbox (web ui, cron, dovecot plugin, ...).

• filter spam (as much as you can) and don't bounce if the message is spam. The issue here is what to do with the message (because of FPs, you can't simply discard it). on the other hand, you can reject junk transactions at smtp time (well, at least some volume of junk)

My preference for quota handling is this:

• user has two quotas. say 100 Mo and 150 Mo.
• if he reaches 100 Mo, he is warned. he should purge his mailbox.
• if he reaches 150 Mo, his address is blocked. He will need to purge his mailbox and ask to be delisted (maybe via a web UI).
• when mail is received, users who are between 100 and 150 are checked in real time. if this shows them reaching 150, they are added to the "block list". otherwise, mail is delivered as usual.

with this, no real time quota checks are done for users under the "low" threshold. if most of your users fall in this category, this means that real time checks are relatively rare.