Subject: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-02

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Jul 2014 15:34:43 -0700

Hi Murray,

I apologize for the long delay in sending the review of 
draft-ietf-appsawg-email-auth-codes-02.

As an overall comment, should there be a comment in the registry as 
follows: "(Non-standards-track)"?

In Section 3:

   "The following new status codes are defined:"

I suggest mentioning "Enhanced" before "status codes".  That applies 
to the title of that section too.

 From Section 3.1:

      "Code:               X.7.20
       Sample Text:        No valid DKIM signature found
       Associated basic status code:  5"

The digit "5" is not a basic status code.  I suggest listing the 
basic status codes (see RFC 5321) or using the alternatives described 
in Section 2.1 of RFC 5248.  In the above case you could use "550" as 
it is a local policy decision.

 From RFC 6371:

   "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."

   "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."

It should be okay as there is a note about that in the first 
description in Section 3.1.

      "Sample Text:        No valid author DKIM signature found
       Associated basic status code:  5
       Description:        This status code is returned when a message
                           did not contain a valid DKIM signature
                           matching the domain(s) found in the From
                           header field, contrary to local policy
                           requirements.  (Note that this violates the
                           advice of Section 6.1 of RFC6376.)"

Please see my previous comment about the basic status code.

Section 2.6 of RFC 6374 is about "Agent or User Identifier".  There 
isn't any mention of "author DKIM signature".  I gather that the 
request for two enhanced status codes is based on the identifiers 
mentioned in RFC 6374.

 From Section 3.2:

       "Code:               X.7.22
       Sample Text:        SPF validation failed
       Associated basic status code:  5"

And RFC 7208:

   "If the checking software chooses to reject the mail during the SMTP
    transaction, then it SHOULD use an SMTP reply code of 550 and, if
    supported, the 5.7.1 enhanced status code"

I suggest using "550" as the status code instead of "5".  What should 
an implementation of RFC 7208 do?

      "Code:               X.7.23
       Sample Text:        SPF validation error
       Associated basic status code:  5
       Description:        This status code is returned when evaluation
                           of SPF relative to an arriving message
                           resulted in an error."

 From RFC 7208:

   "If the message is rejected during the SMTP transaction for this reason,
    the software SHOULD use an SMTP reply code of 451 and, if supported ,
    the 4.4.3 enhanced status code"

   "If the message is rejected during the SMTP transaction for this reason,
    the software SHOULD use an SMTP reply code of 550 and, if supported, the
    5.5.2 enhanced status code"

What should an implementation of RFC 7208 do?

 From Section 3.3:

      "Code:               X.7.24
       Sample Text:        Reverse DNS validation failed
       Associated basic status code:  5

Please see my first comment about basic status code.

RFC 7001 is about communicating the results of message authentication 
efforts.  Why is RFC 7001 being referenced for this enhanced status code?

 From Section 3.4:

       "Code:               X.7.25
       Sample Text:        Multiple authentication checks failed
       Associated basic status code:  5"

Please see my previous comment about basic status code.  There was a 
discussion on the mailing list about what to do when the result is a 
combination of enhanced status codes.  John Levine and Ned Freed 
commented about this [1][2].  "a message failed more than one message 
authentication check" does not convey much information to the other 
end as there isn't any definition of "authentication checks".  There 
is a note in the description about the "specific mechanisms that 
failed are not specified".  I suggest providing a reference to a 
specification or a clear description.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12094.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12102.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Jul 2014 22:14:31 -0700

> draft-ietf-appsawg-email-auth-codes-02.

A late shepherd is better than no shepherd at all.  :-)

> follows: "(Non-standards-track)"?

For these entries?  I don't see why, as we're looking for Proposed Standard
status here.

In Section 3:
> I suggest mentioning "Enhanced" before "status codes".  That applies to
> the title of that section too.
>

Done.

