Subject: Re: [I18ndir] Request for review: draft-ietf-dmarc-eaiauth-02

From: Martin J. Dürst <[email-masked]>
Date: Sun, 3 Mar 2019 09:38:01 +0000

Hello Alexey, others,

On 2019/02/28 10:55, Martin J. Dürst wrote:

> I'll volunteer to write a review, probably by tomorrow my time.

Sorry that took longer. Anyway, here it is. Please shoot.

> On 2019/02/27 22:59, Alexey Melnikov wrote:
>> Dear I18N Directorate members,
>> draft-ietf-dmarc-eaiauth-02 will soon start IETF LC. I would like a quick sanity check that it doesn't say anything wrong from I18N point of view. (A reviewer familiar with EAI, SMTP, DKIM/SPF/DMARC would be ideal).
> 
> I'm in no way as familiar with SMTP,... as some others on the list
> (which sets the bar extremely high), but I'll try my best.

This might have better be worded as "(who set the bar extremely high)".

Anyway, I've read the document 
(https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-03, which was 
published yesterday), it's only 7 pages.

Here are my 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.

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

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 that RFC; it uses the term "internationalized messages" only 
in the context of message/global).

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

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

Regards,   Martin.

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 05 Mar 2019 22:11:05 -0500

Thanks Martin. I have not had a chance to read over your review yet, but 
since you did it, I suppose it would only be good form to go 
retroactively assign it to you in the datatracker tool. ;-) I'll have a 
chance tomorrow to give it a read over if you'd like a sanity check on 
the email bits, but the pen is yours either way.

pr

On 3 Mar 2019, at 4:38, Martin J. Dürst wrote:

>>> draft-ietf-dmarc-eaiauth-02 will soon start IETF LC. I would like a 
>>> quick sanity check that it doesn't say anything wrong from I18N 
>>> point of view. (A reviewer familiar with EAI, SMTP, DKIM/SPF/DMARC 
>>> would be ideal).
>>

-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 5 Mar 2019 19:07:31 +0100

I did a brief scan on dmarc-eaiauth too. Not enough to say whether I
think the mechanisms are appropriate or not, but I noted that the
definitions section 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 is fine with me (I am all in favor of allowing informationals
to be updated), but it should be self-consistent.
Worth including in the review?

-- 
Surveillance is pervasive. Go Dark.

---

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

Thanks for the additional comment, Harald. I'll include it in my review. 
If others have any comments, I'm of course very glad to add them, too.

Regards,   Martin.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

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

Hello Pete,

On 2019/03/06 12:11, Pete Resnick wrote:
> retroactively assign it to you in the datatracker tool. ;-)

Okay.

> I'll have a 

Yes, please do. You have about 100 times the email experience I have!

Any directions on when to conclude our review period? Any direction on 
how/where to send the review? As a baseline, I'll do something similar 
to the Apps Area Directorate reviews, which I think is also very similar 
to what other directorates are doing.

Regards,   Martin.

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 08 Mar 2019 11:51:31 -0600

> Yes, please do. You have about 100 times the email experience I have!

Your review I thought was quite good! Nothing on the email end of things 
jumped out at me after reading the document that you missed. The only 
addition that came to mind is that perhaps in section 5 they could refer 
to 5982, but I agree with your comment that they're probably not going 
to do much better in the grammar itself.

> to what other directorates are doing.

As for when, the Last Call ends on the 14th, so I'd say go ahead and 
submit any time now. If folks pipe up with other comments, they can just 
submit it as a Last Call comment. Remember, this is a document that 
happens to use i18n, not a core i18n document, so no need for a list 
discussion of the document itself.

As for how, I've now assigned the document to you in the review tool in 
the datatracker, so you should see it under "My reviews" under the 
rightmost menu once you log in to the datatracker. You can fill in the 
template and check all the appropriate boxes. Let me know if you need 
assistance.

Cheers,

pr