Victor, John, and probably others,
(explicitly adding Jiankang and the ART ADs in case they not
been following this list closely.)
In addition to believing the text is probably right as it now
appears, I should be explicit about why I'm pushing back on
doing anything about this other that reassuming implementers who
use A-labels that no one is likely to call the Protocol Police.
The other reasons, and the more important ones, are completely
pragmatic. First, given the heavy dependencies of the SMTPUTF8
documents on RFCs 5321 and 5322 and that the latter are being
revised, I think it would not be helpful to revises the SMTPUTF8
documents until after we have finished with the revisions of the
base documents. As I assume others have noticed, those
revisions are not proceeding quickly... and, wherever the fault
lies, is it not with Pete or myself. Second, even if there is
sufficient energy to do serious work on email (and the rate of
progress in EMAILCORE could be interpreted as evidence to the
contrary), there is ample evidence (painful to me personally)
that there is little or none of the combined knowledge,
expertise, and energy to do serious i18n work. Revision of
these specs requires knowledge and interest in both (and, for
this particular case, specific knowledge and experience with
some of the subtle tradeoffs in IDNA2008). And finally, unless
I have misread the signals from the ADs, we are not likely to
see many (if any at all) no-WG, AD-sponsored standards track
documents about which there is any controversy. In the case,
the controversies are already clear from this fairly short
thread. So, unless someone is really to propose a WG and make a
serious suggestion about where the energy is going to come from
--especially when EMAILCORE is still going on-- well...
I would add to this disclaimer that my hope and expectation when
the EAI WG wound down was that fully conforming implementations
would deploy rapidly and extensively enough that, by the time we
got around to revising 5321 and 5322, we could just fold most of
those specs in, maybe talking about "minimal" and "recommended"
(i.e., fully internationalized) implementations. Silly me.
best,
john
--On Tuesday, May 25, 2021 15:32 -0400 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp