On 30.4.2014, at 0.27, Michael M Slusarz <slus...@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