[Dovecot] Pigeon Sieve, redirect action and SPF

[Nikita Koshikov]

On Tue, 26 Jul 2011 01:13:36 +0200
Stephan Bosch wrote:

> 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.
> 
I have raised this problem earlier here (http://www.mail-archive.com/dovecot@dovecot.org/msg20945.html), but seems it stuck at that point. 

The simple way, is to use redirecting user mail_from, so messages will appear like originated from redirecting smtp server.

The right way for redirecting messages with sieve is to use SRS mechanism. And this should be configured on SMTP server. The problem is when sieve exec sendmail_path smtp server has no clue about "redirect" recipient( user who wrote the sieve script) and srs can't be configured. So adding one more header when redirecting sieve message with original sender will be half of the work - another part it to set up smtp for understanding this header and construct new 'mail from:' address in appropriative way(something like srs0_forward_user-fuzzy_staff-orig.address at forwarded_domain. Exact format should be determine.). Maybe this will be hard to setup, but we at least have something(original sender address and forwarded one) and this is another story...