Mailing List Archive

> On May 4, 2021, at 2:48 PM, admin--- via Exim-dev <exim-dev@exim.org> wrote:
>
> https://bugs.exim.org/show_bug.cgi?id=2730
>
>
> RFC 6531 says you SHOULD do this. In IETF-ese "SHOULD" means MUST unless there
> is a compelling technical reason not to do it, not do this if you feel like it.
> (That's MAY.)
>
> It's not a huge bug but it looks easy to fix.

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,
which is only added on *final* delivery to a mailbox (possibly via
LMTP).

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.

Also "Return-Paths" in UTF8 form would rather hinder abuse reporting,
or other help from postmasters, ... when the script in question is
foreign to the mail system operators. Users, on the other hand, rarely
look at trace headers...

Thus section 3.7.3 of the RFC looks misguided to me, I would would be
tempted to ignore it with prejudice.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On 04/05/2021 23:59, Viktor Dukhovni via Exim-dev wrote:
>> On May 4, 2021, at 2:48 PM, admin--- via Exim-dev <exim-dev@exim.org> wrote:
>>
>> https://bugs.exim.org/show_bug.cgi?id=2730
>>
>>
>> RFC 6531 says you SHOULD do this. In IETF-ese "SHOULD" means MUST unless there
>> is a compelling technical reason not to do it, not do this if you feel like it.
>> (That's MAY.)
>>
>> It's not a huge bug but it looks easy to fix.
>
> It seems you're referring to:

[offlist]

Could you copy that to the bugzilla entry?
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

>> 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.

> 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? 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.

R's,
John

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

> On May 4, 2021, at 8:47 PM, John R. Levine via Exim-dev <exim-dev@exim.org> 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.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

It appears that Viktor Dukhovni via Exim-dev <exim-dev@exim.org> said:
>> 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.

No doubt, but the RFC says what it says. You know Yao, you can ask him
what the motivation was.

R's,
John

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##