dovecot - Apr 2014 - BINARY FETCH conversion issue

Given this test message, with admittedly incorrect QP encoding:

----
From: Test <test at example.com>
Subject: Test
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
To: Test <test at example.com>
Date: Tue, 29 Apr 2014 00:54:10 +0000
Message-Id: <1 at 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 at 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