The main issue here is that encoded-words are are only defined in the
context of specific pieces of RFC 5322 syntax, and done in a way so that
they don't break the syntax. This is essential so that agents that don't
support RFC 2047 won't have a problem. So this business of encoding the
whole header field, which wrecks the syntax, is simply broken.
However, this doesn't mean something that things which meet the syntax criteria
for encoded words can't appear in other contexts. For example, nothing prevents
you from using an encoded word as a local-part of an address. But if you do,
its interpretation is just that of a local-part, which is a local matter by
definition. And it can't break the overall syntax of the field.
The larger problem is that a lot of agents blindly decode all the encoded words
they find in a field, rather than parsing first and only undoing the ones that
appear in specific places where they have meaning. This has the effect that a
lot of invalid encoded-word usage works, kinda sorta.
And yes, we were well aware that this would be a problem when the RFC was
written. The problem is every other approach we came up with had even bigger
issues. Keith deserves a lot of credit for this work.
Ned
On Fri, 6 Mar 2020, John C Klensin wrote:
> In the interest of clarity, what you are referring to as "MIME
> entities" are encoded words as specified in RFC 2231. Right?
Right.
> And because encoded words are not permitted in Message-IDs or
> the other fields you mention, those fields must conform to the
> specified syntax without decoding. If they don't, it is pretty
> much up to the receiving system what to do about it. ...
That was my understanding, too. I'm finding these MIME message-ID's in
the IETF's IMAP server, so now I'm wondering if they were in the original
message. Here's one that showed up today. I think they're all from
Microsoft.
https://mailarchive.ietf.org/arch/msg/last-call/xTEWTOyy4HOX-wyvFVaOicn2P-I/#
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp