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.