> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Murray S. Kucherawy > Sent: Tuesday, July 05, 2011 11:48 AM > To: [email protected] > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- > reporting draft > > > -----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 +1
_______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
