On Monday, February 06, 2012 10:03:49 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Scott Kitterman Sent: Monday, February 06, 2012 5:02 AM > > To: [email protected] > > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt > > > > 1. If the DKIM and SPF drafts are supposed to be supported by this > > draft, then the discussion on reporting address discovery is > > inadequate. Those drafts enable domains to explicitly publish reporting > > addresses, so the heuristics for address discovery in this draft are > > inappropriate for those types of reports. > > > > My preferred solution to this problem would be to separate them again > > (not providing a recommended diff since it's just reverting some of the > > changes in the last update). > > That's one option. Another is to indicate that for automatic reports, a > specific reporting address SHOULD be advertised by the party requesting the > reports, and then refer to the two reporting drafts as examples.
I've read the AS draft again and other than the text you just moved into it, I don't find it particularly useful for implementers of auth failure FBRs. I think the minimal efficiency for document producers provided by having one draft to update is more than offset by increased complexity for implementers having to sorth through a lot of irrelevant advice. > > 2. Strongly suggesting use of SPF is, in my opinion, not appropriate in > > a general document like this. The current text adds up to SHOULD use > > SPF. The way it was before (IIRC), SPF only came up in the SPF draft. > > I suspect a general SHOULD SPF is going to be a hard sell in a > > standards track document that's not limited in scope to domains already > > interested in SPF. > > > > 3. Due to now saying senders SHOULD use SPF in the envelope sender > > selection paragraph, the reference to RFC 4408 needs to be normative > > now. > > > > My solution for #2 and #3 is the same as #1. > > The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) could > be moved back to the SPF document, with more generic text left behind in > the AS so that it addresses the problem without naming SPF specifically. Except that as written, 9.2 isn't giving advice for just SPF auth failure results. It's now giving advice for all ARFs (as I understand it), so I don't think it can be pushed off into a document on how to due auth failure ARFs for SPF. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