> The digit "5" is not a basic status code.  I suggest listing the basic
> status codes (see RFC 5321) or using the alternatives described in Section
> 2.1 of RFC 5248.  In the above case you could use "550" as it is a local
> policy decision.
>

Quite right.  I've updated this in each case to be "5XX" or "4XX" to be
consistent with existing entries in that registry.

>
> Section 2.6 of RFC 6374 is about "Agent or User Identifier".  There isn't
> any mention of "author DKIM signature".  I gather that the request for two
> enhanced status codes is based on the identifiers mentioned in RFC 6374.
>

(I assume you mean RFC 6376.)  Right, DKIM itself makes no definition of an
"author signature".  The first place we ever saw that is ADSP (RFC5617),
now Historic.  Rather than cite a Historic RFC, I decided to give a brief
definition here.

To make the matching logic more specific, I suggest:

   Code:               X.7.21
   Sample Text:        No valid author-aligned DKIM signature found
   Associated basic status code:  5XX
   Description:        This status code is returned when a message
                       did not contain a valid DKIM signature
                       whose identifier(s) match the address(es)
                       found in the From header field, contrary to
                       local policy requirements.  (Note that this
                       violates the advice of Section 6.1 of RFC6376.)
   Reference:          [this document]; RFC6376
   Submitter:          M. Kucherawy
   Change controller:  IESG

Does this satisfy your point?

> I suggest using "550" as the status code instead of "5".  What should an
> implementation of RFC 7208 do?
>

I think you're looking at -02 rather than -03; this was addressed in -03.
So, rather than saying "550 5.7.1" for the SPF "fail" case, an
implementation of both RFC 7208 and this document would reply with "550
5.7.22".

> What should an implementation of RFC 7208 do?

Again, handled in -03.  In the former case, rather than "451 4.4.3", it
would use "451 4.7.23"; in the latter, rather than "550 5.5.2", it would
use "550 5.7.23".

> efforts.  Why is RFC 7001 being referenced for this enhanced status code?

It is the only document I know of that formally defines the common reverse
DNS authentication check.  There was a dnsop document that did so, but it
was never published (as far as I know).

> Please see my previous comment about basic status code.

Addressed above.

> There was a discussion on the mailing list about what to do when the
> result is a combination of enhanced status codes.  John Levine and Ned
> Freed commented about this [1][2].  "a message failed more than one message
> authentication check" does not convey much information to the other end as
> there isn't any definition of "authentication checks".  There is a note in
> the description about the "specific mechanisms that failed are not
> specified".  I suggest providing a reference to a specification or a clear
> description.
>

Consensus appeared (to me, at least) to settle on the idea that being able
to report a multitude of failures is a "nice to have" that isn't worth the
effort to specify at this time.  The options left are:

(1) Report a generic error (which we're trying to get away from here) using
an existing code;

(2) Report the first thing that failed (which isn't useful if that was
expected);

(3) Report a random one (ick);

(4) Report that there were multiple failures.

It seemed to end here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12122.html

Hope this resolves all of your questions.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Jul 2014 23:48:09 -0700

Hi Murray,
At 22:14 07-07-2014, Murray S. Kucherawy wrote:
>A late shepherd is better than no shepherd at all.Â  :-)

:-)

>As an overall comment, should there be a comment 
>in the registry as follows: "(Non-standards-track)"?
>
>
>For these entries?  I don't see why, as we're 
>looking for Proposed Standard status here.

See comment below about my reading of the wrong 
version of the draft.  Please disregard the above question.

>The digit "5" is not a basic status code.  I 
>suggest listing the basic status codes (see RFC 
>5321) or using the alternatives described in 
>Section 2.1 of RFC 5248.  In the above case you 
>could use "550" as it is a local policy decision.
>
>
>Quite right.  I've updated this in each case to 
>be "5XX" or "4XX" to be consistent with existing entries in that registry.

I'll suggest being specific in this case (550) as it is a policy decision.

