John Burnham wrote:
>> Is there some way to configure quota differently for different mail
>> accounts???
>>
>> In the configure file there seems to be only one set of quota settings
>> in the local_delivery section. It would be very useful if
>> there could be
>> more than one tier, so that some high volume users could have larger
>> quotas. For instance, one account is a destination for PDF files and
>> tends to fill the 20MB quota in a hurry, whereas other
>> accounts would be
>> fine with even a 10MB quota.
>>
>
> The quota setting is an expanded string which means you could use some form
> of lookup and have
> something like (untested and I've had no coffee yet)
>
> quota = ${lookup ($local_part} lsearch {/a/file/containing/quotas} {$value}}
>
> If anyone more awake wants to improve on this, please do :)
> J
>
>
I started to do - but was interrupted by a RAID1 fail some time back..
In a nutshell;
Exim can 'source' a quota from anywhere that it is allowed to read or
connect. Several examples are around of it using 'dot' files stored
Qmail/Courier style within user's Maildir, helpful in migrating from
some other MTA to Exim.
Exim can also get the quota figure from a DB, CDB, SQL DB, LDAP DB or
flat file. With a small enoug user base, OR same-per-entire domain, it
can even be hard-coded into Exim's configure file as a MACRO, so..
Applying it is a separate item:
The 'best' place to apply the quota test would be in the RCPT phase
where per-user handling is still in place.
*Unfortunately* one cannot reliably ascertain the size of the incoming
message+attachments until later - in DATA phase - at which point
per-user handling is no longer practical (an smtp limitation, not Exim's).
That said, what one *can* do is reject (or defer) while in RCPT for an
individual user IF they are ALREADY over quota, as the incoming size of
new traffic matters not.
If they are not-yet over quota, but the newly offered message would put
them into that state, the earliest point one can reliably detect that is
in DATA. That means generally taking action in the routers, not the
acl's and potentially having to generate an out-of-session DSN (bounce)
back to the sender. Examples can be found, but better to avoid taking
action that late if at all practical, so:
Compromise.
- allow a fixed overflow amount above the stated quota.
'Most of the time' that will let the last message that runs the user
over-quota see an 'accept', then - being already 'over', cleanly reject
per-user in RCPT on the NEXT message w/o need to know the size of that
incoming. And never chance an out-of-session 'bounce'.
The exception to 'most' being near-parallel runs of child processes
delivering traffic for the same user (from different sources).
And also - the parts beyond Exim's control:
- just how accurately or 'currently' the fa underlying the mailstore can
report in any case, as it is hard to know what might be in the queue,
awaiting a separate runner, or might be in the process of deletion or
addition as the result of an IMAP folder manipulation, etc.
One rolls those dice...
... ELSE buys seriously bigger drives, then relies on the real-world
bandwidth limitations to impose a 'good enough' de-facto quota, such
that daily 'df' reports give enough warning (days if not weeks or
months) to take remedial action before outrunning space.
We find drives cheaper than labor or handling gripes, so ceased using
quotas when we left Qmail on a 500 MHz K6....
YMMV,
Bill
--
## 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/
