There was an interesting discussion the other day started by Nathan
Ollerenshaw about rejecting over-quota users at SMTP time.
To summarise:
* By default, when using Exim's inbuilt quota support, messages for users
who are over-quota will be accepted at SMTP time, and a bounce message
will be generated. This is less than ideal.
* Checking quotas at SMTP RCPT time and issuing a suitable rejection
message would be a better way of dealing with the problem.
* It is not easy for Exim's inbuilt quota management to allow checking
of quotas at SMTP RCPT time for various architectural reasons, and
Philip (reasonably enough) has no plans to do anything about it at the
present time (if, indeed, there is anything much that can be done
within the current architecture).
A number of solutions were proposed, all of which had their own merits
(and downsides):
* Jeremy Harris: Do some clever, but rather complicated stuff with ACLs
and databases.
* Peter Bowyer: Use an external socket daemon to do the checks
* Greg Woods: Periodically (regularly) run a script which checks for
over-quota users, and write a redirect/alias file for any users that are
over-quota which overrides normal aliasing, and let verify=recipient do
its stuff.
I was particularly interested by Greg's idea. He provided a sample script
for use with Cyrus. Since I was interested in trying out a similar thing
with maildir++ directories (e.g. as used by Courier-IMAP installations)
then I had a bit of a play around and came up with a script and
corresponding Exim router to do this in a fairly clean and simple way.
With the thought that this might be useful to someone else, I've written
it up and all the details (including a ready-made, fairly generic script
for checking maildir++ quotas) are at:
http://www.timj.co.uk/computing/software/exim/rcpt-time-quota-maildir
I think that a readsocket{} check and accompanying daemon is probably
still the "best" way to attack this problem (though, perhaps, less
efficient - especially in the face of abusive behaviour from remote hosts,
though some gentle caching could probably alleviate things), and I may
experiment with that at a later stage, but for now I thought the above
method might provide some food for thought. Any comments or criticisms
welcome.
Tim
