Nick Simicich <njs @
> Just as a point: This is a really poorly thought out RFC. You might
> want to decode those in your MTA or mailing list manager before
> forwarding them to your subscribers. You *can't* safely do so.
Why do you want to do that? Certainly you're not allowed to do that
within that RFC because doing so would break the e-mail protocol. The
whole reason why RFC 2047 exists is because 8-bit characters are not
allowed in RFC 822 and RFC 2822 headers.
> The subject might or might not display there where it was moved into the
> body...or it might cause the content headers to become part of the body
> so that the mime decoding of the entire letter is hosed, depending on
> whether the subject line is before or after the critical headers.
No, it can't. Anything that decodes such a header in that fashion is
unbelievably broken. The parse of the message happens before the RFC 2047
decoding (and in fact it would be difficult to implement a system that did
it in the wrong order and was actually useful).
This is specifically noted in the RFC:
Only printable and white space character data should be encoded using
this scheme. However, since these encoding schemes allow the
encoding of arbitrary octet values, mail readers that implement this
decoding should also ensure that display of the decoded data on the
recipient's terminal will not cause unwanted side-effects.
NOTE: Decoding and display of encoded-words occurs *after* a
structured field body is parsed into tokens.
> Like I said, this is a real mess. No one thought about retaining a
> plain text section, since it seems that the attitude of many of the
> people who write the mime standards is that people should be forced to
> upgrade to the latest and greatest bit of mail display software, or get
> left in the dust. Or that maybe these augmented headers should be
> hidden somewhere.
Most use of RFC 2047 is in conjuction with text/plain. It works just
Russ Allbery (rra @