[Dovecot] Pigeon Sieve, redirect action and SPF

[Stephan Bosch]

Hi Pedro,

On 7/25/2011 6:53 PM, Pedro Ribeiro wrote:
> Since I've upgraded to dovecot 2.0.13 + Pigeonhole 0.2.3 (Gentoo 
> package) I've received a few complains of users about rejected messages.
>
> Investigating the problem, I've seen that when the external sender 
> server publishes SPF information, when some message is sent from there 
> to one of my users that has a Sieve redirect action active to another 
> external system (that does SPF validation), the message is rejected 
> because our system only changes the envelope "rcpt to" in the 
> redirection and the "mail from" remains the original.
> When the end server does the SPF validation it fails because my server 
> isn't in the IP allow list for the domain of the original sender.

Right.

> I never seen this problem in the old Dovecot+CMUSieve.

What version? The sources I checked (v1.1 and v1.2) use the return path 
of the original message, e.g.:

http://hg.dovecot.org/dovecot-1.1/file/3698dfe0f21c/src/deliver/mail-send.c#l186

>
> Shouldn't the sender be changed in the envelope "mail from" from the 
> original one to the recipient that made the Sieve redirection?

The now obsolete RFC3028 only mentions modifying the envelope recipient, 
which is probably what the CMUSieve plugin is based on. The behavior of 
Pigeonhole Sieve in such ambiguous cases is mostly derived from CMUSieve 
for backwards compatibility, which is why - indeed - only the envelope 
recipient is modified.

However, the new RFC5228 is not very strict on this point (Section 4.2):

    The envelope sender address on the outgoing message is chosen by the
    sieve implementation.  It MAY be copied from the message being
    processed.  However, if the message being processed has an empty
    envelope sender address the outgoing message MUST also have an empty
    envelope sender address.  This last requirement is imposed to prevent
    loops in the case where a message is redirected to an invalid address
    when then returns a delivery status notification that also ends up
    being redirected to the same invalid address.

This suggests making this configurable, which I think would be no problem.

Its a bit late, I'll give this a look later.

Also, do others have a view on this? Is there perhaps an easier way to 
fix this issue, other than adding a config option?

Regards,

Stephan.