Ned,
Complete agreement. And thanks for reminding me/ us about the
additional details. An additional problem with at least the
ones of these Message-ID (and occasionally the mailbox addresses
in "From:" header fields) is that there is no "@" present in the
encoded form. So anything that follows the principle of parsing
before trying to do any decoding will fail; only those systems
that, contrary to the clear intend of the spec (for the reason
you give), decode everything that looks like an encoded word
before examining or parsing the relevant fields has even a
chance of imagining that these things are valid.
best,
john
--On Friday, March 6, 2020 08:37 -0800 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
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