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

From: "John R Levine" <[email-masked]>
Date: 22 Jan 2018 15:59:15 -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: Scott Kitterman <[email-masked]>
Date: Mon, 22 Jan 2018 21:37:54 +0000

>relevant sections rather than just Making Stuff Up.

SPF can use mailfrom local parts, so that needs to be addressed in addition to what's in the draft.  I know it's not commonly used, but it is used and is part of the standard.

Scott K

---

From: Ned Freed <[email-masked]>
Date: Mon, 22 Jan 2018 13:49:03 -0800 (PST)

> enough ambiguity and well-intended bad advice in existing RFCs that I think this

The interaction of this with downgrading as specified in RFC 6857 and RFC 6868
is ... interesting.

Downgrading a u-label to an a-label is of course the obvious thing to do, and
is what RFC 6857 specifies. But the handling of an non-ASCII local-part, while
specified, seems to assume that the syntax allows the insertion of a
group construct, which I don't think is allowed here. So this is a new
case for the RFC 6857 approach. I guess we could opt for an encoded-word ;-)

RFC 6858's approach of inserting an invalid local-part and/or domain
seems fairly unattractive for the domain-only case, but it does cover 
all the cases here.

Anyway, I guesss I'm going to have to teach my downgrade code how to process
Authentication-Results fields one way or the other. Oh well.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 22 Jan 2018 17:31:47 -0500

> The interaction of this with downgrading as specified in RFC 6857 and RFC 
> 6868 is ... interesting.

> Authentication-Results fields one way or the other. Oh well.

I wouldn't try too hard.  By the time a message is hitting POP or IMAP 
downgrades, I would think that anything that's going to use the A-R would 
already have done its thing, and anything you'll lose by eliding a mailbox 
local part isn't very important.

> So this is a new case for the RFC 6857 approach. I guess we could opt 
> for an encoded-word ;-)

I just spent a week in China trying to explain to people that there is no 
way to downgrade a UTF-8 local part so don't even try.  The word 
"punycode" was frequently uttered and as frequently stomped on. 
Arrrrrrrrgggghhhhhh.

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

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2018 19:44:13 -0500

In article <[email-masked]> you write:
>SPF can use mailfrom local parts, so that needs to be addressed in addition to what's in the draft.  I know it's not
>commonly used, but it is used and is part of the standard.

Hmmn, I'm open to sugggestion but my inclination is to say that
anything with %s or %l macros fails with a non-ASCII local part.  That
bit of SPF has always seemed rather ill-defined to me since it's never
been obvious what it means if a local part contains quotes or
parentheses or something like foo\.bar.

R's,
John
-- 
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: Scott Kitterman <[email-masked]>
Date: Mon, 22 Jan 2018 23:42:08 -0500

On Monday, January 22, 2018 07:44:13 PM John Levine wrote:
> >SPF can use mailfrom local parts, so that needs to be addressed in addition
> >to what's in the draft.  I know it's not commonly used, but it is used and
> >is part of the standard.
> 

I don't have any opinion on the correct solution (I know almost nothing about 
EAI and suspect it's good for my future sanity to try to preserve that state), 
but one way or another, I think it needs to be addressed.

One nice thing about your proposed approach is that it's backwards compatible.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2018 12:44:04 -0500

>One nice thing about your proposed approach is that it's backwards compatible.

The other possibility is that they just expand macros using the UTF-8
and if that turns into hard-to-type DNS names, so be it.  The DNS is
8-bit clean other than ASCII case folding, and since the DNS names
that these macros generate have never tried to be host names, random
8-bit UTF-8 crud is in principle no worse than underscores or plus
signs or spaces.

It is still my strong impression that these macros have always been
fragile since the interpretation of \. and the like is probably
whatever the host language's string and/or DNS libraries happen to do
with them.

R's,
John