Hallam-Baker, Phillip wrote: > I do not think that the IESG should block a proposal citing a > conflict when the real animus here is entirely due to the IPR > issue. Hogwash, I've proposed a way to "fix" PRA to avoid at least the worst incompatibility (a "default Sender" derived from the Return-Path in the spirit of RfC 3834). After that was ignored (maybe it was a bad idea) I proposed a clean "opt-in" modifier for those, where both "boundaries" for PRA and MAiL FROM are in fact identical. After all that is possible, even likely (somebody says 80%). But it is not guaranteed (80% is not good enough, BLs operate near 99.5%). The WG settled on "spf2.0/pra,mfrom" in the last week of its existence, I supported this. Certainly not my fault that the WG was closed exactly at the time when a clean solution was in sight, http://purl.net/xyzzy/home/test/MARID.appeal.txt JFTR. the last quote in this mail was an article from you. MARID was closed as soon as it was clear that abusing v=spf1 for PRA without explicit consent of the sender policy publisher is a non-starter, because it would be _tschnical_ FUBAR. > All SPF does is provide a mechanism whereby sending parties > can describe their outgoing edge mail servers. The recipient > has the absolute right to interpret that data in any way they > see fit. Sure, you do what you like, use PRA, or how about Message-IDs ? Or better try a random generator., no DNS headaches if all you want are random rejections. Most mails are spam, so rejecting mails always hits more spam than legit mail, no matter how you decide this. But v=spf1 FAIL is no 80% or 99.5% idea, it is 100% if you do it right accepting all consequences. "Interpret v=spf1 with PRA" is not implicitly the intent of most publishers. If they explicitly want this they are free to publish spf2.0/pra. We're talking about RfCs defining _sender policies_ - what you as receiver do with it is beside the point, as long as domain owners can express their intention. Several hundred thousand domain owners did this, they know or should know that it means what the relevant v=spf1 drafts said. And the SPF RfC reflects this as good as possible (calling that an "experiment" is a part of the many MARID legends all featuring the "let's steal v=spf1 for PRA" theme). PRA doesn't necessarily reflect what these publishers intended. > That is the entire point of a spam filtering scheme. Neither v=spf1 (spf2.0/mfrom) nor PRA (spf2.0/pra) are a good "spam filtering scheme". PRA is a (dubious) anti-phishing idea, and the MAIL FROM part of v=spf1 fights bogus bounces to innocent (spoofed) bystanders. You can use both as input for "spam filtering", e.g. use PASS as "asssume innocent until proven guilty" like AOL, or use a FAIL as "once a liar, always a liar" indicator for the sending IP or HELO identity. But the primary purpose of v=spf1 is MOT "yet-another-FUSSP". It's about avoiding bounces to spoofed Return-Paths, and maybe offer a base for FQDN-reputation systems with HELO-PASS (same idea as CSV-CSA). So the design goals of v=spf1 and PRA are already different, no surprise that many resulting policies are also different. > Nobody has ever demonstrated a conflict as far as I am > concerned, all attempts to allege a conflict begin, "the > sender intends" which is utterly irrelevant. That's not true, this has been proven numerous times. PRA and MAIL FROM identity can be different for various valid reasons. 2476bis 6.1 and 2476bis 8.1 are different chapters. v=spf1 is in the spirit of 2476 6.1, RfC 3834, STD 10, and draft-hutzler. It has nothing to do with 2822-identities, 2476bis 8.1, or PRA. Essentially PRA wants "SHOULD add Sender" where 2476 only says "MAY add Sender" in 8.1. We could discuss this, and in fact "we" (TINW) did, see also: <http://article.gmane.org/gmane.mail.spam.spf.discuss/8162> That's in the same thread mentioned before (started in mxcomp): http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111 > Sender-ID simply describes one means of interpreting an SPF > record. It may or may not work, it may or may not be optimal If you want "sub-optimal" bogus interpretations then that's your personal right as receiver, but the IETF (mis)represented by the IESG should not sanction this abuse as RfC. You can't publish an RfC where you say "if no MX works just try A", because that would be broken and cause harm. RfCs are not supposed to cause foreseeable harm intentionally - as the very minimum they'd need corresponding security considerations. > that is why it is an experiment. The experimental status of v=spf1 is fictitious and beside the point. The author proposed "PS" with a proper IETF last call. > I do not believe that one group should be able to block a > proposal they do not like by alleging a non-existent conflict Nobody proposed to "block" PRA. It should only stay away from sender policies designed for the incompatible v=spf1. There's nothing wrong with PRA-experiments using spf2-0/pra policies. While I guess that PRA will fail miserably I've no problem if others wish to paricipante in this PRA-experiment. But (not only) I don't want this. No experiments with non-voluntary participants. We're talking about legit mails lost in limbo, and spectacular pseudo-PRA-PASS phishing opportunities. Bye _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf