On 30.4.2014, at 0.27, Michael M Slusarz <[email protected]> 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
