Skip to main content

Email Authentication for Internationalized Mail
RFC 8616


(Alexey Melnikov)

No Objection

Alvaro Retana
Warren Kumari
(Alissa Cooper)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

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

Alvaro Retana
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.
Warren Kumari
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.
Adam Roach Former IESG member
Yes (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."
Alexey Melnikov Former IESG member
Yes (for -04)

Barry Leiba Former IESG member
(was No Objection) Yes
Yes (2019-04-07 for -05)
— 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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -05)

Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-04-17)
Thank you for resolving my Discuss point!
Deborah Brungard Former IESG member
No Objection
No Objection (for -05)

Ignas Bagdonas Former IESG member
No Objection
No Objection (for -05)

Magnus Westerlund Former IESG member
No Objection
No Objection (for -05)

Martin Vigoureux Former IESG member
No Objection
No Objection (for -05)

Mirja Kühlewind Former IESG member
No Objection
No Objection (for -04)

Suresh Krishnan Former IESG member
No Objection
No Objection (for -05)