On Feb 4, 2012, at 10:25 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Alessandro Vesely >> Sent: Thursday, February 02, 2012 10:45 AM >> To: [email protected] >> Subject: [marf] Change request for AS, was Working Group Last Call on >> draft-ietf-marf-as-05 >> >> At the risk of being proposed for a treatment, I retract my post and >> ask that a new section be added to marf-as, about loop avoidance and >> control of flow. >> >> The new section would cover FBL traffic details such as using VERP and >> replying 552, which are to be used by all of dkim-reporting, spf- >> reporting, and reporting-discovery. Read more on, e.g. >> http://www.ietf.org/mail-archive/web/marf/current/msg01910.html > > I support the idea of common-factoring what's in > draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through 8.6, > and parallel text in draft-ietf-marf-spf-reporting, or very similar text, > into the AS. The AS is supposed to be a statement of "this is how we suggest > you use ARF" and those strike me as reasonable things to include in such a > document even without the reporting drafts. Do others agree?
Is the thought to add them to the AS document as a section on how to craft and send an ARF message that's being used for SPF or DKIM failure feedback? Or as something that's more generally applicable to all ARF usage? Or something in-between - FBL best practices, say? (Also, if we're going to do that, should we reference 3834 - Auto-Submitted and all that - as well / instead?) It does seem to make more sense to have them both referencing a base "reporting auth failures" document that covers the common requirements rather than referencing each other, whether that base doc is draft-ietf-marf-as or not. > If people don't like that idea, then I would instead suggest at least > removing them from one of the two -reporting drafts and having that one > reference the other one. I'm not too keen on the exact same text appearing > in two documents if we can avoid it. Again, do others agree? Yes. > I don't (currently) agree that the rest of the suggestions at that URL > particularly benefit either of the documents. Others should chime in on this > point as well. Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