>Section 2.6 of RFC 6374 is about "Agent or User 
>Identifier".  There isn't any mention of "author 
>DKIM signature".  I gather that the request for 
>two enhanced status codes is based on the identifiers mentioned in RFC 6374.
>
>
>(I assume you mean RFC 6376.)  Right, DKIM 
>itself makes no definition of an "author 
>signature".  The first place we ever saw that is 
>ADSP (RFC5617), now Historic.  Rather than cite 
>a Historic RFC, I decided to give a brief definition here.
>

I'd say use "550" instead of 5XX as this is again 
local policy.  I took a look at RFC 6376 
again.  In my opinion the above description is 
clear.  If nobody in the working group considers 
the sample text as a problem I'll consider the sample text as good enough.

>I suggest using "550" as the status code instead 
>of "5".  What should an implementation of RFC 7208 do?
>
>
>I think you're looking at -02 rather than -03; 
>this was addressed in -03.  So, rather than 
>saying "550 5.7.1" for the SPF "fail" case, an 
>implementation of both RFC 7208 and this 
>document would reply with "550 5.7.22".

I thought that I was reviewing the wrong version 
of the draft.  tools.ietf.org was showing -02 as 
the latest.  I got -03 when I entered that version in the draft name.

The draft will have to mention why RFC 7208 is 
being updated.  You can have the text in the Abstract or the Introduction.

>Again, handled in -03.  In the former case, 
>rather than "451 4.4.3", it would use "451 
>4.7.23"; in the latter, rather than "550 5.5.2", it would use "550 5.7.23".

Could you add the basic status code instead of "4/5"?

>RFC 7001 is about communicating the results of 
>message authentication efforts.  Why is RFC 7001 
>being referenced for this enhanced status code?
>
>
>It is the only document I know of that formally 
>defines the common reverse DNS authentication 
>check.  There was a dnsop document that did so, 
>but it was never published (as far as I know).

I suggest using "550" for this.  The description 
text is clear to me.  I'll say okay to this.

>Please see my previous comment about basic status code.

Ok.

>Consensus appeared (to me, at least) to settle 
>on the idea that being able to report a 
>multitude of failures is a "nice to have" that 
>isn't worth the effort to specify at this time.Â  The options left are:
>
>(1) Report a generic error (which we're trying 
>to get away from here) using an existing code;
>
>(2) Report the first thing that failed (which 
>isn't useful if that was expected);
>

I just noticed that the term "email 
authentication" is used in Section 1.  I'll 
suggest replacing that with "message 
authentication".  I read Section 4 of -03.  In my 
opinion it provides a balanced view of what is 
being proposed and what is being violated.  As 
there is also WG Consensus on this I don't see 
any reason not to proceed with the existing text.

As a note to the working group, I didn't see any 
strong disagreement about this 
specification.  Please email me if I missed a message about that.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Jul 2014 00:39:08 -0700

> I'll suggest being specific in this case (550) as it is a policy decision.

OK.

> The draft will have to mention why RFC 7208 is being updated.  You can
> have the text in the Abstract or the Introduction.
>
>                  "Code:           X.7.23

Yes, I've added 451 and 550.

>
> I just noticed that the term "email authentication" is used in Section 1.
>  I'll suggest replacing that with "message authentication".

OK.

> I read Section 4 of -03.  In my opinion it provides a balanced view of
> what is being proposed and what is being violated.  As there is also WG
> Consensus on this I don't see any reason not to proceed with the existing
> text.
>
> As a note to the working group, I didn't see any strong disagreement about
> this specification.  Please email me if I missed a message about that.
>

I'll send -04 to the tracker now with these changes, and ask Barry to
approve it.

Thanks!

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Jul 2014 09:32:33 -0400

> Yes, I've added 451 and 550.

I did check and 451/550 are what RFC 7208 suggests if deferring/rejecting, so 
that's consistent.

Scott K