> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Tuesday, July 05, 2011 11:00 AM > To: Hilda Fontana > Cc: [email protected] > Subject: Re: [marf] Cohesion of authfailure-report, was Split of > dkim-reporting draft > > Roughly, a section more or less like > > X.Y.Z. Definition and Registration of Method-Specific Extensions > > The IANA maintains a registry of Email Authentication Methods > along with their possible results. A "method-specific extension" > extends an authentication method by providing for the possibility > to report its result using the ARF format specified in this > document. Any such extension must specify: > > * which method(s) it addresses; > > * which result(s) of the addressed method(s) deserve being > reported; > > * a list of one or more keywords to be used in the Auth-Failure > field when reporting such results; and > > * the location and the syntax of the report parameters whose > semantic content is described in Section U.V.W. > > In addition, a method-specific extension may define further ARF > header fields. In case it does so, it shall also define the > corresponding updates to ARF header field names in its IANA > Considerations section. > > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and > rs too. Not how they are syntactically encoded, just what they mean. > > Does the above make sense?
We're adding DKIM and SPF reporting to ARF in this way because they both pre-date ARF in the official sense. I think the current approach makes sense; this document extends ARF and the spf-reporting and dkim-reporting documents extend SPF and DKIM respectively, and they're all compatible with each other. I think if the working group feels this is a good idea to write down for future extensions, we can produce another Informational document that explains the things one should consider in terms of creating a new email authentication method, including registering and defining reporting extensions both in terms of ARF and RFC5451. Or, as a lesser approach, that could become an appendix of this one. > Indeed, I think authfailure-report can be written without mentioning > neither "dkim" nor "spf", except for possible examples. I guess that > would enhance comprehensibility. However, the WG should decide > whether to go this way _before_ delving into any finer tuning, if it's > not too late already. Ignoring redaction for the moment, what we have now is: - authfailure-report modifies ARF - dkim-reporting modifies DKIM and ADSP - spf-reporting modifies SPF That seems nice and clean. Your proposal changes it to: - authfailure-report modifies ARF - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure-report - spf-reporting modifies SPF, and also modifies authfailure-report At a glance the first method seems cleaner to me. On the other hand, the latter is a more clear demonstration of how future email authentication methods will need to create reporting hooks. What do others think? And let's try to make this the last revisit of the arrangement of this work so that we can make some progress. Thanks, -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
