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#...
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.