> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, August 09, 2011 1:44 PM > To: [email protected] > Cc: [email protected] > Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. > > Title : Authentication Failure Reporting using the Abuse > Report Format > Author(s) : Hilda L. Fontana > Filename : draft-ietf-marf-authfailure-report-01.txt > Pages : 19 > Date : 2011-08-09 > > This memo registers an extension report type to ARF to be used for > reporting forensic information about messages that fail one or more > message authentication schemes in use by the purported sender of the > message.
Hi Hilda, It looks like in Section 3.2.2, the definition of "DKIM-Canonicalized-Body" has gone missing. I believe it should go back in. The definition is the same as for DKIM-Canonicalized-Header, except (obviously) change "haeder" to "body" in the definition text. In the first sentence of Section 3.3, we should change "header" to "header field". Also in Section 3.3, for "granularity", we might want to mention that this is supported in [OLD-DKIM] but not in [DKIM] since it's undergoing update now and the whole concept of key granularity has been removed. We would then change the existing [DKIM] reference to [OLD-DKIM], and add one called [DKIM] that points to the one that's currently in the RFC editor queue. (Barry, check my math on this one, please.) Also in Section 3.3, the list of SPF result codes should have spaces after the commas. Apart from that, I don't have any pending feedback. This specification is implemented in OpenDKIM v2.4.2 (with one omission that will be present in the next release). I do have one question for the WG though: Do people think the current list of Auth-Failure types is complete enough? Are there other specific cases we want to call out? Right now OpenDKIM puts signature failure details in parentheses after the "signature" keyword, but I wonder if there are some specific failure modes that deserve special treatment so a parser can be sure to distinguish them. Off the top of my head, I can't think of any, but I'd like to poll the group. If there's no other feedback, do people think we're ready to start a WGLC on this one? -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
