Le 26 mai 09 à 02:08, Timo Sirainen a écrit :
On Sun, 2009-05-24 at 18:35 +0200, Axel Luttgens wrote:
- Shouldn't deliver honor the first_valid_uid setting?
I'm not sure. Somehow enforcing it there seems like a bad idea to me.
Yes, could well be that I overlooked some possible side-effects.
On the other hand, this would help to enforce the deliver+Dovecot pair
consistency (if John Doe can't fetch his mails, should he receive
mails?). Or help to enforce, even if inefficiently, some local
policies not easily implemented otherwise.
Someone else? ;-)
- What exactly is the -e option supposed to do? .. Note that the question may somehow be re-phrased as: when invoked without the -e option, under which circumstances will deliver send a rejection message?
Only when user is over quota.
OK, this would thus be intended design.
If you don't want messages to be delivered to some users, Postfix shouldn't call deliver for the user.
I agree that waiting to have a message enqueued for rejecting it
afterwards is somewhat inefficient.
But... ;-)
Let's first consider deliver as a replacement of Postfix' mailbox
delivery, because of the nice benefits (indexing, headers
sanitization, plugins...) it comes with.
With Postfix' own mailbox delivery, i.e.
mailbox_command =one gets with my previous example:
postfix/smtpd[8639]: connect from localhost[127.0.0.1]
postfix/smtpd[8639]: 1AFE4CA5D97: client=localhost[127.0.0.1]
postfix/cleanup[8642]: 1AFE4CA5D97: message-id=<029EE72B-B412-437F-A211-33C3597C8C54@almbp.local >
postfix/qmgr[8637]: 1AFE4CA5D97: from=<testuser@almbp.local>,
size=560, nrcpt=1 (queue active)
postfix/local[8643]: 1AFE4CA5D97: to=<www@almbp.local>,
relay=local, delay=0.08, delays=0.01/0.01/0/0.06, dsn=5.2.0,
status=bounced (cannot update mailbox /Library/WebServer/_inbox/
mailspool for user www. unable to create lock file /Library/WebServer/
_inbox/mailspool.lock: No such file or directory)
postfix/cleanup[8642]: 2C455CA5D99: message-id=<20090526075000.2C455CA5D99@almbp.local
postfix/qmgr[8637]: 2C455CA5D99: from=<>, size=2896, nrcpt=1 (queue active)
postfix/bounce[8644]: 1AFE4CA5D97: sender non-delivery
notification: 2C455CA5D99
postfix/local[8643]: 2C455CA5D99: to=<testuser@almbp.local>,
relay=local, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent
(delivered to mailbox)
postfix/qmgr[8637]: 1AFE4CA5D97: removed
postfix/qmgr[8637]: 2C455CA5D99: removed
postfix/smtpd[8639]: disconnect from localhost[127.0.0.1]
So, Postfix' default behavior is to bounce the message; strictly
speaking, deliver can't thus be viewed as a transparent substitute.
Now, let's consider the default behavior of Postfix when facing an
over-quota recipient:
postfix/smtpd[8977]: connect from localhost[127.0.0.1]
postfix/smtpd[8977]: 91CEECA5FDF: client=localhost[127.0.0.1]
postfix/cleanup[8980]: 91CEECA5FDF: message-id=<B46CADD6-E42D-493C-AB04-46B0BFF3F78A@swing.be >
postfix/qmgr[8938]: 91CEECA5FDF: from=<AxelLuttgens@swing.be>,
size=12634, nrcpt=1 (queue active)
postfix/local[8981]: 91CEECA5FDF: to=<testuser@almbp.local>,
relay=local, delay=0.04, delays=0.02/0.01/0/0.01, dsn=5.2.2,
status=bounced (cannot update mailbox /Volumes/ALMbpSpare/People/a/
testuser/_inbox/mailspool for user testuser. error writing message:
File too large)
postfix/cleanup[8980]: 980EECA5FE1: message-id=<20090526085344.980EECA5FE1@almbp.fusl.ac.be
postfix/bounce[8982]: 91CEECA5FDF: sender non-delivery notification: 980EECA5FE1
postfix/qmgr[8938]: 91CEECA5FDF: removed
postfix/qmgr[8938]: 980EECA5FE1: from=<>, size=2702, nrcpt=1
(queue active)
postfix/smtp[8983]: 980EECA5FE1: to=<AxelLuttgens@swing.be>,
relay=in.mx.skynet.be[195.238.5.129]:25, delay=2.8,
delays=0.01/0.01/2.8/0.05, dsn=2.0.0, status=sent (250 ok: Message
446634039 accepted)
postfix/qmgr[8938]: 980EECA5FE1: removed
postfix/smtpd[8977]: disconnect from localhost[127.0.0.1]
In this case, by default, Posfix adopts the same behavior as deliver.
But I could have needed for some administrative reason to configure
Postfix with, for example,
soft_bounce = yesand then again face a problem when considering to make use of deliver
as mailbox transport.
More generally, since one of deliver's goal is to replace an MTA's
local delivery agent, it would be nice to have some ways to fine tune
deliver's behavior.
That would allow to transparently integrate deliver into an existing
MTA setup.
Or even to augment the capabilities of that setup, for example by
refining local policies.
At least, it would be nice to have a very precise description of how
deliver is supposed to behave when facing various conditions.
This would then be a documentation matter.
Of course, the source code always is the ultimate documentation :-)
- Doesn't failure_exit_callback() in deliver.c tend to merge many (possibly dissimilar) errors into the single EX_TEMPFAIL one?
Yes. EX_TEMPFAIL is the safest choice almost always. If something breaks, you typically want to fix it and get the mail delivered again, instead of being rejected the first time and never seeing the mail.
Yes, to be right under any circumstances is rather difficult;
ultimately, perhaps is this a matter of local policy.
Anyway, let's consider this (stupid) one:
mailbox_command = /usr/local/dovecot/libexec/dovecot/deliver -e -n -xHere, deliver immediately returns with EX_USAGE and, by default,
Postix will reject the message; but this is something I could have
noticed and fixed in the meantime.
On the other hand, it could also be argued that an over-quota
recipient is fixable as well: just pick the phone and ask the
recipient to clean his mailbox. And one could thus conclude that
deliver's default behavior isn't the right one...
Now, that last point may be controlled thru QUOTA_FULL_TEMPFAIL, so
that deliver nevertheless appears to be at least partially configurable.
Hence the temptation to ask for more configurability...
(in fact, I was musing on the possibility to modulate the switch
statement with some config settings)
And BTW, is that function guaranteed to be always called with an EX_* value? Seems to be the case, but... ;-)
What do you mean? It's called with FATAL_* values and it replaces them with EX_TEMPFAIL.
Sorry, some kind of mental short circuit occurred here; I meant:
"guaranteed to always return with status set to an EX_* value?".
I asked because of the default case in failure_exit_callback(), which
just returns and leaves status as it was on entry. Conceptually, one
could thus enter and leave the function with status set to a value
differing from one of the FATAL_* and the EX_*, that value being
ultimately returned to the caller. May this happen in practice? If
yes, when and which values?
Again, thanks a lot Timo for bearing with a guy who's just a plain
newbie with Dovecot,
Axel