On Mon, 21 Dec 2009 13:44:42 +0100, Joan <aseques@???> 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).
jimsmith@??? --> /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
"jim@???" that points to "jimsmith@???"? Maybe we also
have domain1.NET which is a domain alias of domain1.com. MAYBE
"jimsmith@???" is also a forward to his
"jimsmith@???" 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
"jim@???" which forwards to "jimsmith@???" which forwards
to "jimsmith@???". Where the only account with a maildir
and a corresponding quota is "jimsmith@???"? 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
