Subject: [apps-discuss] EAI, SPF, DKIM, and DMARC

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 04:52:23 -0000

Gosh, I love acronyms.  I wrote a short draft describing how
internationalized mail (EAI) interacts with SPF, DKIM, and DMARC.

Nothing in it should be surprising.  It just clarifies where you need
U-labels vs. A-labels, and makes what I think is an obvious change to
the DKIM-Signature header to allow U-labels (UTF-8 domain names) in
the d= and i= fields when the message is EAI so it's got UTF-8
everywhere else.  It also fixes some minor bugs in the DMARC spec that
confuse U-labels with full domain names.

https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/

If people find this of interest, I'd like to do it through appsarea.
SPF and DKIM are standards track, DMARC currently is not, so I tried
to finesse it.

R's,
John

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 09:10:13 +0200

> SPF and DKIM are standards track, DMARC currently is not, so I tried

I like this.

But, I see a number of "MUST", "must" and "That section is updated to say that all U-labels in the domain are converted to A-labels before further processing." etc. These things I think should be made clear in future versions exactly so that one know what the original text say. Maybe you have quoted correctly and the unclarity exists in the source document? Maybe you did in this first version "just wrote text" (like I do :-) ).

So please continue with this!

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 4 Jul 2015 20:40:07 +1200

> But, I see a number of "MUST", "must" and "That section is updated to say that all U-labels in the domain are converted to A-labels before further processing." etc. These things I think should be m…

As you surmised, I just wrote text.  If people want to go ahead with this, 
I don't think that it will be a big problem to fix the requirements 
language.

Keep in mind that DMARC is not standards track so as I understand it, 2119 
doesn't apply.  That's why the DMARC bits are phrased as advice, not 
requirements.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 4 Jul 2015 10:07:47 +0100

John,

> On 4 Jul 2015, at 09:40, John R Levine <[email-masked]> wrote:
> 
> Keep in mind that DMARC is not standards track so as I understand it, 2119 doesn't apply.  

It is perfectly Ok to use 2119 language for non Standards Track documents.

> That's why the DMARC bits are phrased as advice, not requirements.

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Jul 2015 12:07:11 -0400

--On Saturday, 04 July, 2015 20:40 +1200 John R Levine
<[email-masked]> wrote:

>> But, I see a number of "MUST", "must" and "That section is
>> updated to say that all U-labels in the domain are converted
>> to A-labels before further processing." etc. These things I
>> think should be made clear in future versions exactly so that
>> one know what the original text say. Maybe you have quoted
>> correctly and the unclarity exists in the source document?
>> Maybe you did in this first version "just wrote text" (like I
>> do :-) ).
> 
> As you surmised, I just wrote text.  If people want to go
> ahead with this, I don't think that it will be a big problem
> to fix the requirements language.

I don't either although some of those assertions are going to
need careful checking with, and probably references to, the
source documents.  To take the first example I ran across,
Section 2 includes a sentence that says 
	"Since the EHLO command precedes the server response
	that identifies the SMTPUTF8 extension, an IDN domain
	name argument SHOULD be represented as an A-label."
That MUST (sic) is a MUST; see Section 3.7.1 of RFC 6531.

The draft uncovers two more serious problems:

(1) The SMTPUTF8 ("EAI") specs are very clear in prohibiting
encoding of local-parts or, more specifically, making any
assumptions about anything that might resemble an encoding.  So,
unless whatever processes are involved with SPF, DKIM, and/or
DMARC are fully UTF-8-capable (with all the disclaimers that go
with that statement), there are certain to be problems.   In
particular, part of Section 5 says 
	"Since a policy record can be used for both
	internationalized and conventional mail, those addresses
	have to be conventional addresses, not internationalized
	addresses"
Because there is no "conventional" form of an address with a
non-ASCII local part, that requirement appears to be equivalent
to a prohibition on such addresses in the rua or ruf tags of
DMARC policy records.

