Subject: I18ndir last call review of draft-ietf-dmarc-eaiauth-03

From: Martin Dürst via Datatracker <[email-masked]>
Date: Thu, 14 Mar 2019 02:55:21 -0700

Reviewer: Martin Dürst
Review result: Ready with Issues

I am the assigned Internationalization Directorate (i18ndir) reviewer for this
draft. Harald Alvestrand and Pete Resnik contributed to this review.

The Internationalization Directorate has been formed only recently,
and has not yet established a review template or an FAQ.
The review is intended to concentrate on internationalization issues,
but is not limited to such issues.

Please treat these comments just like any other last call comments.

General:
=======

It's good that this document is being done, EAI can only work better if
it's clear where in the infrastructure U-labels are to be used, and
where A-labels, and what happens with non-ASCII LHS.

It's a pity that there are not more places where U-labels are used, but
that may be difficult to change.

Major/intermediate issues:
=========================

The Abstract mentions the Authentication-Results header field, but the
text doesn't.

Section 4, %{s} and %{l} macros in SPF: The draft says that these cannot
be used for local parts that contain non-ASCII characters. This may be
enough for this draft, but is this a problem that should be fixed in the
longer term? How widely are %{s} and %{l} macros used currently?

Section 5, grammar of dkim-safe-char: This adds all of Unicode
(therewith not including overlong encodings or surrogates), which is
probably the best thing that can be done in the grammar; any try to eliminate
e.g. non-characters, characters with control functions, invisible characters,
unassigned code points, private-use code points, and the like would be very
difficult. But there should be a warning about this in the security section.

It may be appropriate to give a warning to implementers that they have
to make sure that for internationalized messages, the DKIM signatures
are calculated on UTF-8 strings. My assumption is that this should just
work with the usual signature algorithms and the usual APIs, but some
implementations may use special checks or so that would cause problems.

Minor issues:
============

In Abstract, fix "Authentication-Results header" ->
"Authentication-Results header field"

1. Introduction:

This should start with a short section listing the documents/definitions
that the reader is supposed to be familiar with.

"unencoded message bodies": Does this mean message bodies in ASCII only?
I'm not sure this needs special mention; A-labels would also be needed
e.g. for Korean domains in a message body encoded as Shift_JIS.

"Internationalized mail also allows UTF-8 characters": There are no
UTF-8 characters. There are ((non-ASCII) Unicode) characters encoded
as/in UTF-8. Please fix. (several places)

2. Definitions:

    The term IDN, for Internationalized Domain Name, refers to a domain
    name containing either U-labels or A-labels.
What about domain names with mixed U-labels and A-labels?

The draft says:
   Since DMARC is not currently a standards track protocol, this
   specification offers advice rather than requirements for DMARC.
but then the abstract says
   This specification updates the SPF, DKIM, and DMARC
   specifications
and the DMARC section (section 6) looks as if it's just as normative as
the others.
Either way may be fine (allowing informationals
to be updated is not a bad idea), but it should be self-consistent.

Section 5 repeatedly uses the term "internationalized messages", but it
doesn't seem to be defined. The intent seems to be to refer to messages
with RFC 6532 headers (which are called "internationalized email
headers" in RFC 6532; it uses the term "internationalized messages" only
in the context of message/global).

In section 5, please consider referencing RFC 5982.

6. DMARC ...

This would be easier to read, in particular for outsiders, if special
terms such as "RFC5322.From", "rua", and "ruf" were quoted.

Nits:
====

Please fix capitalization of headers (e.g. General principles -> General
Principles).

"This rule is
    relaxed only for headers in internationalized messages [RFC6532] so
    IDNs SHOULD be represented as U-labels but MAY be A-labels."
is a bit difficult to read. I'd propose a rewrite along the following lines:
"This rule is
    relaxed only for headers in internationalized messages [RFC6532].
    In such headers, IDNs SHOULD be represented as U-labels but MAY
    be represented as A-labels."

"Field names are restricted to printable ASCII (see
    [RFC5322] section 3.6.8) so this case conversion remains the usual
    ASCII conversion."
->
"Field names are restricted to printable ASCII (see
    [RFC5322] section 3.6.8) so this case conversion remains limited to
    ASCII characters."
(We don't want to give the impression that non-ASCII characters are unusual;
they are not.)

"Since a policy record can
    be used for both internationalized and conventional mail, those
    addresses still have to be conventional addresses, not
    internationalized addresses."
->
"Since a policy record can
    be used for both internationalized and conventional mail, those
    addresses still have to be ASCII-only addresses, not
    internationalized addresses."
(We don't want to give the impression that addresses with non-ASCII characters
are non-conventional.)

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 14 Mar 2019 13:38:02 -0700

Replying to one question posed below. Eliding the other content...

On Thu, Mar 14, 2019 at 2:55 AM Martin Dürst via Datatracker <
[email-masked]> wrote:

> <elided>

> Major/intermediate issues:

Based on a dataset that is currently a couple of years old, surveying about
12M domains that were in current use at that time, there were 75 using the
%{s} macro and 139 using %{l}. So I think it's a safe generalization to say
that they are not widely used. From a cursory inspection, it appears that
the general use case is for logging anomalies through query records
employing the "exists" SPF mechanism.

