[Dovecot] forwarded message is broken in 2.2.10 with pigeonhole-0.4.2
Hi, forwarding a message with sieve like
redirect:copy "me@other.domain";
was working without any problem until dovecot-2.1.17, dovecots lmtp and dovecot-2.1-pigeonhole-0.3.5.
Using dovecot-2.2.10 , dovecots lmtp and dovecot-2.2-pigeonhole-0.4.2 the structure of a forwarded message is broken. Content of a message is not displayed or an attachment (for instance pdf) can not be opened by (different) clients. Writing a html mail or plain one makes no different.
I have compared two messages and the main different is a missing
Content-Type: multipart/alternative; boundary="...."
to encapsulate the body of the forwarded message. Was it lost in sieve?
Here parts of a "well" forwarded message:
Return-Path: ... ... Received: by mails.cms.hu-berlin.de (Postfix, from userid 29) id A78C738734; Tue, 14 Jan 2014 17:10:54 +0100 (CET) X-Sieve: Pigeonhole Sieve 0.3.5 X-Sieve-Redirected-From: schmidt@mails.cms.hu-berlin.de Delivered-To: <schmidt@mails.cms.hu-berlin.de> Received: from mails.cms.hu-berlin.de by suncom1 (Dovecot) with LMTP id p8HoIn9h1VKnTwAA9XuJ/g for <schmidt@mails.cms.hu-berlin.de>; Tue, 14 Jan 2014 17:10:54 +0100 ... Message-ID: <52D5618D.6050905@gmail.com> Date: Tue, 14 Jan 2014 17:10:53 +0100 From: xy <xy@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: schmidt@hu-berlin.de Subject: from gmail with attachment Content-Type: multipart/mixed; boundary="------------070108020005050001040207" X-ENVELOPE-TO: <me@other.domain> This is a multi-part message in MIME format. --------------070108020005050001040207 Content-Type: multipart/alternative; boundary="------------090806050202050708030507"
--------------090806050202050708030507 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit
Hallo.
text
--------------090806050202050708030507 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
<html> <head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hallo.<br> <br> <u>text</u><br> <br> P.<br> </body> </html>
--------------090806050202050708030507--
--------------070108020005050001040207 Content-Type: application/pdf; name="auftrag-2014-eng-Hinweise.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="auftrag-2014-eng-Hinweise.pdf"
JVBERi0xLjYNJeLjz9MNCjcyIDAgb2JqDTw ... ... c3RyZWFtDWVuZG9iag1zdGFydHhyZWYNCjExNg0KJSVFT0YNCg== --------------070108020005050001040207-- message end
Now a broken message without "Content-Type: multipart/alternative;":
Return-Path: ... ... Received: by mail5.cms.hu-berlin.de (Postfix, from userid 29) id 47C4C6D46E; Tue, 14 Jan 2014 17:43:54 +0100 (CET) X-Sieve: Pigeonhole Sieve 0.4.2 X-Sieve-Redirected-From: testuser@mail5.cms.hu-berlin.de Delivered-To: <testuser@mail5.cms.hu-berlin.de> Received: from mail5.cms.hu-berlin.de by suncom5 (Dovecot) with LMTP id mnY0AEpp1VLsaQAA0tuC1A for <testuser@mail4.cms.hu-berlin.de>; Tue, 14 Jan 2014 17:43:54 +0100 ... Message-ID: <52D56948.1090704@gmail.com> Date: Tue, 14 Jan 2014 17:43:52 +0100 From: xy <xy@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: testuser@hu-berlin.de Subject: from gmail with attachment Content-Type: multipart/mixed; boundary="------------030506080302040201020604" X-ENVELOPE-TO: <me@other.domain>
This is a multi-part message in MIME format. --------------030506080302040201020604 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit
text.
--------------030506080302040201020604 Content-Type: application/pdf; name="auftrag-2014-eng-Hinweise.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="auftrag-2014-eng-Hinweise.pdf"
JVBERi0xLjYNJeLjz... ... c3RyZWFtDWVuZG9iag1zdGFydHhyZWYNCjExNg0KJSVFT0YNCg== --------------030506080302040201020604-- message end
-- Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
Le 15 janv. 2014 à 10:17, Burckhard Schmidt a écrit :
Hi, forwarding a message with sieve like
redirect:copy "me@other.domain";
was working without any problem until dovecot-2.1.17, dovecots lmtp and dovecot-2.1-pigeonhole-0.3.5.
Using dovecot-2.2.10 , dovecots lmtp and dovecot-2.2-pigeonhole-0.4.2 the structure of a forwarded message is broken. Content of a message is not displayed or an attachment (for instance pdf) can not be opened by (different) clients. Writing a html mail or plain one makes no different.
I have compared two messages and the main different is a missing
Content-Type: multipart/alternative; boundary="...."
to encapsulate the body of the forwarded message. Was it lost in sieve?
Hello Burckhard,
Just to be sure. Above excerpt and your two sample messages invariably show "boundary=" items starting at the beginning of a new line. Is this really the case?
Axel
Am 15.01.2014 13:15, schrieb Axel Luttgens:
Le 15 janv. 2014 à 10:17, Burckhard Schmidt a écrit :
Hi, forwarding a message with sieve like
redirect:copy "me@other.domain";
was working without any problem until dovecot-2.1.17, dovecots lmtp and dovecot-2.1-pigeonhole-0.3.5.
Using dovecot-2.2.10 , dovecots lmtp and dovecot-2.2-pigeonhole-0.4.2 the structure of a forwarded message is broken. Content of a message is not displayed or an attachment (for instance pdf) can not be opened by (different) clients. Writing a html mail or plain one makes no different.
I have compared two messages and the main different is a missing
Content-Type: multipart/alternative; boundary="...."
to encapsulate the body of the forwarded message. Was it lost in sieve?
Hello Burckhard,
Just to be sure. Above excerpt and your two sample messages invariably show "boundary=" items starting at the beginning of a new line. Is this really the case?
Axel
Sorry, I lost the leading space by cut/paste.
-- Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
Le 15 janv. 2014 à 13:19, Burckhard Schmidt a écrit :
[...] Sorry, I lost the leading space by cut/paste.
Fine, thank you for the clarification.
Could you try something along these lines:
redirect "me@other.domain";
keep;instead of:
redirect:copy "me@other.domain";and see whether the mime info disappears as well?
Axel
Am 15.01.2014 13:52, schrieb Axel Luttgens:
Le 15 janv. 2014 à 13:19, Burckhard Schmidt a écrit :
[...] Sorry, I lost the leading space by cut/paste.
Fine, thank you for the clarification.
Could you try something along these lines:
redirect "me@other.domain"; keep;
instead of:
redirect:copy "me@other.domain";
and see whether the mime info disappears as well?
Axel
That does not help, still missing a Content-Type: multipart/alternative;
Burckhard
-- Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
Le 15 janv. 2014 à 14:50, Burckhard Schmidt a écrit :
Am 15.01.2014 13:52, schrieb Axel Luttgens:
Le 15 janv. 2014 à 13:19, Burckhard Schmidt a écrit :
[...] Sorry, I lost the leading space by cut/paste.
Fine, thank you for the clarification.
Could you try something along these lines:
redirect "me@other.domain"; keep;
instead of:
redirect:copy "me@other.domain";
and see whether the mime info disappears as well?
Axel
That does not help, still missing a Content-Type: multipart/alternative;
Hello Burckhard,
Quickly tried here with dovecot 2.2.8/pigeonhole 0.4.2, and couldn't reproduce the problem with either
Content-Type: multipart/alternative; boundary=20cf302234d5b8063c04efcd4318or
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318in the message headers.
The script being a single-line one:
redirect "me@other.domain";I'll try with 2.2.10 as soon as possible.
Axel
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=20cf302234d5b8063c04efcd4318I 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-1instead 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
Am 15.01.2014 16:40, schrieb Axel Luttgens:
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.
interesting! I tryed to look into the message before and after redirection. I set the message on hold (postfix) to have a look into the original message. I'm not familiar with the format inside the queue:
This is shown (using vim) as one line: Subject: 3N^^Content-Type: multipart/mixed;N0 boundary="------------000804020208020000000909"N^@N,This is a mult...
between "...mixed;N0 boundary..." is a space like expected.
Next view after redirect:copy "..." I have the redirected message in the queue (vim again):
^_X-Sieve: Pigeonhole Sieve 0.4.2N=X-Sieve-Redirected-From:... ... Again, between "...mixed,N0 boundary..." is a space like expected: Subject: 3N^^Content-Type: multipart/mixed;N0 boundary="------------000804020208020000000909"N^@N-This is a multi-part message in MIME format.^MN'--------------000804020208020000000909^MN=Content-Type: text/plain; charset=ISO-8859-15; format=flowed^MN Content-Transfer-Encoding: 7bit^MN^A^MN^Ganbei.^MN^A^MN'--------------000804020208020000000909^MN^_Content-Type: application/pdf;^MN& name="auftrag-2014-eng-Hinweise.pdf"^MN"Content-Transfer-Encoding: base64^MN!Content-Disposition: attachment;^MN* filename="auftrag-2014-eng-Hinweise.pdf"^MN^A^M
There is no Content-Type: multipart/alternative; inside the message after redirect.
Regards - Burckhard
Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 15 Jan 2014, Axel Luttgens wrote:
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> 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>
--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...
Well, you recieve the message text:
keyword: body keyword: body nokeyword keyword: body <<empty line>> message body
The line "nokeyword" violates RFC. I wonder why your MTA delivers the message at all.
Pigeonhole stops parsing headers at nokeyword, OK. One could probably ignore that broken line instead, but if for some reason the empty line got screwed, one would parse stuff nobody knows where it's from. But if Pigeonhole would believe nokeyword is a continueation of the previous line and unfold it, you open for attacks, IMHO.
The message without the leading space in the cont line should look as "raw"/malformed in any mail client. I think Dovecot/Pigeonhole is correct to stop parsing headers after seeing a malformed header line.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUtbFJnD1/YhP6VMHAQKZHggA19M+CJR8p2OeAt16a6XhxmMNrnNT//MD iukjdeRBFBUIR3MNlSVPP0K3L5fRgdc6tUpfnAMTb6i4pbFRCR7jHHp6xpWDyCic 2M3z2xUuo/AAYDWJiWfs7WUADWDAswvXkEtY714JN63e1Pi4374uI1MxJWCZI5xO 2gsEXrkudBwRhGAlG+3q3cXYqu7AzzZq4ZIKM3L9r/BS0Nlv9uCznibHZMhu9uUI C7rq2Gs3fNo5p95RZ30OdFRKRTn85AzBP7jKR5jW2ugN7ILxZYQC8WmQZ7nxEW6H ShR/QigU0pcrLiLC+S/3ZO1R0aSqbC2DNV9VyVGmvLVrC/tD/SnX4Q== =gmoU -----END PGP SIGNATURE-----
Le 15 janv. 2014 à 18:28, Steffen Kaiser a écrit :
[...] Well, you recieve the message text:
keyword: body keyword: body nokeyword keyword: body <<empty line>> message body
Yes, I was trying to reproduce Burckhard's problem by voluntarily omitting the line-continuation character (hence the above "nokeyword").
The line "nokeyword" violates RFC.
Indeed. ;-)
I wonder why your MTA delivers the message at all.
Good question...
In fact, I was precisely trying to understand where exactly the massaging could happen, when your message arrived.
In my previous trials, I did a "telnet 127.0.0.1 25" for sending my bogus message; that meant:
postfix -> dovecot's lmtp -> mailboxI then tried something I should have tried before posting: a telnet directly to lmtp.
In that case, the bogus message is delivered *as is*, without spurious re-ordering nor removal.
I'm reproducing those trials at the end of this message.
So, it looks like postfix could somehow be blamed, not dovecot as I perhaps erroneously wrote. (more precisely, postfix-2.11-20130327, which I should probably replace anyway here on my testbed) My apologies...
Pigeonhole stops parsing headers at nokeyword, OK.
Well, yes and no...
I've just retried with a redirect to "her@some.domain", still through a telnet against lmtp:
lmtp -> mailbox (with sieve redirect)And it appears that the message headers are now mangled, with exactly the same pattern as in the case of:
postfix -> dovecot's lmtp -> mailbox (without sieve redirect)Not sure how to interpret such results...
But it seems that pigeonhole isn't neutral, and doesn't stop its parsing at the bogus header.
One could probably ignore that broken line instead, but if for some reason the empty line got screwed, one would parse stuff nobody knows where it's from. But if Pigeonhole would believe nokeyword is a continueation of the previous line and unfold it, you open for attacks, IMHO.
Agreed, would be quite silly. ;-)
The message without the leading space in the cont line should look as "raw"/malformed in any mail client. I think Dovecot/Pigeonhole is correct to stop parsing headers after seeing a malformed header line.
Either I'm doing something terribly wrong, or there's something really worth to be investigated. Something that could be, at least partially, related to the problem described by Burckhard.
Axel
==========
When talking to postfix:
$ telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ALMba.local ESMTP Postfix
mail from:<her@some.domain>
250 2.1.0 Ok
rcpt to:<me@some.domain>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 9
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--
.
250 2.0.0 Ok: queued as 288A68FAB93
quit
221 2.0.0 Bye
Connection closed by foreign host.this one is written into the mailbox:
From her@some.domain Wed Jan 15 18:53:29 2014
Return-Path: <her@some.domain>
Delivered-To: <me@some.domain>
Received: from ALMba.local
by almba.local (Dovecot) with LMTP id ibRXLxnL1lIPUgEA5Q0ykw
for <me@some.domain>; Wed, 15 Jan 2014 18:53:29 +0100
Received: from localhost (localhost [127.0.0.1])
by ALMba.local (Postfix) with SMTP id 288A68FAB93
for <me@some.domain>; Wed, 15 Jan 2014 18:52:48 +0100 (CET)
Content-Type: multipart/alternative;
Message-Id: <20140115175257.288A68FAB93@ALMba.local>
Date: Wed, 15 Jan 2014 18:52:48 +0100 (CET)
From: her@some.domain
X-UID: 6
Status:
X-Keywords:
Content-Length: 357
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 9
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--On the other hand, when talking directly to lmtp:
$ telnet /_ROOT/var/run/dovecot/lmtp
Trying /_ROOT/var/run/dovecot/lmtp...
Connected to (null).
Escape character is '^]'.
220 almba.local Dovecot ready.
mail from:<her@some.domain>
250 2.1.0 OK
rcpt to:<me@some.domain>
250 2.1.5 OK
data
354 OK
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 8
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--
.
250 2.0.0 <me@some.domain> cKl7H4LH1lKZUQEA5Q0ykw Saved
quit
221 2.0.0 OK
Connection closed by foreign host.the mailbox receives:
From her@some.domain Wed Jan 15 18:39:16 2014
Return-Path: <her@some.domain>
Delivered-To: <me@some.domain>
Received: from missing
by almba.local (Dovecot) with LMTP id cKl7H4LH1lKZUQEA5Q0ykw
for <me@some.domain>; Wed, 15 Jan 2014 18:38:54 +0100
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 8
X-UID: 5
Status:
X-Keywords:
Content-Length: 296
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--Now, telnetting lmtp with a sieve redirect:
$ telnet /_ROOT/var/run/dovecot/lmtp
Trying /_ROOT/var/run/dovecot/lmtp...
Connected to (null).
Escape character is '^]'.
220 almba.local Dovecot ready.
mail from:<her@some.domain>
250 2.1.0 OK
rcpt to:<me@some.domain>
250 2.1.5 OK
data
354 OK
Content-Type: multipart/alternative;
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 10
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--
.
250 2.0.0 <me@some.domain> mBR9CJgC11L2UgEA5Q0ykw Saved
quit
221 2.0.0 OK
Connection closed by foreign host.yields this one into the mailbox:
From her@some.domain Wed Jan 15 22:51:09 2014
Return-Path: <her@some.domain>
Delivered-To: <her@some.domain>
Received: from ALMba.local
by almba.local (Dovecot) with LMTP id Uc+AFM0C11IGUwEA5Q0ykw
for <her@some.domain>; Wed, 15 Jan 2014 22:51:09 +0100
Received: by ALMba.local (Postfix, from userid 1003)
id 4A8408FAE7B; Wed, 15 Jan 2014 22:51:09 +0100 (CET)
X-Sieve: Pigeonhole Sieve 0.4.2
X-Sieve-Redirected-From: me@some.domain
Delivered-To: <me@some.domain>
Received: from missing
by almba.local (Dovecot) with LMTP id mBR9CJgC11L2UgEA5Q0ykw
for <me@some.domain>; Wed, 15 Jan 2014 22:50:38 +0100
Content-Type: multipart/alternative;
Message-Id: <20140115215109.4A8408FAE7B@ALMba.local>
Date: Wed, 15 Jan 2014 22:51:09 +0100 (CET)
From: her@some.domain (Dovecot)
X-UID: 287478
Status:
X-Keywords:
Content-Length: 358
boundary=20cf302234d5b8063c04efcd4318
Subject: sieve test 10
--20cf302234d5b8063c04efcd4318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello
--20cf302234d5b8063c04efcd4318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<b>Hello!</b>
--20cf302234d5b8063c04efcd4318--Le 15 janv. 2014 à 23:29, Axel Luttgens a écrit :
[...]
Pigeonhole stops parsing headers at nokeyword, OK.
Well, yes and no...
I've just retried with a redirect to "her@some.domain", still through a telnet against lmtp:
lmtp -> mailbox (with sieve redirect)
And it appears that the message headers are now mangled, with exactly the same pattern as in the case of:
postfix -> dovecot's lmtp -> mailbox (without sieve redirect)
Not sure how to interpret such results...
I must have been very tired when writing the last sentence.
The message went back thru postfix, and has thus been submitted to postfix' parsing rules (depending on its settings).
But it seems that pigeonhole isn't neutral, and doesn't stop its parsing at the bogus header.
Or maybe could it be said that it is very neutral, in the sense that the bogus message is passed as is?
Axel
Am 15.01.2014 10:17, schrieb Burckhard Schmidt:
Hi, forwarding a message with sieve like
redirect:copy "me@other.domain";
was working without any problem until dovecot-2.1.17, dovecots lmtp and dovecot-2.1-pigeonhole-0.3.5.
Using dovecot-2.2.10 , dovecots lmtp and dovecot-2.2-pigeonhole-0.4.2 the structure of a forwarded message is broken. Content of a message is not displayed or an attachment (for instance pdf) can not be opened by (different) clients. Writing a html mail or plain one makes no different.
I did another test with dovecot-lda instead of lmtp:
dovecot 2.2.10, dovcot-lda and pigeonhole-0.4.2 --> Message is forwarded and fully readable. dovecot 2.2.10, lmtp and pigeonhole-0.4.2 --> forwarded message is broken If I compare both messages I see trailing blanks like
... Subject: anhang pdf Content-Type: multipart/mixed; without trailing blank ... X-ENVELOPE-TO: <me@other.domain> blank line here --> and now every line until the end of the message has one trailing blank, starting with: This is a multi-part message in MIME format. --------------060501050100070603080402 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit
test text
--------------060501050100070603080402 Content-Type: application/pdf; name="oxford-google-docs.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="oxford-google-docs.pdf"
JVBERi0xLjQKJeHp69MKMiAwIG9iago8PC9UeXBlIC9DYXRhbG9nCi9QYWdlcyAxIDAgUgo+ ... dGFydHhyZWYKNTMyMzcKJSVFT0Y= --------------060501050100070603080402-- end of message
This should be the reason I think.
Burckhard
-- Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
Am 16.01.2014 10:31, schrieb Burckhard Schmidt:
Am 15.01.2014 10:17, schrieb Burckhard Schmidt:
Hi, forwarding a message with sieve like
redirect:copy "me@other.domain";
was working without any problem until dovecot-2.1.17, dovecots lmtp and dovecot-2.1-pigeonhole-0.3.5.
Using dovecot-2.2.10 , dovecots lmtp and dovecot-2.2-pigeonhole-0.4.2 the structure of a forwarded message is broken. Content of a message is not displayed or an attachment (for instance pdf) can not be opened by (different) clients. Writing a html mail or plain one makes no different.
Finally I switched to a newer version of postfix. This solved my problem. I happened with version 2.8.9, 2.9.4. works now.
Thanks to Alex for support!
Burckhard
-- Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation ZE Computer- und Medienservice der Humboldt-Universität zu Berlin Postanschrift: Unter den Linden 6, 10099 Berlin Standort: Rudower Chaussee 26; 12489 Berlin Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959 Mail: bschmidt@cms.hu-berlin.de
participants (3)
-
Axel Luttgens
-
Burckhard Schmidt
-
Steffen Kaiser