wayne wrote:
[Julian said:]
Such a contradiction could be a reason to ask the IESG to
change their IESG note for the SPF spec, or to escalate the
appeal to the IAB.
Yes and yes. More the latter, because the note is not exactly
our business, the IESG should be free to say what they think,
as long as it's technically correct.
I'm not sure that there is a contradiction here.
2119 SHOULD NOT and SHOULD are incompatible.
SPF records can be used with other identities if you are
careful with the technical details.
Yes, 2119 SHOULD NOT (= NOT RECOMMENDED) and "can" is okay.
e.g. if records signal this explicitly by op=pra or similar.
For example, I can't think of any problems that would be
caused if SenderID only gave PASS and NEUTRAL results.
A PRA-PASS on v=spf1 designed for 2476bis 6.1 (without 8.1)
is the "phishing superhighway". 2476bis 6.1 is good enough
for an op=auth "HARDPASS". But it fails miserably with PRA
and cross-user PRA-forgeries.
I don't think the SPF RFC referring to the Sender ID RFC
("section 3.4 of RFC XXXX") is appropriate.
That's in the IESG note, not in the SPF spec. proper
From the IESG's point of view, this is the only appropriate
solution.
s/the only/an/ They missed the "only appropriate solution",
maybe the IAB finds it: Four characters in XXXX 3.4 are wrong.
I highly doubt that any other standards body is going to be
more vendor neutral.
Yes, if we and the IESG missed and still miss serious technical
problems like the "phishing superhighway", then nobody else
will see it, last chance IAB.
I will not approve of an appeal to the IAB.
I do, "v=spf1" simply doesn't work as expected with PRA tests.
We have a chance to educate users about adding TYPE 99 to TXT.
But SPF is doomed if we try to educate them about adding three
instead of only one record:
SPF "v=spf1 co=py"
TXT "spf2.0/pra"
SPF "spf2.0/pra"
That's FUBAR. And the last time you tested it you found that
it has no effect. Either stop this PRA-abuse or kill v=spf1.
Before this gets out of hand deleting legit mails worldwide.
Bye, Frank
-------
Sender Policy Framework: http://www.openspf.org/
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