Re: [Imap-protocol] Accessing the Content-Transfer-Encoding of a top-level multipart
Jan Kundrát <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday, 16 October 2013 22:44:55 CEST, Dave Cridland wrote: > Perhaps I'm misunderstanding, but isn't the CTE of any multipart/* 7bit by > definition? No, as per page 17 of RFC2045: Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded. And indeed, I'm seeing multipart/mixed with CTE: 8bit; they are produced by mlmmj mailing list moderation. The next paragraph is related to my fourth question: It should also be noted that, by definition, if a composite entity has a transfer-encoding value such as "7bit", but one of the enclosed entities has a less restrictive value such as "8bit", then either the outer "7bit" labelling is in error, because 8bit data are included, or the inner "8bit" labelling placed an unnecessarily high demand on the transport system because the actual included data were actually 7bit-safe. It doesn't answer what one might expect when dealing with such errors -- I know that's a difficulr question, though. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol