On Thu, 2013-08-01 at 16:27 +0200, Ulrich Zehl wrote:
> On Thu, Aug 01, 2013 at 02:31:31PM +0200, Axel Luttgens wrote:
> >
> > http://hg.dovecot.org/dovecot-2.2/rev/2470bb9106b0
> > http://hg.dovecot.org/dovecot-2.2/rev/51b8020b29f6
> > http://hg.dovecot.org/dovecot-2.2/rev/eb63eca7447
On Thu, Aug 01, 2013 at 02:31:31PM +0200, Axel Luttgens wrote:
>
> http://hg.dovecot.org/dovecot-2.2/rev/2470bb9106b0
> http://hg.dovecot.org/dovecot-2.2/rev/51b8020b29f6
> http://hg.dovecot.org/dovecot-2.2/rev/eb63eca74471
> http://hg.dovecot.org/dovecot-2.2/rev/43488e1044
Le 1 août 2013 à 12:44, Timo Sirainen a écrit :
> On 1.8.2013, at 13.11, Axel Luttgens wrote:
>
>> [...]
>> unfortunately still requires to relax the permissions on the config unix
>> socket:
>> [...]
>
> Yeah. Hmm. I guess this is a good idea to fix too:
> http://hg.dovecot.org/dovecot-2.2/re
On 1.8.2013, at 13.11, Axel Luttgens wrote:
> Le 30 juil. 2013 à 20:36, Axel Luttgens a écrit :
>
>> [...]
>> Do you really mean "either", not "both"? I ask, because those patches seem
>> to intervene at quite different levels (but I guess I'll have, one day or
>> another, to get more acquaint
Le 30 juil. 2013 à 20:36, Axel Luttgens a écrit :
> [...]
> Do you really mean "either", not "both"? I ask, because those patches seem to
> intervene at quite different levels (but I guess I'll have, one day or
> another, to get more acquainted with Dovecot's coding, so as not to come with
> su
Le 30 juil. 2013 à 12:28, Timo Sirainen a écrit :
> On 14.7.2013, at 19.54, Axel Luttgens wrote:
>
>> [...]
>>
>> Going on with our telnet session:
>>
>> recipient=john@example.com
>> size=1
>>
>> action=OK
>>
>> Hmmm... OK, this may be a config problem of mine which ma
On 14.7.2013, at 19.54, Axel Luttgens wrote:
> and messages for that user are correctly rejected by lmtp:
>
> dovecot[4989]: lmtp(5069, john@example.com):
> QWSWLgrP4lF7FAAA5Q0ykw: msgid=<20130714161643.9085DF176F2@ALMba.local>: save
> failed to INBOX: Quota exceeded (mailbox for use
Le 14 juil. 2013 à 18:54, Axel Luttgens a écrit :
> [...]
>
> Is this the expected behavior, to have quota-status switch to another user?
I should have added: "And to have it indefinitely running as that user?".
Notwithstanding the permission problems that come with that behavior (see my
previ
Hello,
I'm currently experimenting with this quota-status service configuration:
service quota-status {
client_limit = 1
executable = quota-status -p postfix
# Let's make the default explicit.
user = root