Subject: [dmarc-ietf] AD review draft-ietf-dmarc-eaiauth-02

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Feb 2019 13:56:25 +0000

Hi all,

This document is in a good shape, but I have a couple of minor things 
that I would like to see fixed before initiating IETF LC:

4.  SPF and internationalized mail

    SPF macros %s and %l expand the local-part of the sender's mailbox.
    If the local-part contains non-ASCII characters, terms that include
    %s or %l do not match anything.  (Note that unlike U-labels, there is
    no way to rewrite non-ASCII local parts into ASCII.)

The SPF RFC is using %{s} and %{p}, so I appreciate if the text above is 
updated appropriately.

5.  DKIM and internationalized mail

    dkim-safe-char        =  %x21-3A / %x3C / %x3E-7E / %x80-FF
                         ; '!' - ':', '<', '>' - '~', non-ASCII

Addition of UTF-8 is not precise enough and will encourage buggy 
implementations. So please replace the last alternative "%x80-FF" with:

  UTF8-2 / UTF8-3 / UTF8-4

UTF8-2          = <Defined in Section 4 of RFC 3629>

UTF8-3          = <Defined in Section 4 of RFC 3629>

UTF8-4          = <Defined in Section 4 of RFC 3629>

So RFC 3629 would be another normative reference.

Thank you,

Alexey

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Feb 2019 14:25:09 +0000

>The SPF RFC is using %{s} and %{p}, so I appreciate if the text above

A related point ...

The draft currently says it updates RFC 7208, but is that right?  It only explicitly documents what's already defined there.  Should that be removed?

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 27 Feb 2019 21:35:14 -0500

> The draft currently says it updates RFC 7208, but is that right?  It only explicitly documents what's already defined there.  Should that be removed?

It does say that matching a UTF-8 local part fails, which is new.

If you write code the way I write code, a current implementation might 
just stuff the UTF-8 into a DNS lookup.  The DNS is mostly 8-bit clean, 
after all, so it hypothetically might find something.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 28 Feb 2019 08:25:28 -0800

On Wed, Feb 27, 2019 at 6:35 PM John R. Levine <[email-masked]> wrote:

> > A related point ...
> >
> > The draft currently says it updates RFC 7208, but is that right?  It
> only explicitly documents what's already defined there.  Should that be
> removed?
>

I haven't seen "might" listed in 2119 so it seems like a sketchy construct
for interoperability :-D

--Kurt