Subject: [marf] draft-ietf-marf-dkim-reporting-00

From: SM <[email-masked]>
Date: Thu, 22 Apr 2010 02:47:56 -0700

Hi Murray,

These comments are for draft-ietf-marf-dkim-reporting-00.

In Section 1:

   "[DKIM] introduced a standard for digital signing of messages for the
    purposes of sender authentication."

I suggest avoiding the word "standard" in there.  Reusing some text 
from RFC 4871:

    DomainKeys Identified Mail (DKIM) defines a mechanism by which email
    messages can be cryptographically signed, permitting a signing domain
    to claim responsibility for the introduction of a message into the
    mail stream.

In Section 5.2:

  "u  Reports are requested for messages that have no valid [DKIM]
       signature but do not match the published [ADSP] policy."

I suggest replacing the "but" with "and".

In Section 6:

  "smtp:  An [SMTP] error with a string descriptive of the problem that
       caused the DKIM verification to fail."

Do you mean SMTP error code?  Would the descriptive string be a 
redefinition of existing strings used for these error codes?

In Section 7.3:

   "For example, "Failure: asp" could be augmented by a"

There is a typo for "adsp".

The [MAIL] reference should be RFC 5322.

In Appendix B.1:

   "Reports about signature evaluation failures should be send to the
    address "dkim-errors" at the sender's domain;"

That should be "the domain found in the "d=" tag of the signature" 
instead of the sender's domain.

In Appendix B.2:

   "The sending domain (i.e. the one that is advertising this policy)
    signs all mail it sends;"

That should be Author Domain.  There are other occurrences of 
"sender's domain" that should be fixed.

BTW, Appendix C should point to this mailing list.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Apr 2010 15:01:44 -0400

> I suggest avoiding the word "standard" in there.  Reusing some text from RFC
> 4871:

RFC 4871 is on the Standards Track, and there's no reason to avoid
referring to it as a "standard".  Why do you object to that?

That said, I'd rather avoid the "sender authentication" phrasing, and
suggest the "claim responsibility" wording that SM quotes.

Barry

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 22 Apr 2010 14:25:56 -0600

> referring to it as a "standard".  Why do you object to that?

How about we take the best of both suggestions and use "standard mechanism" instead of just "standard" or just "mechanism"?

---

From: SM <[email-masked]>
Date: Thu, 22 Apr 2010 13:36:26 -0700

Hi Barry,
>referring to it as a "standard".  Why do you object to that?

RFC 4871 may be on the Standards Track but it's not an Internet 
Standard.  I don't think it's a good idea to refer to it as a 
standard in a WG document.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Apr 2010 16:57:13 -0400

> RFC 4871 may be on the Standards Track but it's not an Internet Standard.  I
> don't think it's a good idea to refer to it as a standard in a WG document.

I think that's a very odd objection.  It's "Proposed Standard", yes.
We refer to standards-track documents as "standards" (as opposed to
"Full Standard", or "STD 17", or whatever) all the time.

Barry

---

From: SM <[email-masked]>
Date: Thu, 22 Apr 2010 15:28:04 -0700

>I think that's a very odd objection.  It's "Proposed Standard", yes.

It's probably odd.  As the comment doesn't materially affect the 
document, I would not classify it as an objection.

>"Full Standard", or "STD 17", or whatever) all the time.

It depends on how we read RFC 2026. :-)

At 13:25 22-04-10, McDowell, Brett wrote:
>How about we take the best of both suggestions and use "standard 
>mechanism" instead of just "standard" or just "mechanism"?

That works for me.

Regards,
-sm