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 stephan@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/**e439789e3211http://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.