John Glube wrote:
* The IESG is only going to approve the protocol for SPFv1,
which attempts to document what has been done in the field
as an experimental document.
See subject, they're free to pick any ridiculous status they
like. We had this debate already, hundreds of thousands
domains, several independent implementations, practical use
for at least 15 months (taking the AOL experiment as "start").
And if that's an _experiment_ I would ask them in public why
something like 3066bis incompatible with some aspects of 3066
should be the new "BCP 47" without any prior practical tests.
Talking about double-standards, it's about their credibility.
* If people want to move SPFv1 forward on a standards track,
you need to set out what has been learned
We learned that it works as expected and that adding Wayne's
processing limits to the spec. was a good idea. I can't tell
you why "we" didn't learn to specify the PermError codes, and I
will probably try to get them back in the IETF "last call".
Anything else is just fine as far as I can judge it. I could
certainly live with documenting the Received-SPF header field
elsewhere or nowhere if that turns out to be an SPF showstopper.
the recommendation made in the protocol for SPFv1 concerning
the use of these records conflicts with the backward
compatibility agreement that was reached between Meng (one of
the editors), AOL and MSN allowing the use of SPFv1 records
for the purpose of PRA checking and as reflected in SIDF.
There is no such "agreement", and it was always clear that no
such "agreement" is possible, because v=spf1 and PRA are just
INCOMPATIBLE. Is the IESG about ENGINEERING, or are they in
the pocket of some big players ?
They'll also answer this question in public. Here's what Meng
said about it, in that famous thread started by you in mxcomp:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/8119>
John, this is serious. I'd call for an investigation of this
issue by law enforcement agencies. We're not in a 2+2=5 movie.
* The IESG were to decide to reject SIDF for experimental
status (which is unlikely);
This is _very_ likely, unless Jim removes the offending SHOULD.
Intentionally causing loss of legit mail is gross negligence at
the very minimum. And in reality it would be a breach of all
ethical standards I ever heard of.
In my view the IESG is going to resolve the matter by stating
that both proposals should proceed as experimental standards.
Not with the offending SHOULD. This would kill them, because I
am determined that it won't happen.
I may be wrong, but I do feel obliged to tell people.
I'm almost certain that you're wrong, at least some of them are
decent folks just trying to do what they think is the best for
the net at large. I reserve the right to err in at most one of
13 cases.
this is why I think the work done by the Canadian Task Force
on Spam, which builds heavily on what was done in Australia
merits close study.
http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/h_gv00317e.html
http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00329e.html
| RECOMMENDED BEST PRACTICES FOR INTERNET SERVICE PROVIDERS AND
| OTHER NETWORK OPERATORS
[...]
| 1. All Canadian registrants and hosts of domain names should
| publish Sender Policy Framework (SPF) information in their
| respective domain name server zone files as soon as
| possible.
[...]
| At this point in time, the SPF classic (SPFv1) proposal is
| the most technically mature and widely deployed sender-
| authentication scheme.
Bye, Frank