--Kurt Andersen

---

From: "John Levine" <[email-masked]>
Date: 19 Mar 2019 16:57:28 -0400

In article <[email-masked]> you write:

Here's a terminology question.

>(We don't want to give the impression that addresses with non-ASCII characters

What do we call mail that's not EAI mail?  It's not ASCII mail, since
non-EAI messages can contain any character sets you want in the
message body.

Some people call it legacy mail which seems kind of jumping the gun.

R's,
John

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 20 Mar 2019 03:09:09 +0000

Hello John,

Thanks for your followup to the I18N directorate's review of your draft.

Copying the EAI mailing list, since they might have some ideas.

On 2019/03/20 05:57, John Levine wrote:
> What do we call mail that's not EAI mail?

Maybe just that, 'non-EAI mail'? Or something like "mail that needs the 
SMTPUTF8 extension for transmission"? Or "mail with non-ASCII addresses"?

> It's not ASCII mail, since

And in comments in headers, if properly encoded.

> Some people call it legacy mail which seems kind of jumping the gun.

I wish we could use that term, but I agree it's a bit early. Also, even 
if it were appropriate now, it's not precise enough.

Regards,   Martin.

---

From: "John R Levine" <[email-masked]>
Date: 19 Mar 2019 23:14:13 -0400

> SMTPUTF8 extension for transmission"? Or "mail with non-ASCII addresses"?

Non-EAI seems simple enough.

>> It's not ASCII mail, since non-EAI messages can contain any character 
>> sets you want in the message body.

> And in comments in headers, if properly encoded.

With 8BITMIME, which is supported by pretty much every MTA in the world, 
UTF-8 message bodies don't need to be encoded.  They can include literal 
UTF-8 or any other character set that interprets ASCII CR/LF as CR/LF.

I have an updated version of the draft, will post it once the window 
reopens.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 20 Mar 2019 04:17:44 +0000

> UTF-8 or any other character set that interprets ASCII CR/LF as CR/LF.

Yes, I know of course.

> I have an updated version of the draft, will post it once the window 

Great, looking forward to it.

Regards,   Martin.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 20 Mar 2019 08:05:40 +0100

On 19 Mar 2019, at 21:57, John Levine wrote:

> What do we call mail that's not EAI mail?  It's not ASCII mail, since non-EAI messages can contain any character sets you want in the message body.

And in the headers, including in the name in the email address...

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 20 Mar 2019 11:01:53 -0400

>> non-EAI messages can contain any character sets you want in the message 
>> body.

> And in the headers, including in the name in the email address...

No, not really.  In non-EAI mail, the headers are all ASCII, even though 
some of that ASCII may be MIME encodings of UTF-8.  On systems that 
support 8BITMIME (all of them, these days) the body can contain literal 
unencoded UTF-8 in the body parts, although the MIME headers between the 
body parts are still ASCII.

In EAI mail, the headers and the body part MIME headers can contain UTF-8 
just abuout everywhere other than the field names.

Regards,

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 21 Mar 2019 07:15:39 +0100

On 20 Mar 2019, at 16:01, John R Levine wrote:

> No, not really.  In non-EAI mail, the headers are all ASCII, even though some of that ASCII may be MIME encodings of UTF-8.  On systems that support 8BITMIME (all of them, these days) the body can contain literal unencoded UTF-8 in the body parts, although the MIME headers between the body parts are still ASCII.

Ok, I was sloppy in my wording.

If the email client do understand MIME and handle that correctly, one can have non-ascii in headers and not only the body already since...hmmm...1991. Thats only 28 years. :-)

> In EAI mail, the headers and the body part MIME headers can contain UTF-8 just abuout everywhere other than the field names.

Yes, but for me, if you can encode things and then decode in a non-destructive way, I call that support.

What EAI is doing is to add the ability to have non-ascii in the email address. YMMV regarding how important that is.

Personally I see it as one of the largest mistakes and issues with email that people try to have their name as local part in an email address, as that gives the ability for people to guess email addresses. The structure of an address in an SMTP based email do have a slot for the name of a person, and since 1991 that can contain non-ascii.

That said, yes, I know, have talked with many, and understand people that want to have non-ascii in email addresses. Specifically for use in a local context.

That should not be mixed with the ability to have ones name in non-ascii in an email header.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2019 10:21:46 -0400

> Yes, but for me, if you can encode things and then decode in a non-destructive way, I call that support.

Theyr'e different levels of abstraction.  SMTP transport does no encoding 
or decoding, so at that level everything has to be ASCII, or with 
8BITMIME, strings of bytes under 1000 long with ASCII CR/LF at the end of 
each.  Go up a level to software that interprets the message and sure, you 
can have all sorts of MIME encodings.

> That said, yes, I know, have talked with many, and understand people 
> that want to have non-ascii in email addresses. Specifically for use in 
> a local context.

Right.  There was an interesting talk at the recent ICANN tech day by two 
women from Thailand who said they have a lot of mail users who are 
literate in Thai but not in any Latin alphabet language.

Regards,