Hi Stephan,

Attached is the configuration and both the original message as received (sieve redirect test.eml) and what it was like at the location where the redirect was received (1373811315.24616_23.niflheim:2,S)

Let me know if you need anything else to diagnose the problem.

Thanks, Anand

On 24 July 2013 07:12, Stephan Bosch <stephan@rename-it.nl> wrote:

On 7/24/2013 3:55 AM, Anand Kumria wrote:

...

I've noticed that the redirect sieve extension is placing an extra space before the headers of email when the 'redirect' command is used.

Unfortunately this break gmail, yahoo, and most other email programs.

I am using pigeonhole 0.4.0-14 with Dovecot 2.2.4.3; I see change

1781:e439789e3211 but it appears to only change how the X-Sieve header is generated.

I only have the one dovecot instance but I will note that the setting 'mail_save_crlf = yes' is specified.

Could you send us the following:

Output of dovecot -n More information on your MTA An example of a mangled message

Regards,

Stephan.

Hi Stephan,

On 24 July 2013 11:52, Stephan Bosch <stephan@rename-it.nl> wrote:

Op 7/24/2013 12:32 PM, Anand Kumria schreef:

Hi Stephan,

...

Attached is the configuration and both the original message as received (sieve redirect test.eml) and what it was like at the location where the redirect was received (1373811315.24616_23.niflheim:**2,S)

Let me know if you need anything else to diagnose the problem.

Bizarre. I haven't seen this before, I cannot reproduce it and I don't see how Sieve could be introducing additional spaces. Anything is possible, but are you sure this is caused by Sieve?

The only sieve script in use is:

if anyof( address :is "to" "akumria@acm.org", exists "List-ID") {

   redirect "wildfire@progsoc.org";
   keep;

}

Is `sieve redirect test.eml' the same as what is saved by Sieve using fileinto? I'm wondering what exact message is being passed to Sieve, since this problem could also be caused by the LMTP transfer.

I'm not sure what you mean by your first question, but from what I understand if there was no 'keep' in the above script I would not have a local copy.

As I said, my suspicions are on 'mail_crlf_save = yes', since that *is* specifically modifying the headers associated with the message.

Regards, Anand

Op 7/24/2013 3:30 PM, Stephan Bosch schreef:

Op 7/24/2013 1:04 PM, Anand Kumria schreef:

...

As I said, my suspicions are on 'mail_crlf_save = yes', since that *is* specifically modifying the headers associated with the message.

This setting has no effect on Sieve redirect since the message is not saved. However, redirect does use Dovecot functionality that filters headers and fixes line endings. What could be happening here is that the header of the message is somehow consolidated into one big Delivered-To header.

I'll discuss this some more with Timo.

As you suggested earlier, this change may have something to do with it:

http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/e439789e3211

The reporter of the bug that led to this change indicated that Exim presents strange behavior when the message mixes LF and CRLF line endings in the header. Since your next-hop MTA is also Exim, this may have the same root cause.

Please try to apply this change and see whether this problem persists. If this fixes it, I should make a new release soon.

When the problem persists, try to capture the outgoing message before it enters the MTA, e.g. by pointing sendmail_path to a shell script that saves the message somewhere. That way we can see what mail is actually being sent to the MTA.

Regards,

Stephan.

On 7/25/2013 8:06 AM, Anand Kumria wrote:

Hi Stephan,

I'm not sure, I'm using Dovecot-managesieved 0.4.0-14, which I believe is commit

1771:b41f5cf04b8f, which is actually *before* the commit you mentioned.

I'm not clear because you already have a release (v4.1) which does contain that patch; are you suggesting that an upgrade to that version might help?

Oh, right, it is already released. So, yes, upgrade.

Regards,

Stephan.