Email Authentication for Internationalized Mail

Note: This ballot was opened for revision 04 and is now closed.

Barry Leiba (was No Objection) Yes

Comment (2019-04-07 for -05)
No email
send info
— Section 4 —

   An IDN in MAIL FROM can
   be either U-labels or A-labels.

There’s a number agreement error here.  Make it “...can use...,” (or “can include”) and I think that fixes it.

(Alexey Melnikov) Yes

(Adam Roach) Yes

Comment (2019-04-09 for -05)
Thanks to everyone who worked on this document.


The i18ndir review included a number of minor issues that appear to remain
unaddressed. (To be clear, I don't assert that all of them require document
changes, but I would expect to see responses to the reviewer on these points).
I reiterate one of the more important minor comments below.


I agree with Benjamin's DISCUSS comment: this document needs to better
explain the consequences of the inability to match %{s} and %{l}. He talks about
it from a security perspective, but I think there's also a discussion to be had
here about whether this disadvantages users who elect to have non-ASCII
characters in their mailbox names.

I did see the response to the i18ndir review regarding the low usage of these
macros. If that is relevant to the decision to ignore the proper functioning of
these macros, then such rationale should be included in this document. Further,
if this document is breaking these macros under certain circumstances due to low
deployment, I would urge the working group to consider whether this document
should formally deprecate their use rather than relegating certain users to
second-class status.



>  the From: header of e-mail messages.

Nit: "...header field..."


>  Section 2.11 of [RFC6376] defines dkim-quoted-printable.  Its
>  definition is modified in messages with internationalized headers so
>  that non-ASCII UTF-8 characters need not be quoted.  The ABNF for
>  dkim-safe-char in those messages is replaced by the following, adding
>  non-ASCII UTF-8 characters from [RFC3629]:

Nit (twice): replace "UTF-8 characters" with either "UTF-8 byte sequences" or
"UTF-8 encoded Unicode characters".



>  Header names and other text intended primarily to be interpreted by

Nit: "Header field names..."



>  DKIM [RFC6376] specifies a message header that contains a

Nit: "...header field..."

>  of a DKIM-Signature header MUST be encoded as A-labels.  This rule is

Nit: "...header field..."

>  consistency with other headers.  (A-labels remain valid to allow a

Nit: "...header fields..."

>  in section 3.7, the hash MUST use the domain name in the format it
>  occurs in the header.

Nit: "...header field."

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-04-09 for -05)
Thanks for the clarifications this draft provides to deployed technologies.  A few comments:

(1) Support Ben’s first DISCUSS asking questions about macro expansion

(2) A process question – are there any issues with a IETF stream proposed standard draft (this draft) updating an ISE stream published document (RFC7489)?

(3) Section 3, Please expand “EAI” on first use.  It isn’t in the RFC Editor Abbreviations List --

(4) Section 4 says, “Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension , an IDN argument  MUST be represented as an A-label.”  Is the “IDN argument” in question the hostname used in the EHLO?  If this is the only argument, I would recommend explicitly saying s/an IDN argument/an IDN hostname used in EHLO/).

(5) Section 6, Recommend making the reference clearer by
s/described in section 7/described in section 7.1 of [RFC7208]/

(6) Section 5, Recommend making the reference clearer by 
s/When computing or verifying the hash in a DKIM signature as described in section 3.7/
When computing or verifying the hash in a DKIM signature as described in section 3.7 [RFC6376]/

(7) Section 6, Recommend making the reference clearer by
s/Section 6.6.1  specifies/Section 6.6.1 of [RFC7489]/
s/Sections 6.7 and 7.1/Sections 6.7 and 7.1 of [RFC7489]/

(8) Section 6 says “Section 6.6.1  specifies, somewhat imprecisely”.  What does the “somewhat” mean?  I recommend more precision in describing the ambiguity left by RFC7489 or dropping that word.

(9) Section 8.  Recommend making more specific statements about the Security Considerations:

s/This document attempts  to slightly mitigate some of them but does not, as far as the author knows, add any new ones. /
This document provides clarifications to existing protocols to improve their handling of internationalized email./  

Recommend adding something as follows as the last sentence: “It introduces no additional security considerations beyond those already identified in the base specifications of [RFC7208], [RFC6376] and [RFC7489].” – pending resolution of Ben’s first DISCUSS.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-04-17)
Thank you for resolving my Discuss point!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-04-04 for -04)
Does -04 fix all issues / comments from the Internationalization directorate (which was about -03) ?

Nits: section 8 in security consideration, unsure whether the use of "as far as the author knows" is useful or required.

Magnus Westerlund No Objection