|-----Original Message-----
|From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-|discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Frank
Ellermann
|Sent: May 23, 2005 12:40 AM
|To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|Subject: [spf-discuss] Sep 22 - Jan 03 (was: PermError and
|NXDOMAIN in spf-01)
|
|wayne wrote:
|
|> While I agree that MarkL worked hard and tried to do what he
|> thought was best, I disagree that what was created was widely
|> accepted as an "SPF classic" draft.
|
|It was _here_ (I'm not saying that anybody implemented it), it
|was a fast shot for almost the same $reason why there now is a
|new -01 soon to be replaced by a -02. E.g. Stephane asking for
|a new SPF RR based on no I-D at all won't work.
|
|> It wasn't *just* me who had problems with it.
|
|Sure, the "FAIL malformed domain" was a profoundly bad idea -
|to be fixed in whatever came next.
|
|> I also disagree that we couldn't have had a much more
|> compatible draft submitted to the IETF within the timeframe
|> that the lentczner draft was submitted.
|
|You were absent when MarkL started. You came back with a ton
|of objections when it was almost ready (for its purpose as
|fast shot). And while I agreed with all principles in your
|"unofficial manual" the same was not immediately true for say
|James. Some details like the 3 * 10 limit needed discussion.
|
|> Feb 11 draft-mengwong-spf-00 sent to the IETF
|> May 16 draft-mengwong-spf-01 sent to the IETF
|
| Sep 15 draft-ietf-marid-mailfrom-00
| Sep 15 draft-ietf-marid-protocol-03
|
|Whatever you thought, I considered that as MARID finally
|starting to see the light. Unfortunately not for long...
|
| Sep 22 MARID: appeal
|
|> Oct 13 draft-lentczner-spf-00 sent to IETF
|
| Oct 14 draft-leibzon-responsible-submitter-00.txt
|
|> Oct 15 first release of draft-schlitt-spf-00pre1
|> Oct 16 release of draft-schlitt-spf-00pre2
|> Nov 3 release of draft-schlitt-spf-00pre4
|
|All claiming to be "libspf2 manuals not intended to be sent
|to the IETF", yes. As relevant as say the "op=" SPF draft.
|
| Nov 11 SID drafts published via the IETF
|
|> Nov 15 release of draft-schlitt-spf-00
|
|No I-D at this moment. Some individuals claiming to be part
|of an obscure "SPF community" like it. Relevance for the
|IESG (incl. Ted) from their POV: zero.
|
|> Dec 22 draft-schlitt-* drafts are official
|> http://spf.mehnle.net/Council_Resolution/17
|
|Read: Now this obscure (outside POV) SPF community appears
|to have some formal body acting as speaker, and internally
|they apparently prepare to replace draft-lentczner. But I
|very much doubt that the world at large (incl. IETF / IESG)
|has an idea what draft-schlitt-spf-00 might be.
|
|> the mengwong-spf-0[01] drafts were the official drafts for
|> 5-8 months and the status wasn't controversial.
|
|The mengwong draft was clinically dead after the first bug
|in the ABNF was detected. Latest since Sep 15 from my POV:
|
| This Internet-Draft will expire in September 2004.
|
|> lentczner-00 was official for at most two months
|
|Not for the IETF / IESG, draft-lentczner -00 was the only
|classic I-D for three months, that's a quarter of the year.
|
|> the SPF community has always been somewhat seperate from
|> the IETF.
|
|Not from my POV, since Meng's "CYA" I always wanted an RfC
|clearly stating the facts. Not some obscure texts free to
|be twisted into whatever MS or Meng like next. And I still
|trust that the IETF won't take any shit.
|
|There was no such thing as an SPF Council for two critical
|months, there was only John Glube trying his best, and a
|"private list", where Meng played delaying games.
|
|Technical stuff snipped, I've submitted it as new [Discuss]
|"for SPF Council review".
Bye, Frank
Having been around for the period that Frank wrote about, I agree
with his factual review.
The only point he missed is that Meng made a deal with AOL and
Microsoft. In essence, AOL agreed to publicly support SIDF when
Microsoft agreed to change their specification and spf2.0
"backward compatible."
In turn, Microsoft agreed to support publishing of v=spf1 records
and only push spf2.0 records as needed, through their wizard.
At the time, I felt that was a bad arrangement, in part because I
always felt that Meng lost a golden moment, between the deadline
of the email authentication summit and the need for cohesion
between AOL and Microsoft.
To me, it has always been a technical mistake to use SPF records
published to support IP/domain based SMTP mail from
authentication as a platform to fight phishing.
There are enough issues surrounding the SPF approach without
compounding the problem.
Sure, the financial sector may want a "band aid," but why should
technologists give them a "band aid" which has the potential to
create just as many problems as it attempts to solve.
Of course, I also understand market economics and when the
financial sector speaks, people listen. "He who has the gold
makes the rules."
Having said this, when the deal was announced, I did negotiate
directly with Microsoft to compel them to honour their part of
the bargain as to the wizard, while making it quite clear, I
would continue to raise pointed objections both about the license
and the technical merit of SIDF.
As an aside I recall the weekend before the email authentication
summit. I spent the whole weekend drafting a response to the
Microsoft statement and pounding on Microsoft to get them to
honour their bargain.
When nominations were held for the Council, I was asked to stand,
but declined making it clear that in my mind CSV was a better
proposal for mail stream authentication.
When the vote was held, I voted and since then have essentially
let the Council carry on with its work.
My biggest problem is that the Community is trying to do a number
of things with SPF at once:
* Put together a document which reflects what SPF was in the
field;
* Wanting to take this document and turn it into a standard, when
there are known issues surrounding SPF.
I appreciate that Wayne has posted the ID draft to various IETF
discuss lists seeking comment. However, the unfortunate reality
is that spammers have figured out ways to "game" SPF.
(See the discussion on this list concerning German spam and
recent discussions on Spam-L.)
* Use SPF to both authenticate the mail stream and validate the
return path.
I don't agree with the present approach of expanding SPF to cover
EHELO/HELO checks, simply because SPF was designed to focus on
the SMTP mail from authentication.
If you think that checking EHELO/HELO makes sense, I feel it is
better to say to people publish CSV records and either
incorporate CSV checking and that whole design into the SPF
specification, or simply recommend that folks use CSV.
Why? In my view, the design parameters for checking EHELO/HELO
and SMTP mail from are different.
(Yes, this is a change in my position, but then as time passes,
hopefully you learn from your mistakes and so get wiser.)
I firmly believe the other mistake folks are making is not
sitting down and talking with MAAWG and in particular the email
design at AOL lead by Carl Hutzler to find out what are the
actual concerns and problems.
That's why I raised the IESG concerns. Because I knew that many
of the big ISPs were concerned about SPF for a variety of reasons
and the big ISPs (other than MSN/Hotmail) are only using SPF
records to authenticate the mail stream for white and black
listing purposes.
I realize that this means SPF can't realistically be used to stop
spam as some have advocated, but then it was never designed with
this purpose in mind.
Sure, if you have a small network, it is your network and your
rules. But, if SPF is going to be used as a tool by smaller
networks, rather than write a specification which reflects what
SPF was, why not write a specification which takes into account
all of the bugs and lessons learned along the way?
I see some evidence of this, but when folks talk about making any
change to correct an obvious difficulty, there is always the
concern, what about the legacy implementations. Well, guess what?
To the consumer, being both senders and receiving networks, this
whole exercise is an experiment.
Everyone who has published a record, or who has implemented SPF
checking, at least based on my guidance, has also been told this
is an experimental proposal and is subject to change.
As far as SIDF is concerned, my own feeling is that I appreciate
MSN/Hotmail is looking for a band aid for phishing. If
MSN/Hotmail wants to use v=spf1 records for that purpose, that's
really between the IESG and the proponents of spf2.0.
Having said this, I respect the SPF Community for taking the
stance in the SPF protocol that it is recommended v=spf1 records
should not be used for any other purpose.
Why? Because message authentication is best carried out by a
light weight cryptographic solution and to my mind, SPF should
not be used for message authentication.
(Yes, I understand DomainKeys has its own issues, but at least
with the DomainKeys design team, everyone understands this is an
experiment, we want consumer feedback, the design will probably
change to incorporate all the lessons learned.)
The whole underlying premise of the SPF design was to ensure that
"bounces" went to the right place. How was this to be achieved?
By asking the simple question, is the return path address
authorized for use by a particular MTA. Yes, fine. We can move to
the next stage. No, then the message should be rejected at the
Data stage and since the MTA was not authorized by the sender to
use this return path address, drop the message.
In turn, since one aspect of spamming is appropriating other
people's property, this design could if feasible have the goal of
going some way to thwart the garden variety spammer from hiding
his, her or its identity.
But, and this is very important, email authentication will *not*
stop UBE, nor online abuse.
The unfortunate difficulty is that message forwarding tends to
mess with this solution.
To my own way of thinking, if a receiving network wants to use
SPF to reject mail, then it needs to take a stand on how users of
their network are going to conduct message relaying and
forwarding.
In reality, the SPF community needs to say:
* Senders, publish your records.
* Forwarders, implement message header re-writing;
* Receivers reject at the Data stage.
The problem is that this is a bit like someone standing at the
water's edge in face of a tidal wave and saying, "I command you
to stop."
The SPF community also needs to acknowledge that until forwarders
implement message header re-writing and all the big consumer
networks publish SPF records, this creates a significant risk of
false positives for those who publish records ending in -all.
To avoid this risk, senders should publish records ending in ~all
and receiving networks may only want to use SPF records for
verifying the sender's outbound mail server, so allow for better
use of white and black listing for filtering purposes.
(In essence, a hacked version of CSV.)
I appreciate this does not achieve the original design goal, but
then it also recognizes the reality and is further support for
the position, "thou should not use v=spf1 records for any other
purpose."
I am discounting the trusted-forwarder.org set up, because this
is a band aid solution, unless people are prepared to accept that
this is an interim step and the trusted-forwarder.org site is
changed to reflect this reality.
Okay, here ends my rant. I am now going back to lurking.
John
P.S. I appreciate that people have and will continue to put a lot
of effort into SPF and I applaud those who participate and
exercise leadership.
John Glube
Toronto, Canada
voice:416-535-6366; mailto:john(_at_)trusted-email-sender(_dot_)com