On 17Apr2020 16:20, Paul Gilmartin <paulgboul...@aim.com> wrote:
On 2020-04-17, at 16:06:07, Fred Smith wrote:
My wife send me mail from aol.com with an attachment. when I received
the
mail the attachment's filename was gibberish, NOT what she viewed
when she sent it:
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?utf-8?B?Q09WSUQxOV9OZXdzbGV0dGVyX1Nlbmlvcl9DZW50ZXJfT3BlcmF0aW9uLnBkZg==?="
Content-ID: <ta4YlvHHUZs0ycPQvstq>
This is covered by RFC 5335:
https://tools.ietf.org/html/rfc5335
I think that specifies what AOL _should_ be doing (or could be doing).
But the extended UTF8-xtra syntax _isn't_ RFC2047 as used above.
(Besides, there are no nonASCII characters in the underlying filename -
it _should_ just appear in the clear, ungarbled.)
Also, doesn't RFC5335 require 8-bit clean transport because if
explicitly allows (and requires) nonASCII. See section 2:
https://tools.ietf.org/html/rfc5335#section-2
[...] This specification describes a change to the email message format
that is related to the SMTP message transport change described in the
associated document [RFC4952] and [RFC5336], and that allows non-ASCII
characters in most email header fields. These changes affect SMTP
clients, SMTP servers, mail user agents (MUAs), list expanders, gateways
to other media, and all other processes that parse or handle email
messages. [...]
Happy to have my thinking corrected if it is wrong.
Cheers,
Cameron Simpson <c...@cskk.id.au>
