On Fri, Feb 13, 2004 at 04:14:36PM +0000, Nigel Metheringham said: > On Fri, 2004-02-13 at 15:55, Chris Meadors wrote:
> > Anyway, to the question... How can I stop the bounces generated after
> > the fact by users at quota? I worked to have nearly all my rejections
> > done at SMTP time, but this quota thing has been a thorn in my side.
>
> Interesting question. Quotas are a special case of a bounce caused by a
> transport failure. As such they cannot happen until the transport kicks
> in, which for exim is *after* the message has been fully accepted and
> put on the queue.
>
> So at present this cannot be done directly.
>
> Work rounds could be by hacking some other means of checking quota and
> using that within a router or an acl - either a real check on a quota or
> a lookup against a list of current over-quotas.
Yeah - one main problem is that you don't really know how big the
message is until DATA. Considering that the message may be going to
muliple recipients, you can't bounce an individual user at data - it has
to be done at RCPT time. A possible workaround (which can impact load
and performance,) is to limit the number of simultanious recipients to 1
allowing you to check quota in DATA.
If you check at RCPT, one option is to have a db of "over quota" users.
A cron script could periodically check the users' disk usage and update
the DB (probably the least performance impact on the mail server).
Another option is to do that check real-time in a script called from the
RCPT ACL. Of course there is the corner cases. What if the user is
under quota and then you try to deliver a message that would put it over
quota? The result depends on whether you have hard or soft quotas.
One advantage of the DB approach is that mail spools / home directories
can be on a different server than the mail server. Down side is that you
won't know if a message puts you over hard quota until delivery. I
suppose you could create a "quota" daemon that does real-time
checking...
It seems as though there are many possible ways to handle this, although
many have limitations and may not work in your particular implemention.
You are going to have to think through the corner cases that depend on
the details of your setup in order to determine which way works for you.
