> I agree. 8BITMIME has largely failed (strictly speaking, announcing > 8BITMIME requires body rewrite features in mail relay software). We > should not introduce similar functionality, as an RFC for that will > be ignored, implemented incorrectly, or not implemented due to the > involved complexity. It's a different world now. At the time 8BITMIME was defined few MUAs supported MIME, but many could display 8bit text in message bodies as long as it wasn't MIME encoded, and sender and receiver happened to use the same character set. And given the demographics of the Internet at that time, there was at least a fair chance that both sender and receiver used iso-8859-1 (though many others were in use). At the present time most MUAs support MIME encoding. Essentially all MUAs that support utf-8 also support MIME; thus they are able to decode 2047 headers and use the proper character encoding for display. OTOH unlabeled 8bit text in message headers is not treated consistently across MUAs, and there are many more character sets in wide use than when 8BITMIME was defined. Though it is generally possible to distinguish between several of the popular encodings even without tagging, it's probably the case that header text encoded in 2047 is more likely to work with existing MUAs than unencoded utf-8. The real problem with 8BITMIME was that it essentially forced the MTA to make a guess about whether the recipient's MUA supported MIME. I agree that we don't want to do that again. MTAs should be encouraged to handle relayed messages as transparently as possible. However, the benefit in doing so is mostly for the long term. It still won't permit us to use unencoded utf-8 in message headers in the near term. Keith