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

From: [email-masked]
Date: Sun, 25 May 2014 01:49:48 -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          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-email-auth-codes-00.txt
	Pages           : 5
	Date            : 2014-05-23

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 May 2014 12:53:09 -0400

>    because of email authentication failures.  This document registers

I'll repeat that I have a very strong objection to including the DKIM
status codes.  6376 says this (Section 6.3):

   In general, modules that consume DKIM verification output SHOULD NOT
   determine message acceptability based solely on a lack of any
   signature or on an unverifiable signature; such rejection would cause
   severe interoperability problems.

and this (Section 6.3):

   If the email cannot be verified, then it SHOULD be treated the same
   as all unverified email, regardless of whether or not it looks like
   it was signed.

The point that the codes are trying to convey is that the message is
being rejected by a *policy* decision, not directly because of a DKIM
signature issue.  Both status codes that are proposed represent
rejection because of a policy that directly violates "SHOULD"
provisions in RFC 6376.  I do not want to see a Proposed Standard that
standardizes a status code that says, essentially, "This message was
rejected because we have a policy that's in violation of RFC 6376."

I would have much less problem with a status code that says, "This
message was rejected because we were unable to verify the sending
domain, and policy requires such verification."  That could be put in
here as a general thing, or can be left to DMARC to create (I see no
reason to wait).  This status code could explain, in its description,
that said verification could come from successful validation of a DKIM
signature, successful application of SPF, or [perhaps] by another
verification mechanism that might later be defined.

That would also address my other concern: this would clearly take
precedence over the SPF Failures Code.  You return the "Sending Domain
Verification Failure Code" if you make broader checks, while the "SPF
Failures Code" (why is it plural?) is used when you're only checking
SPF (which does include policy, so my DKIM objection doesn't apply to
SPF).  It is probably worth explicitly saying that in the document.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 May 2014 10:13:21 -0700

> verification mechanism that might later be defined.

I guess I misunderstood your proposed change to the individual submission,
and it landed where we are now.  I'll take another run at it in the next
version.

> SPF).  It is probably worth explicitly saying that in the document.

The plural is probably a mistake.  I'll work on the rest of this as well.

-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 27 May 2014 19:54:35 +0200 (CEST)

On Tue, 27 May 2014, Barry Leiba wrote:

> status codes.

++++1 !!

> verification mechanism that might later be defined.

correct.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 May 2014 14:08:21 -0700 (PDT)

> rejected because we have a policy that's in violation of RFC 6376."

Nicely put. I have to agree.

> domain, and policy requires such verification."

Exactly. This provides a code with real utility, because it tells the
processing agent that the problem isn't with this recipient address, but with
the message/recipient combination.

> That could be put in

The argument for putting it here is so that it is more generally applicable.
The argument for putting it in the DMARC specification is that would make
it clear that DMARC agents are supposed to use it.

A middle ground would be to specify it here and reference the specification in
DMARC. But any of these work for me; I'm more concerned with producing a timely
specification than I am with the document taxonomy.

> SPF).  It is probably worth explicitly saying that in the document.

Agreed.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 May 2014 14:24:07 -0700

> specification than I am with the document taxonomy.

Does the -01 version handle these concerns for you as well?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 May 2014 15:00:07 -0700 (PDT)

> Does the -01 version handle these concerns for you as well?

Yes, it looks OK to me now.

				Ned