(2) For a number of reasons, some associated with the "late
conversion" advice of RFC 6055, the EAI WG was quite clear that
addresses, as well as local-parts, be kept in native character
form except when actually converted to/ treated as domain names
to be looked up in the public DNS.  Some of the advice in this
document (presumably taken directly from the SPF, DKIM, and/or
DMARC specifications themselves, seems counter to that principle.

I think the draft performs the service of exposing more broadly
something that the EAI WG was aware of and discussed: that SPF
and DKIM were defined without real consideration of many i18n
issues.  From the above, the DMARC design may have given them
even less consideration.  It appears to me that some of these
issues, especially those that involve handling of local parts or
that might apply to mail being transmitted within an
administrative domain [1], may require rethinking and updating
the base SPF and DKIM Proposed Standard specifications and may
be important input to the effort to standards DMARC.  I am not
convinced that APPSAWG has sufficient focus, much less an
adequate concentration of i18n expertise, to do that job well.

    john

[1] Administrative domains for email purposes need not have
anything to do with either DNS zones or even DNS administrative
hierarchy.

---

From: "John R Levine" <[email-masked]>
Date: 6 Jul 2015 07:28:04 +1200

> That MUST (sic) is a MUST; see Section 3.7.1 of RFC 6531.

OK.

> to a prohibition on such addresses in the rua or ruf tags of

That's how I read it.  Given that those addresses are only used to send 
blobs of XML or ARF from one computer to another, I don't see it as a big 
deal that the local part has to be ASCII.  EAI systems have to support 
ASCII addresses, or postmaster wouldn't work.

> even less consideration.

No kidding.  I don't think it's hard to fix, though.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Jul 2015 19:01:10 -0700

On 7/5/15 9:07 AM, John C Klensin wrote:

> anything to do with either DNS zones or even DNS administrative

Dear John,

Your comments are on the mark.  When DMARC asserts a
restrictive policy it deprecates the role of Sender in a
different domain to offer an extremely weak version of
S/MIME or OpenPGP, which is otherwise well supported,
particularly for mobile users.  This scheme will also ossify
needed improvements as it lacks a strategy for adopting
alternatives or for providing reasonable methods to override
needlessly disruptive policies related to third-party services.

Regards,
Douglas Otis

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 04:49:13 -0400

> needlessly disruptive policies related to third-party services.

Doug,

That is my impression.  It is also my impression that DMARC's
origins with, apparently, a small number of organizations with a
narrow set of perceived needs and correspondingly small number
of use cases, leading to the damage that we saw when it was
first deployed.  I hope the WG can solve most or all of those
problems and that, if it cannot, that the IETF declines to
standardize it, leaving at least a small door open for other
options.

The best may be the enemy of the good but when the effect of the
good (or non-so-good) is to block the emergence of the best or
even the better, the tradeoffs become more complicated than the
slogan.

On the other hand, I'm unsure about your comparison to PGP and
S/MIME.  While I personally prefer them, I've gotten very
pessimistic over the years about the ability of ordinary users
to maintain private keys in a secure way, I believe that models
based on trusted third parties holding private keys are close to
a contradiction, and that, however bad our experience with CA
operators have been, depending on DNS registrars may be worse.

So I'm not quite sure where we go from here.  Simply denouncing
DMARC or suggesting entirely different models for email are,
fairly clearly, not going to be helpful.

best,
   john

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Jul 2015 20:43:13 -0700

Dear John,

Deployment strategies for OpenPGP are getting much better.
In fact, Facebook will make use of OpenPGP to encrypt web
and mobile app user messages.  Perhaps this might help at
getting this goose off the ground.  It seems iOS has issues
with airdrop moving private keys for email onto the mobile
device.  I remain fairly confident things will improve in
this much needed area.

This draft details other alternatives to mitigate DMARC
disruption in the following:

https://tools.ietf.org/html/draft-otis-dmarc-escape-03

We offered to help any a large provider facilitate the
scheme.  As expected, they avoided having better control
over abuse by pointing out how this would give them more
responsibility.  We were constantly notifying a large
provider of ongoing exploits occurring with their
"compliant" implementation of DKIM. About a year later they
seemed confused about how malefactors were able to spoof
their customers email. Heck, we published an article in
ZDNet illustrating this exploit by using their service to
spoof a message as being from the ZDNet reporter.  A cynic
might suspect there could be some type of click rate
disincentive.

What can be expected of a free service that just wants eyeballs?

Regards,
Douglas Otis