Hello, I've found a bug in the quota-status util (Dovecot 2.2.21, and probably below): it always return OK (sufficient quota) because it fails to load the user properly. More specifically, the branch " if (quser == NULL) return 1; " in src/plugins/quota/quota-status.c:59 is always taken. (at least with postgresql backend, test your config with the (adapted) command below: printf "recipient=mailbox at example.com\nsize=10000000000\n\n" | nc inet:mailstore.example.com 12340 it should reject, unless you have no quota, or more than 10G). Therefore it is pointless to configure the quota-status service as described in http://wiki2.dovecot.org/Quota because of that bug: the mail would be always accepted from the client and rejected at the end of the (Postfix) processing by lda. It is possible to reject directly at SMTP level when the mailbox is full using Postfix and main.cf: smtpd_recipient_restrictions = ... reject_unauth_destination, ... check_policy_service inet:mailstore.example.com:12340 smtpd_end_of_data_restrictions = check_policy_service inet:mailstore.example.com:12340 However there remain a *small inconsistency* as lda will count the size of message including headers whereas smtpd_end_of_data_restrictions seems not to count them towards the message size (or additional headers might be added by other preprocessing e.g. antispam etc...) I propose the patch below to fix quota-status. Could an expert double-check that it doesn't have memory leaks? (it shouldn't but I'm not yet comfortable enough with Dovecot memory management). Best regards, Thierry C. -------------- next part -------------- A non-text attachment was scrubbed... Name: quota-status.patch Type: application/octet-stream Size: 963 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20160207/0eafe18d/attachment.obj>
> Le 7 f?vr. 2016 ? 23:26, Thierry Coppey a ?crit : > > Hello, > > I've found a bug in the quota-status util (Dovecot 2.2.21, and probably below): it always return > OK (sufficient quota) because it fails to load the user properly. More specifically, the branch > " if (quser == NULL) return 1; " in src/plugins/quota/quota-status.c:59 is always taken. > (at least with postgresql backend, test your config with the (adapted) command below: > printf "recipient=mailbox at example.com\nsize=10000000000\n\n" | nc inet:mailstore.example.com 12340 > it should reject, unless you have no quota, or more than 10G). > > [?]Hello Thierry, Could it be that you found an explanation for a similar problem I encountered as early as with 2.2.4 and with a sqlite backend (see thread "2.2.4 - Some questions about and needing help with quota-status" started July 16, 2013)? It would be marvelous, as I?m currently stuck with quite an ugly workaround. Thanks, Axel
> On 08 Feb 2016, at 00:26, Thierry Coppey <info at tcknet.ch> wrote: > > Hello, > > I've found a bug in the quota-status util (Dovecot 2.2.21, and probably below): it always return > OK (sufficient quota) because it fails to load the user properly. More specifically, the branch > " if (quser == NULL) return 1; " in src/plugins/quota/quota-status.c:59 is always taken. > (at least with postgresql backend, test your config with the (adapted) command below: > printf "recipient=mailbox at example.com\nsize=10000000000\n\n" | nc inet:mailstore.example.com 12340 > it should reject, unless you have no quota, or more than 10G).It works fine with me. Maybe you simply didn't enable quota-plugin for quota-status service? (e.g. you enabled inside protocol imap { .. } and elsewhere, but not globally)
> Le 2 mars 2016 ? 15:31, Timo Sirainen a ?crit : > > >> On 08 Feb 2016, at 00:26, Thierry Coppey wrote: >> >> Hello, >> >> I?ve found a bug in the quota-status util (Dovecot 2.2.21, and probably below): it always return OK (sufficient quota) because it fails to load the user properly. More specifically, the branch " if (quser == NULL) return 1; " in src/plugins/quota/quota-status.c:59 is always taken. >> (at least with postgresql backend, test your config with the (adapted) command below: >> [?] > > It works fine with me. Maybe you simply didn't enable quota-plugin for quota-status service? (e.g. you enabled inside protocol imap { .. } and elsewhere, but not globally)Hello Timo, To be sure to understand correctly, are you referring to a top level setting such as: mail_plugins = ? quota ? that could be missing? Axel