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