Subject: [EAI] New version of E-mail Authentication for Internationalized Mail draft

From: "John R Levine" <[email-masked]>
Date: 23 Jan 2018 20:01:23 -0500

Read all about it: 
https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/

This is an updated version of a draft I wrote two years ago, that tries to nail 
down the small changes to SPF, DKIM, and DMARC in EAI messages.  This version 
adds a section for the Authentication-Results header.

What it mostly says is that wherever you can have a domain name in a mail 
message header it can be a U-label, and wherever there's a mailbox, the local 
part can be UTF-8, while stuff in the DNS doesn't change and domains there are 
A-labels, same as always.  It's intended to be utterly unsurprising, but 
there's enough ambiguity and well-intended bad advice in existing RFCs that I 
think this is worth doing.

I'm working on an intro to implenting EAI document underwritten by ICANN so it 
would be nice if this were far enough along that I could point to it in the 
relevant sections rather than just Making Stuff Up.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Jan 2018 11:07:08 +0100

Hi, I've certainly forgotten what I put in draft-ellermann-spf-eai-05
more than 6 years ago,
but apparently I thought that local part macros might not work as
expected (bad enough
to mention this also in the security considerations). At this time EAI
and SPF were still
experimental, and RFC 7208 was still Scott's draft. :-)

Unrelated Gmail observation, they tag SPF PASS + DKIM PASS + DMARC FAIL as spam.

On 24 January 2018 at 02:01, John R Levine <[email-masked]> wrote:
> This is an updated version of a draft I wrote two years ago, that tries to
> nail down the small changes to SPF, DKIM, and DMARC in EAI messages.  This
> version adds a section for the Authentication-Results header.
>
> message header it can be a U-label, and wherever there's a mailbox, the
> local part can be UTF-8, while stuff in the DNS doesn't change and domains
> there are A-labels, same as always.  It's intended to be utterly
> unsurprising, but there's enough ambiguity and well-intended bad advice in
> existing RFCs that I think this is worth doing.
>
> I'm working on an intro to implenting EAI document underwritten by ICANN so
> it would be nice if this were far enough along that I could point to it in
> the relevant sections rather than just Making Stuff Up.
>
> R's,
> John
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2018 09:42:42 -0500

> but apparently I thought that local part macros might not work as

Scott mentioned that on another list.  My first suggestion is to say that 
macros that use local parts don't work with EAI addresses, the second is 
to say that you use the UTF-8 local parts as is and if that creates some 
hard to type DNS names, so be it.  (The DNS is 8 bit clean other than 
ASCII case folding so there's no DNS problems.)

It has always been my impression that SPF local parts are fragile even 
with ASCII names, e.g., what DNS name does this entirely valid ASCII local 
part turn into?

    a.b\.c\\d)e

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