[Dovecot] RFC: Different quota for dovecot and deliver
Philipp Marek
philipp.marek at emerion.com
Fri Jul 17 11:51:49 EEST 2009
Hello everybody,
I've been with this question in IRC the last days, but no solution was found.
So I looked into the sources, and came up with the attached (untested, not
even compiled) patch against 1.2.1.
Rationale
-----------
I'd like to bounce on the external side, which is quite easy if the quota is
stored in a SQL database; then eg. postfix can directly query it, and reject
accordingly without doing any real work.
Now, as discussed some time ago on the postfix list (cannot find it anymore,
sorry), it would be best to *not* bounce internally, ie. when the mail is
delivered in the mailbox, but to allow a small bit of over-usage instead.
Thoughts
----------
Why don't we simply set the value seen by postfix down a bit?
I don't think that this is the correct solution; if the difference between
these two values is smaller than the allowed mail size we'd get internal
bounces again.
(And we wouldn't allow to *get* the amount of mail, btw, only to use it via
COPY.)
There are more complicated schemes, like putting a slightly higher quota in
the configuration, and subtracting a bit in postfix again.
I wouldn't see that as aesthetical, too.
Furthermore all such schemes have the problem of being unstable - larger mails
get (internally) rejected earlier than small ones.
Wanted behaviour
------------------
What I'd like to achieve is that postfix uses the trigger value from the
Database as well, but that deliver allows a small bit more - say 5, 10, or
20MB.
Then one incoming mail simply makes the quota go over the defined limit; now
postfix no longer accepts mail, but the incoming queue (amavis etc.) can be
drained - at least if there's not some big hiccup in queue processing, and
that's why I'd like to use a *different* quota, and not simply *none* (for
deliver).
Idea to solve this
--------------------
The idea is that in the SQL configuration the name of an environment variable
can be given to the SELECT query; this name, and the value of the environment
variable, are used as an additional WHERE constraint.
It would be much nicer if a stored procedure could be called with parameters
(like Postfix allows), but that would mean a fair bit of change to dovecot.
(And in Postgres at least the query could be rewritten with rules - but that's
not that nice, either.)
I've now looked into the sources, and tried to sketch the basic change that I
imagine; please see the attached patch.
Would something like that be acceptable?
I thought for some time whether the additional query should use the filename
part of the executable; then similar things could be done.
But as this is a bit more general I settled for the environment variable.
Thank you for all answers.
Regards,
Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: env_name.patch
Type: text/x-patch
Size: 1454 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20090717/1418ee09/attachment-0001.bin
More information about the dovecot
mailing list