Le 15 janv. 2014 à 15:33, Axel Luttgens a écrit :
> [...]
>
> I'll try with 2.2.10 as soon as possible.
I anyway had to compile 2.2.10. ;-)
No more dubious header removal.
But but but...
Tried again, but now without a leading space at the beginning of the
"boundary=" line, i.e. with:
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
I received this one into my mailbox:
[...]
Content-Type: multipart/alternative;
Message-Id: <20140115150454.5A9E28FA2D3@ALMba.local>
Date: Wed, 15 Jan 2014 16:04:49 +0100 (CET)
From: me@some.domain
X-UID: 287477
Status:
X-Keywords:
Content-Length: 357
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 6
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
instead of:
[...]
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 5
Message-Id: <20140115144803.1C9FB8FA17A@ALMba.local>
Date: Wed, 15 Jan 2014 15:47:51 +0100 (CET)
From: me@some.domain
X-UID: 287476
Status:
X-Keywords:
Content-Length: 296
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
[...]
So, is could well be that you really are receiving messages without the
line-continuation character (the leading white space before "boundary=").
On the other hand, I guess the dovecot/pigeonhole behavior isn't the most
appropriate one when facing such a malformed message...
After removal of the single-line sieve script, thus allowing for direct
delivery into the recipient's mailbox, I get a similarly corrupted message.
One could thus infer that the source of the message's massaging is on dovecot's
side.
HTH,
Axel
