Quoting Timo Sirainen tss@iki.fi:
Anyway .. the BINARY APPEND converts only the MIME parts that you
send with "Content-Transfer-Encoding: binary". Are you sending such
header to Dovecot?
I don't think so. I noticed the CATENATE error when I was stripping a
simple text/html part out of a multipart/alternative message. The
"master" message header has a single MIME header:
Content-Type: multipart/alternative;
boundary="----WPFVNCCY4GPWDK6HNJXHWWE7J94BSS"
For the record, here's the entire transaction, along with the fallback
APPEND w/out using literal8 that was successful on the identical data:
C: 6 APPEND "INBOX" (\seen) "16-May-2013 22:05:14 -0600" CATENATE (URL
"/INBOX;UIDVALIDITY=1255685337/;UID=48812/;SECTION=HEADER" TEXT ~{40}
S: 6 NO [UNKNOWN-CTE] Binary input allowed only when the first part is binary.
C: 8 APPEND "INBOX" (\seen) "16-May-2013 22:05:14 -0600" CATENATE (URL
"/INBOX;UIDVALIDITY=1255685337/;UID=48812/;SECTION=HEADER" TEXT {40+}
C: [LITERAL DATA: 40 bytes]
C: URL "/INBOX;UIDVALIDITY=1255685337/;UID=48812/;SECTION=1.MIME" URL
"/INBOX;UIDVALIDITY=1255685337/;UID=48812/;SECTION=1" TEXT {40+}
C: [LITERAL DATA: 40 bytes]
C: TEXT {113+}
C: [LITERAL DATA: 113 bytes]
C: TEXT {42+}
C: [LITERAL DATA: 42 bytes]
C: )
S: 8 OK [APPENDUID 1255685337 48885] Append completed.
If a non-binary MIME part contains NUL, what is Dovecot supposed to
do? Change it to some other character? Fail the APPEND? Should there
be a difference between how literal vs literal8 is handled in such
case?
I would say there is no doubt: fail the APPEND. It should be the
client's responsibility to correctly format the data.
I appreciate that Dovecot does its best to try to Do The Right Thing
(Cyrus is much stricter about input, for example). But at some point
us client authors have to be at least somewhat competent, and it is
not asking to much for us to accept that GIGO.
michael