Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't…

Página Inicial
Delete this message
Reply to this message
Autor: Viktor Dukhovni
Data:  
Para: exim-dev
Assunto: Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels
> On May 4, 2021, at 8:47 PM, John R. Levine via Exim-dev <exim-dev@???> wrote:
>
>>> https://bugs.exim.org/show_bug.cgi?id=2730
>
>> It seems you're referring to:
>>
>> https://tools.ietf.org/html/rfc6531#section-3.7.3
>>
>> When an SMTPUTF8-aware SMTP server adds a trace field to a message
>> that was or will be transmitted with the SMTPUTF8 parameter included
>> in the MAIL commands, that server SHOULD use the U-label form for
>> internationalized domain names in the new trace field.
>>
>> Which appears to be concerned primarily with the "Return-Path:" header,
>
> No, what I was testing was the domain names in Received headers, the FROM and BY clauses. Discussions in the IETF have told us that it is a religious issue whether you consider Return-Path to be a trace field.


I see, but the domains in question are:

   * "from": The EHLO name sent by the peer before SMTPUTF8 is announced,
             So necessarily ASCII.
   * "by":   The receiving system name announced in the SMTP greeting also
             before SMTPUTF8 is announced, so again necessarily ASCII.


If the specification in 3.7.3 expects these to be transformed to Unicode
in the trace headers even though they're sent and received as A-labels
in the actual SMTP dialogue, then I am not impressed by the specification.

>> In that context, use of non-ASCII domain forms may needlessly break
>> message delivery, if the mailstore does not support non-ASCII headers,
>> and UTF8 would not otherwise appear in the message headers.
>
> If UTF8 would not otherwise appear in the message headers, why would the mail be sent as SMTPUTF8?


It needs to be declared SMTPUTF8 when any of the envelope addresses are UTF8.
If those are Bcc addresses, or the headers have been rewritten to no longer
use UTF8, then the message content may be free of UTF8, leaving UTF8 in just
the (at least incoming) envelope.

> That doesn't strike me as a very strong argument.
>
> Like I said, it's not a huge bug, but the spec is clear enough.


The spec is clear, but likely misguided, just like the 552 -> 452
downgrade in 5321, which nobody implements, because it is misguided.

-- 
    Viktor.