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 -> mailbox
I 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--