ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

2021-05-25 14:33:05
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