On Mon, May 24, 2021 at 07:05:53PM -0400, John R. Levine wrote:
I've been doing some EAI tests. RFC 6531 section 3.7.3 says that domain
names in trace headers SHOULD all be U-labels. In practice, everyone uses
A-labels for reasons that are not absurd. The FROM clause has the name
from the EHLO command which has to be sent as A-labels, and it's quite
plausible to have a message where the message itself is entirely ASCII,
sent to a UTF-8 address, which then could be forwarded to an ASCII address
except that it has those U-labels in the trace header which would have to
be downgraded. I've talked to a couple of MTA maintainers who have told
me forget it, that's silly, not doing that.
Disclaimer: I'm one of the MTA maintainers who found the RFC advice in
question to be unworthy of implementation.
In a situation like this, would it make sense in a future update to the
RFC to adjust the advice to the reality?
Without daring to generalise to broader questions of whether/when the
spec or the implementations have the final say, on the particulars of
this specific case I think it is easy to conclude that it best to amend
the specification.
* The specification in question prescribes the format of some fields
of trace headers that most users will not see.
* The specifications causes the format used in the trace header to
differ from the actual data exchanged on the wire. These are the
client-to-server EHLO name and the server-to-client greeting name,
also repeated in the first line of the EHLO response.
Because both are exchanged prior to negotiation of SMTPUTF8, they
always in A-label form.
* The trace headers should match data recorded in system logs and
are mostly for the benefit of the postmaster. There's more value
in making them readable to any/all the postmasters along the
delivery path, than to those versed in the native tongue of the
message sender and ultimate recipients.
* It is possible that the message headers are all ASCII, and the
only presence of UTF8 is in the envelope, which may get rewritted
or narrowed in transit. By the time the message is delivered to
some mailboxes, the only non-ASCII content that might remain could
be the trace headers in question (if they follow the RFC).
Given that not all IMAP clients, MUAs, ... support EAI, the
conservative thing to do (a la Postel) is to not needlessly
inject UTF8 content into the message headers.
Therefore, I find the specific RFC text to be misguided, and not
only inessential to interoperability/utility, but actually working
against both. I am therefore inclined to ignore this part of the
RFC with prejudice. If there's an opportunity to revise (remove)
the text, that'd be great.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp