dovecot - Nov 2012 - Sieve puts incoming message into inbox on any problem with submission_host

Hello dovecot-users,

I have a question/suggestion regarding the submission_host feature of
the lda (either via dovecot-lda binary or lmtp) in combination with sieve.

When trying to deliver message to a mailbox and this message has a sieve
redirect action applied to it, dovecot is using the configured smtp
server to forward the message just fine. Unfortunately, if the server
configured for submission is unavailable, returns an error or cannot be
found via DNS, sieve will simply put the message into the inbox and be
done with it:

--- dovecot.log ---
dovecot: lda(user1): Error: lmtp client: DNS lookup of
idonotexist.example.com failed: Name or service not known
dovecot: lda(user1): Error: sieve: msgid=unspecified: failed to redirect
message to <user2> (refer to server log for more information)
dovecot: lda(user1): sieve: msgid=unspecified: stored mail into mailbox
'INBOX'
dovecot: lda(user1): Error: sieve: execution of script
/mailboxes/user1/.dovecot.sieve failed, but implicit keep was successful
(user logfile /mailboxes/user1/.dovecot.sieve.log may reveal additional
details)
--- /dovecot.log ---

The same applies to vacation messages being sent out. Especially with an
(unconditional) redirect action, users don't expect to find messages in
their inbox. Also problems with the submission_host could very much be
temporary and a little delay in delivering a message is better then
putting it somewhere the user doesn't expect a message to be.

Is there any way to change the behavior of dovecot or the sieve plugin
to tempfail in case a message cannot be sent out?
I know that with multiple sieve actions it gets more complicated as
there could be corner cases were the first message can be sent via the
submission server and another message produced by the same sieve script
cannot.

I'd love sieve to behave like this:

a) if submission host is unreachable (hostname wrong, timeout, ...) ->
tempfail

b) if submission host returns 4xx error -> tempfail

c) if submission host returns 5xx error -> fail(-save) and just drop the
message into inbox or even have an option to reject the message
completely in this case.


In case of a tempfail response, the mta simply queues the message and
tries again later. In case of a permanent fail the mta will create a
bounce message to in form the sender.





Regards and have a great weekend,


Christian

On 11/9/2012 2:24 PM, Christian Rohmann wrote:
> Hello dovecot-users,
>
> I have a question/suggestion regarding the submission_host feature of
> the lda (either via dovecot-lda binary or lmtp) in combination with sieve.
>
> The same applies to vacation messages being sent out. Especially with an
> (unconditional) redirect action, users don't expect to find messages in
> their inbox. Also problems with the submission_host could very much be
> temporary and a little delay in delivering a message is better then
> putting it somewhere the user doesn't expect a message to be.
Yes, I agree. With the normal sendmail configuration this situation was 
much less likely to occur since messages would be queued locally first.
> Is there any way to change the behavior of dovecot or the sieve plugin
> to tempfail in case a message cannot be sent out?
Not currently, I've been thinking about something like that for use with 
the extprograms plugin, which presents similar challenges.
> I know that with multiple sieve actions it gets more complicated as
> there could be corner cases were the first message can be sent via the
> submission server and another message produced by the same sieve script
> cannot.
Exactly. And other kind of actions even make this more annoying. The 
Sieve interpreter tries to do things atomically as much as possible. 
With outgoing messages, that is rather difficult, so these actions are 
performed only after all other actions, e.g. local folder deliveries, 
succeed. So, in the current implementation simply issuing a temp fail 
would yield the even nastier result of duplicating deliveries; it is not 
possible to simply undo local message deliveries at that stage anymore.

To solve this definitively I'll have to do some redesign of the action 
execution sequence.
> I'd love sieve to behave like this:
>
> a) if submission host is unreachable (hostname wrong, timeout, ...) ->
> tempfail
The simplest solution right now would be to perform a pre-check on 
whether the message submission is likely to succeed or not.

Regards,

Stephan.