[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