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

...

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

On Thu, 28 Jul 2011 20:43:45 +0200 Stephan Bosch wrote:

On 07/26/2011 08:37 AM, Nikita Koshikov wrote:

...

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.

Yes. I read a bit about this though, and obviously this breaks bounce processing.

...

The right way for redirecting messages with sieve is to use SRS mechanism. And this should be configured on SMTP server.

Right.

...

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

Would the header name need to be configurable, or is X-Sieve-Redirected-From good for all purposes?

Regards,

Stephan.

I saw this

X-ResentFrom: X-SRS-Rewrite: X-Forwarded-(To/For):

So the name is not significant. If it's not so difficult to code - than configurable header of course is better. But it's only a matter of taste.

One thing to note for implementing: It will be much more simple for setting up srs, if sieve will export to environment some variables indicating need for rewrite. And than we will be able to write wrapper for sendmail_path that will selectively choose what should we do: For example, I don't want srs to happen if user is forwarding for local domain mailbox, or if action that trigger mail sending is - "out of office reply". So, wrapper will analyze need srs or no, and after all invoke srs binary for signing, or just call pure mta.

On Tue, 02 Aug 2011 16:43:13 +0200 Stephan Bosch wrote:

On 7/29/2011 8:53 AM, Nikita Koshikov wrote:

...

On Thu, 28 Jul 2011 20:43:45 +0200 Stephan Bosch wrote:

...

Would the header name need to be configurable, or is X-Sieve-Redirected-From good for all purposes? Regards, Stephan. I saw this

X-ResentFrom: X-SRS-Rewrite: X-Forwarded-(To/For):

So the name is not significant. If it's not so difficult to code - than configurable header of course is better. But it's only a matter of taste.

Adding more settings is best to be avoided. I've added the header:

http://hg.rename-it.nl/dovecot-2.0-pigeonhole/rev/81b37c0055c3 http://hg.rename-it.nl/dovecot-2.0-pigeonhole/rev/efad75f779de (d'oh)

...

One thing to note for implementing: It will be much more simple for setting up srs, if sieve will export to environment some variables indicating need for rewrite. And than we will be able to write wrapper for sendmail_path that will selectively choose what should we do: For example, I don't want srs to happen if user is forwarding for local domain mailbox, or if action that trigger mail sending is - "out of office reply". So, wrapper will analyze need srs or no, and after all invoke srs binary for signing, or just call pure mta.

I am not sure Sieve has access to enough information to make such an assessment. And I don't think adding SPF/SRS-specific code to Sieve is a good idea. It would also not be very straight-forward since the low-level mail sending code is part of Dovecot itself.

Regards,

Stephan.

I meant export to environment some variables, like dovecot does: USER= IP= MAIL= .... Adding more like: SIEVE_ACTION= SIEVE_RECIPIENT= etc And then execute sendmail_path. Thus program\wrapper can be aware of mail originated from sieve. This is not specific spf\srs code. Seemed, that this section of code need to be in dovecot-lda region, so maybe Timo will be able to catch it.

Thanks for your work.