On Mon, 21 Dec 2009 13:44:42 +0100, Joan <[email protected]> wrote: >> >> You need to check user's quota on routing stage, not transport. >> > It'd be much better, because I would allow me to mix overquota and > no-overquota recipients. > But the problem in my case is that I am using some hashing to > distribute the users' mailboxes, dovecot can handle this easily > because it supports some interesting stuff > (http://wiki.dovecot.org/Variables) > With a perl script I could also do that, I would like only if it's the > last resort (too much overhead I would think) >> >> I have wrote perl script for my setup that checks existence of >> maildirsize file and counting quota value for mailbox on smtp-processing >> stage, thus if user overquota exim's router will return error and you can >> treat it as 4xx or 5xx response.
Forgive my late entry into this thread, but I've been driving myself crazy for the last 12 hours trying to figure out the exact same problem. ACL, routers, etc, etc. To paraphrase (and sum up): How to prevent backscatter from either Exim or Dovecot LDA by rejecting email in the SMTP session. And I finally found the answer. It's so simple that I wanted to shoot myself for all the time spent trying to work out a solution. Answer: You can't. (Huh? What?) And this is why. Firstly, overquota scenarios aren't meant to be permanent errors. By definition, they're temporary. And not just temporary as in defer temporarily, I mean INTERNALLY temporary. Queued by Exim. The user is meant to log back in and clean things up, right? So immediately, forget about throwing a 5XX/4XX back to the sending mail server. Your mail server is meant to queue it, and wait til your slack user makes some space in his account. So does this mean you can't handle this in the SMTP session? Not exactly. Have I lost you yet? Probably, cause I was lost too. Look, in the most simple Exim configuration you can make sure every user maps directly to a maildir (and the corresponding maildir++ maildirsize file). [email protected] --> /usr/local/mail/domain1.com/jimsmith/Maildir/ Can we process overquota scenarios in the SMTP session for these basic 1-to-1 recipients? YES! Oh sweet simplicity, YES! BUT. Who among us only has this simple setup? If you do, then you're not my audience and just stop reading. In the real world, don't we also have an alias "[email protected]" that points to "[email protected]"? Maybe we also have domain1.NET which is a domain alias of domain1.com. MAYBE "[email protected]" is also a forward to his "[email protected]" account also residing on the server. So, again, I ask you, "Do you really think you can gracefully check and deny/defer based on the RCPT in the SMTP session?" When the RCPT is "[email protected]" which forwards to "[email protected]" which forwards to "[email protected]". Where the only account with a maildir and a corresponding quota is "[email protected]"? How many layers of recursion are necessary? You have to check this for every incoming RCPT, so how many CPU cycles are you wasting? How complex is this ACL Macro? How inefficient?! I have multiple Exim MTA's sharing a maildir store over NFS. I modestly have several thousands of users and many hundreds of domains. I *highly* customized a Vexim configuration and made it sing ... until the quota issue. Since I use Dovecot, I moved to Dovecot's LDA/Deliver to handle the last leg of message delivery. I now use Dovecot's Dictionary Quota (MySQL backend) to store quota information. This allows me to run a cronjob to search for over quota accounts and identify those who may simply be lazy, and those who may be subject to backscatter attacks, and disabling accounts if necessary. (You can also do this with maildir++ quotas, but that's a lot of file IO compared to a simply SQL query). All in all, the solution isn't with fancy ACL conditions or Macros, and certainly not in the routers because by then (as previously mentioned in this thread) the message is already accepted and you're throwing backscatter (or null routing). The solution is taking a step back and solving the problem outside the MTA, and rethinking policy. I apologize for the lengthy and opinionated response, but if it saves anyone the frustration I went through, then it was worth it. :-) -Ken Price -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
