On 18 August 2011 23:34, Murray S. Kucherawy wrote: > Section 3 should probably include a sentence at the end that says “In the > absence of an ‘r=’ tag in the SPF record, all other fields defined above > MUST be ignored.”
+1 I don't see the difference between exp= and rs=, if it is in fact almost the same an explanation of exp= in the context of MARF would be better than a new modifier. IMO result SOFTFAIL implies "want report", there should be no opt-out in ro=. Any PERMERROR or SOFTFAIL must be interesting for somebody wishing to get reports at all (limited by ri= if desired). A FAIL report is slightly dubious, if it's a bug in the policy senders got an ordinary bounce (or a "go away" for their FAILing EHLO), and need no extra report blowing up their logfile. They certainly need no report if some spammer forges their EHLO or MAIL FROM in thousands of FAILing mails, eliminating backscatter is one of the main points of SPF. It makes no sense to replace backscatter by opt-in FAIL reports. If the receiver does not reject FAIL curious senders might be interested in the fact, but then ro=f could be limited to "unrejected" mail, or let's just say ro=f is bogus. OTOH ro=n could be very interesting, if it is something that should be PASS or FAIL instead of NEUTRAL. Suggestion: ro=debug or ro=default, where "debug" asks for any NEUTRAL reports in addition to the default PERMERROR and SOFTFAIL. Obviously there can't be SOFTFAIL reports for a policy without SOFTFAIL outcome, and that is as it should be, but explaining it in the draft helps. All bytes in an SPF policy are precious, ro=d for "debug" and no ro= at all for "default" might be good enough. > Some of the stuff in Section 6 looks like it might have been copied > verbatim from [ARF] or [DSN] (though I’ve not confirmed this). If > that’s the case, I’d prefer to see them incorporated by reference > rather than by value. Okay, but for very important security points explaining what the given reference is about helps. The author can demonstrate to know what it says, readers have no excuse to say that it was hidden in a reference. > I also wonder if any copied from draft-ietf-marf-authfailure-report > and/or draft-ietf-marf-dkim-reporting should also be incorporated > by reference SPF and DKIM tend to be orthogonal (as designed in the case Of DKIM), what do you have in mind? I have not yet understood the difference between the r= address in I-D.ietf-marf-spf-reporting and section 7.2 in I-D.ietf-marf-reporting-discovery-01. > there’s still an open question about whether Section 5.1 belongs > here or in the fledgling SPFbis effort. Quite a lot of folks volunteered to help with 4408bis, I hope that can be done (= ready and published) in a few months. If that's the case it is not really necessary to create an SPF modifier registry now: IOW, there won't be any conflicts with the MARF SPF modifiers. IIRC and if I did not miss something in 2009 or 2010 these are the first *new* suggestions for modifiers since RFC 4408 got its number. The simplified ro= proposed above could be queezed into op= options to save bytes, or better, some remarks about "new modifiers in SPF" in the old op= draft can be adopted in I-D.ietf-marf-spf-reporting. > Replace Section 5 with text that basically says we know SPF doesn’t > allow unknown modifiers That is not exactly the case, see RFC 4408 section 6 intro. The main problem are new yes/no SPF modifiers claiming to have a default, and "opting in" SPF policies published years before the modifier existed. This would be strictly against the SPF design, working policies are supposed to work without "upgrades" as long as they describe the IPs permitted to send MAIL FROM, etc. No need to "opt-out" from any new tricks, the main topic of the old op= SPF draft. Where precisely is the ball or token wrt a 4408bis WG at the moment? -Frank _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
