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? Regards, Anand On 24 July 2013 15:10, Stephan Bosch <step...@rename-it.nl> wrote: > 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<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. > > > >