It would certainly be appropriate to either revise the spec or,
better from my point of view, create a short applicability
statement that explains the reasoning behind the SHOULD and the
circumstances under which it would be sensible to ignore it.
The thing that sometimes gets lost in "let's make the spec
conform to what implementations are doing" discussions in this
area is that there is an assumption behind the whole collection
of SMTPUTF8 specs, namely that the world really wanted non-ASCII
addressing and header field values. If that were true and
things had gone as quickly as the advocates predicted, then your
argument would not hold because the odds of the downstream
system in the scenario you describe not having support for the
extension would be low. If we are merely being slower than
expected getting there, then advising people to do something
that is sub-optimal for other reasons is a bad idea because it
is likely to just slow things down further.
Now, if, on the other hand, the reality were that no one is
going to fully implement SMTPUTF8 other than mail providers in a
few countries that intend to use it internally, then we should
probably be reconsidering the whole model --not just this
detail-- lest we end up with two mail systems and needing
gateways, possibly even gateways with serious downgrade and/or
encapsulation facilities between them.
Just my personal opinion, of course.
john
--On Monday, May 24, 2021 19:05 -0400 "John R. Levine"
<johnl(_at_)iecc(_dot_)com> 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.
In a situation like this, would it make sense in a future
update to the RFC to adjust the advice to the reality?
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp