[Dovecot] BINARY FETCH conversion issue
Given this test message, with admittedly incorrect QP encoding:
From: Test <test@example.com> Subject: Test Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain To: Test <test@example.com> Date: Tue, 29 Apr 2014 00:54:10 +0000 Message-Id: <1@example.com>
https://example.com/?from=bsu&url=http%3A//www.example.com/
Dovecot 2.2 returns this:
C: 5 UID FETCH 4464 (BINARY.PEEK[1]) S: * 1 FETCH (UID 4464 BINARY[1] NIL) S: 5 OK Fetch completed.
Contrast with, e.g., Cyrus 2.4:
C: 6 UID FETCH 1 (BINARY.PEEK[1]) S: * 1 FETCH (UID 1 BINARY[1] {57} S: [LITERAL DATA: 57 bytes] S: ) S: 6 OK Completed (0.000 sec)
(Cyrus FETCH output strips out the spurious non-encoding '=', IIRC).
Not sure if this is an example of Cyrus' QP decoder being more robust
(or lenient) than Dovecot's. Or whether this is intentional to return
NIL for this kind of bad data.
Although if intentional, output should probably be a NO response with
UNKNOWN-CTE response code, since this appears to be an instance of
"the server does not know how to decode the section's CTE". (RFC 3516
[4.3]).
michael
On 30.4.2014, at 0.27, Michael M Slusarz <slusarz@curecanti.org> wrote:
Given this test message, with admittedly incorrect QP encoding: .. Dovecot 2.2 returns this:
C: 5 UID FETCH 4464 (BINARY.PEEK[1]) S: * 1 FETCH (UID 4464 BINARY[1] NIL) S: 5 OK Fetch completed.
Contrast with, e.g., Cyrus 2.4:
C: 6 UID FETCH 1 (BINARY.PEEK[1]) S: * 1 FETCH (UID 1 BINARY[1] {57} S: [LITERAL DATA: 57 bytes] S: ) S: 6 OK Completed (0.000 sec)
(Cyrus FETCH output strips out the spurious non-encoding '=', IIRC).
Not sure if this is an example of Cyrus' QP decoder being more robust (or lenient) than Dovecot's. Or whether this is intentional to return NIL for this kind of bad data.
It was kind of intentional. Dovecot's istream-qp-decoder aborts when it finds anything broken. I guess it could simply skip errors, but I'm not sure how good idea that is either..
Although if intentional, output should probably be a NO response with UNKNOWN-CTE response code, since this appears to be an instance of "the server does not know how to decode the section's CTE". (RFC 3516 [4.3]).
Yeah, I think that's better. Fixed: http://hg.dovecot.org/dovecot-2.2/rev/197f77f6ef0d
Also this fix more or less requires this: http://hg.dovecot.org/dovecot-2.2/rev/99f59d6fce05
Quoting Timo Sirainen <tss@iki.fi>:
On 30.4.2014, at 0.27, Michael M Slusarz <slusarz@curecanti.org> wrote:
Not sure if this is an example of Cyrus' QP decoder being more
robust (or lenient) than Dovecot's. Or whether this is intentional
to return NIL for this kind of bad data.It was kind of intentional. Dovecot's istream-qp-decoder aborts when
it finds anything broken. I guess it could simply skip errors, but
I'm not sure how good idea that is either..
I don't find it all that useful for a server to try to guess the best
decoding results.
Instead, I'd rather be told that the part is broken thus giving me the
option to download via a normal BODY FETCH ... since that allows me to
resolve the decoding issue locally however I want.
Although if intentional, output should probably be a NO response
with UNKNOWN-CTE response code, since this appears to be an
instance of "the server does not know how to decode the section's
CTE". (RFC 3516 [4.3]).Yeah, I think that's better. Fixed:
http://hg.dovecot.org/dovecot-2.2/rev/197f77f6ef0d
Thanks. I agree that this is the best solution.
michael
participants (2)
-
Michael M Slusarz
-
Timo Sirainen