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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com