|From: Frank Ellermann
|Sent: June 11, 2005 6:05 PM
|
|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.
Hmm ... The IESG considered that SPFv1 was best suited for
experimental status when it called for individual
submissions last October after closing MARID.
The difficulty is that it seems those who have done actual
large scale testing of SPFv1 don't agree with the analysis
that the "protocol works."
I am referencing the MAAWG document filed as an Internet
Draft dealing with SPF.
In addition, you have the decision made by Outblaze sometime
ago to remove its SPFv1 records, which was made public in
April.
As well, if you read what Andy Newton, Carl Hutzler and John
Levine recently wrote on the Marid mailing list and in
particular Andy Newton's suggestion about a framework
approach, reading between the lines, I will reiterate my
conclusion:
"we have learned a lot with SPFv1 - useful as an aid in
filtering, yes - but for anything else, no."
I appreciate that this may be a hard pill to swallow for
many, despite all the hard work done to date, but this is
why I suggest SPFv1 will only be granted experimental status
by the IESG.
Of course, I could be wrong and we shall have to wait for
the ultimate answer.
<snip>
|> 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.
Two things:
* As to the agreement which I reference, ask Meng. You may
recall that he decided to proceed in this fashion last fall
despite vigorous objection from the SPF community and
subsequently there was a press announcement confirming the
renewed support by AOL.
* Given the issues surrounding the SIDF protocol, this is
why SIDF is being considered for experimental status and not
for standard track.
To the best of my knowledge MSN/Hotmail is only using PRA
checks for filtering purposes and not to reject mail.
MSN/Hotmail has added a header to the message indicating the
SIDF result. I suggest this will be the case when PRA checks
are incorporated into Microsoft Exchange at the end of this
quarter.
|>* 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.
I take your point and for now the IESG has refused to give
SIDF a passing vote for consideration for experimental
status.
|> 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 applaud your efforts.
|> 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.
Only one of out 13 times? Your brave. <grins>
Only time will tell.
|> 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_gv00317
e.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.
Yes, I am aware of this recommendation. I am also aware
that:
* Sympatico.ca, the largest ISP in Canada has published an
SPFv1 record ending in ?all, following the lead set by AOL.
* Folks should not take this recommendation to mean anything
more than what it says.
I am going to be bold and suggest that you won't find
any major Canadian ISP which has or will publish an SPFv1 record
ending in -all or is using SPFv1 records for anything other
than an aid in filtering and not to reject mail.
Bottom Line.
I may be wrong, but my opinion remains that the IESG will
not approve SPFv1 for standard track. For now can you and I
agree to disagree? I appreciate you and others within the
SPF Community will do everything you can to persuade the
IESG to approve SPFv1 for standards track. In the
circumstances, I can only wish you well in these efforts.
To put things in perspective, it is helpful to read:
Unsolicited Bulk Email: Mechanisms for Control
<http://www.imc.org/ube-sol.html>
John