So, some backstory and explanation. For representing 8-bit characters in email headers, the encoding used is defined in RFC 2047. You've probably seen that at some point; it looks like:
=?UTF-8?Q?Hi!_=F0=9F=92=A9?= Those can be used in only a few places: in "text" in a Subject or Comment header, a MIME body part field where the field body is defined as "*text" (such as Content-Description ... and really, that's the only one), or as a replacement for a "word" in an email address in a place where an email address exists. Specifically, RFC 2047 says: + An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. For MIME parameters, they used an alternate encoding defined by RFC 2231. That looks like: name*=utf-8''Hi!%F0%9F%92%A9 (There's more if you have a long parameter name, but you get the idea). So, incompatible encoding. Fine. Nmh has supported RFC 2047 encoding for _decode_ for a long time; for 1.6 we added 2047 encoding, and support for RFC 2231 for both encoding and decoding. However ... nothing is ever simple. Specifically, there was a patch contributed (but later reverted) that enabled RFC 2047 decoding for some MIME parameters. The exact issue is that some MUAs will use RFC 2047 encoding for a filename that contains 8-bit characters when creating a Content-Disposition field. This was a problem with older versions of Outlook (like pre-2007), Lotus/IBM Notes (which I was surprised to discover was still a thing), but most troublesome, RFC 2047 encoding is ALSO used when you attach a filename with 8-bit characters when you use the web interface for Gmail. If you Google "rfc 2047 vs rfc2231" you can get an idea of what happened (Chrome and Thunderbird support it for decode, and Google uses that as justification for keeping it ... and Chrome and Thunderbird don't want to disable that support, because Gmail still uses it. Argh). I am torn as to what to do here. It feels somehow wrong to support this for decode natively, but I'm not completely convinced of that. We have a number of email programs that get this wrong, including a very popular one. This might be something perfect for mhfixmsg to deal with. What do others think? --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers