Re: [exim] Configuring mailbox quotas on large servers

Todd Lyons wrote:
> On Fri, Nov 27, 2009 at 4:11 PM, Phil Pennock <exim-users@???> wrote:
>>> Are there any other ways of doing this? If there are, nothing has
>>> come to mind and I welcome suggestions.

*snip* (how-to w/r maildrop and/or routers)

> positive experiences with maildrop. I did not realize that I could
> use exim to enforce quota (in a router, so I think that will allow me
> to defer/reject at SMTP time, which is my ultimate goal). I thought I
> had to hand it off to something else in order to get quota
> enforcement.

Verification-walks aside, (which you can use, per the redacted coverage)
.. router/transports are not otherwise really 'at smpt time'.

The 'session 'ends as you leave the DATA phase.

But you *can* know the actual size while still in acl_smtp_data and
*can* use that information to insure that your defer/deny is
communicated directly to, and ONLY to, the still-connected entity,
thereby eliminating risk that an NDR is abused for any form of
backscatter spamming.

ISTR there are examples of useful acl snippets in the list archives


... all part of why Exim & its acl's are so effective vs
MTA+[milters]+[maildrop|procmail| friends]

CAVEATS:

- I don't (need to) use quotas, as a message-size limit, large RAID1,
and finite b/w on the front-end give me days if not weeks to react to
consumption of space with my particular user community.

YMOV - BUT... a setup where you publish quota 'n' but actually provide
for space for quota 'n+20%' and trigger at quota [n+10%] before
defer|deny might reduce your admin load costs more than the extra HDD
space costs. A fair bit of slack also reduces the risk of one
child-process clearing the session and THEN hitting a router or fs
blockage because one or more OTHER children were already using-up the
last of the headspace, or conversely, rejecting if the POP/IMAP daemon
was clearing more space in the meantime.

- Be aware also that there exist sending 'entities' that do not
hang-around for 'proper' completion of DATA handshakes. All the more
reason, IMNSHO, to NOT generate out-of-session NDR's to such critters,
as they are more likely to be maliciously-coded rather than just-plain
broken.

- Note necessarily a recommended practice, but I also disallow
pipelining so as to insure nothing comes onto the box before it has
passed all tests prior to acl_smtp_data. Up to that point, there has
been nothing exchanged but ephemeral handshakes, no HDD space required
for those at all.

Do your own due diligence on that issue, as one size does not fit all.

Finally - if you are running a hot and heavy MTA, it helps to NOT use
the default /var mount-point for mailstore (or even, necessarily for
spool). If ~/var ever overflows, the system logger (among other needful
things) is stumped, which is not good.

As Exim can easily be pointed to use of a bespoke mount (separate
hardware RAID recommended) for mailstore and optionally spool, that
makes migration, upgrades, or failure recovery a bit cleaner, and helps
insure that you can at least ssh into a box that has not dropped into
single-user mode due to an 'unable to write..' panic.

HTH,

Bill