Subject: [apps-discuss] I-D ACTION:draft-ietf-appsawg-email-auth-codes-04.txt

From: [email-masked]
Date: Tue, 08 Jul 2014 11:55:38 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Applications Area Working Group Working Group of the IETF.

    Title         : Email Authentication Status Codes
    Author(s)     : M. Kucherawy
    Filename      : draft-ietf-appsawg-email-auth-codes
    Pages         : 7 
    Date          : 2014-07-08 
    
   There is at present no way to return a status code to an email client
   that indicates a message is being rejected or deferred specifically
   because of email authentication failures.  This document registers
   codes for this purpose.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-appsawg-email-auth-codes-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Jul 2014 17:19:23 -0400

>     Filename      : draft-ietf-appsawg-email-auth-codes

I have reviewed this draft and believe it is almost ready for publication.

The term "author-aligned" is the distinguishing factor between X.7.20 and 
X.7.21.  Since this is a new term in the IETF standards context I think it 
needs to be clearly and obviously defined.  I don't think discussion buried in 
a parenthetical in section 4 is adequate.

In draft-kucherawy-dmarc-base, section 3.1.4. Identifier Alignment, there is a 
good, detailed discussion of the concept.  I think it would be useful to have 
a DKIM focused extract of that in this document.

Also, with DMARC on the horizon (and having been discussed extensively 
recently), I think it would be useful for this document to specifically 
recommend that future documents that define new email authentication protocols, 
policy protocols, etc. ought to specify specific codes to cover those uses.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Jul 2014 15:52:44 -0700

> a DKIM focused extract of that in this document.

I'm not sure how far we want to go into introducing new concepts in this
relatively small document.  However, I'll see if I can come up with a
fairly short paragraph that captures the idea beyond what's there now and
see if we like it.

> policy protocols, etc. ought to specify specific codes to cover those uses.

I'm not sure how useful it would be to do that in this document as authors
of new protocols wouldn't know to look here, but I suppose it can't hurt to
at least talk about it.

Any objection to dealing with both of these during IETF Last Call?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Jul 2014 22:52:30 -0400

> fairly short paragraph that captures the idea beyond what's there now and

Since there's no reference for the definition to live in, if we're going to 
have a code point distinguished based on it, then there has to be at least 
enough definition here to make the document usable.  You couldn't create a "No 
valid Fred DKIM signature found" code point without explaining what Fred meant 
in this context.

DKIM has no concept of author or alignment, so I believe the definition is 
essential.  That doesn't mean it has to be long.

> of new protocols wouldn't know to look here, but I suppose it can't hurt to

Google or its competitors would likely help, but at the very least reviewers 
could point to it if it were missing.  Functionally, this document establishes 
the concept that email authentication 'technologies' ought to have their own 
codes.  It ought to be explicit about it.

> Any objection to dealing with both of these during IETF Last Call?

Probably not.  If we can agree on the right words to resolve the comments then 
definitely not.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Jul 2014 20:34:04 -0700

> essential.  That doesn't mean it has to be long.

Might it be simpler to just remove "author-aligned" from the document,
obviating the need for a definition?  Something like "No valid author
domain DKIM signature found"?

> codes.  It ought to be explicit about it.

How about this, at the end of Section 4:

"Any message authentication or policy enforcement technologies developed in
the future should also include registration of their own enhanced status
codes so that this kind of specific reporting is available to operators
that wish to use them."

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Jul 2014 00:56:47 -0400

> domain DKIM signature found"?

If you do, be sure to renumber the following codes.

Looking at RFC 6376, in section 6.2 in the informative advice, it says 
something about making sure the "verified identity matches the author 
identity", which is pretty close to what you have in your description.  The 
word aligned in the name though doesn't match with the description or 6376.

Perhaps changing "author-aligned" to "author-matched" and "the address(es) 
found in the From header field" to "the author address(es) found in the From 
header field"?

I think that accomplishes essentially the same thing and is supported by 
what's defined in 6376 (even if you have to squint a bit to see it).

> > > I'm not sure how useful it would be to do that in this document as
> > 
> > authors
> > 
> > > of new protocols wouldn't know to look here, but I suppose it can't hurt
> > 
> > to
> > 
> > > at least talk about it.
> > 

That's good.  If you're OK with my suggestion for fixing author-aligned, then 
I'm fine to leave it to last call.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Jul 2014 22:23:49 -0700

> what's defined in 6376 (even if you have to squint a bit to see it).

Sure, though your second change is redundant (I think) since the only place
you find author addresses is the From field.  Can't hurt to include it,
however.

> I'm fine to leave it to last call.

Done in my copy, so it'll be in -05.  Thanks!

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Jul 2014 06:20:19 -0400

On Tuesday, July 08, 2014 22:23:49 Murray S. Kucherawy wrote:
> > > "Any message authentication or policy enforcement technologies developed
> > 
> > in
> > 

Excellent.  See you at IETF last call.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Jul 2014 14:37:32 -0700

On 7/8/2014 2:19 PM, Scott Kitterman wrote:
> I think it would be useful to have 

Not 'dkim focused', but merely independent of DMARC.

The term is meant to assert the the domain name in the rfc5322.From
field matches an authenticated domain name.  The latter can come from
more places than just dkim.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net