dovecot - Jul 2009 - RFC: Different quota for dovecot and deliver

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-0002.bin>

On Freitag, 17. Juli 2009, Philipp Marek wrote:
> So I looked into the sources, and came up with the attached (untested, not
> even compiled) patch against 1.2.1.
...
> I've now looked into the sources, and tried to sketch the basic change
that
> I imagine; please see the attached patch.
The newer version in this mail actually compiles - I used the wrong structure 
to address the env_name.


Regards,

Phil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: env_name2.patch
Type: text/x-patch
Size: 1581 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090717/919771ae/attachment-0002.bin>

On Fri, 2009-07-17 at 10:51 +0200, Philipp Marek wrote:
> 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.
Actually there shouldn't be a need to patch Dovecot to get this. You
could just do something like:

user_query = select .., \
  '*:' || (case '%s' when 'deliver' then (quota+20*1024)
else quota)) as quota_rule, ..
> I've now looked into the sources, and tried to sketch the basic change
that I
> imagine; please see the attached patch.
I'm not exactly sure what you intended the patch to do. dict-sql is used
only for storing the actual current quota usage (not limits) to database
when using dict quota (and not Maildir++ quota).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090717/8ae69c46/attachment-0002.bin>

Hello Timo,

thank you very much for your answer.

On Freitag, 17. Juli 2009, Timo Sirainen wrote:
> On Fri, 2009-07-17 at 10:51 +0200, Philipp Marek wrote:
> > 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.
>
> Actually there shouldn't be a need to patch Dovecot to get this. You
> could just do something like:
>
> user_query = select .., \
>   '*:' || (case '%s' when 'deliver' then
(quota+20*1024) else quota)) as
> quota_rule, ..
That would be perfect ... I'll take a look.

Are placeholders like "%s", "%n" etc. listed anywhere?
Google doesn't help, a
grep for "%s" in the sources is a bit misleading, and not even a

	grep "case.*'.'.*:" -r .

did help me.

> > I've now looked into the sources, and tried to sketch the basic
change
> > that I imagine; please see the attached patch.
>
> I'm not exactly sure what you intended the patch to do. dict-sql is
used
> only for storing the actual current quota usage (not limits) to database
> when using dict quota (and not Maildir++ quota).
It's entirely possible that I just looked into the wrong places.


Regards,

Phil

Philipp Marek wrote:
> Hello Timo!
> 
> On Montag, 20. Juli 2009, Timo Sirainen wrote:
>> On Jul 20, 2009, at 1:56 AM, Philipp Marek wrote:
>>> Are placeholders like "%s", "%n" etc. listed
anywhere?
>> http://wiki.dovecot.org/Variables
> Thank you very much for your quick answer!
> 
> BTW: Google gives
> 	Your search - link:http://wiki.dovecot.org/Variables - did not 
> 	match any documents.
> 
> so how about linking to that page in the Wiki ;-) ?
> 
It is: http://wiki.dovecot.org/MainConfig

And others. Google is not always right.

~Seth