Representing SPF at ETC

SPF Team-

I attended ETC (Email Technology Conference) and did my best to represent 
SPF to the masses, as Meng was not available to attend this one.  Here is a 
brief recap of the trip.
After spending too long looking for parking near CalTrain in Mountain View, 
I gave up and drove to Lawrence station, which is a tad further from SF but 
closer to my house.  I rode up on CalTrain to Millbrae and transferred to 
BART, which deposited me literally 5 steps away from the Palace Hotel in SF.
I got my badge and wandered about looking for anyone I might know.  I saw 
Phillip Hallam-Baker first (of Verisign) and talked to him for a few 
moments, then went into the main hall to hear the end of some session.  I 
didn't catch most of what they said since they were near to wrapping up, 
but I did hear phrases like "Sender ID and other IP-based authentication 
schemes are definitely a good first step" and "next steps that build on the 
base established by Sender ID and the like."  I was happy to observe that 
we are getting air-time in big sessions like that.  I took advantage of the 
free wireless connection and checked my mail.
After that was over, I went up the stairs to the smaller rooms where the 
breakout sessions were held.  The session I needed to be in was called "Can 
SMTP Be Saved?"  I found the right room and settled in.  The session soon 
filled up -- there were probably 80 people seated and another 20 or so 
standing at the back and at the sides.
A brief introduction was made by John Levine, and then I was up first.  My 
job was to explain a bit about SPF, then explain the merger proposal we are 
calling "Sender ID", all within 10 minutes.  (My slides are viewable here: 
<http://www.nekodojo.org/~gconnor/Slides/> )
Here is a quick overview of my talk.  I was a little nervous but I didn't 
do too badly - I think I only said "uh" like 100 times, which is not bad 
for me :)
01 Typical SMTP transaction
I asked for a quick show of hands "How many here have heard of SPF?" (just 
about all) and "How many have browsed a couple pages of the SPF site?" 
(about half).  Given this level of familiarity, I just jumped right in with 
the first slide, showing an SMTP transaction and separating out the 2821 
and 2822 parts.
02 Choose a domain
The next slide just points out which domain/identity gets chosen for 
SPF+SRS and CID-PRA.  I touched briefly on the difference between "before 
data" and "after data".
03 Typical forwarded message
Showing a typical forwarded message, I talked about the impact to 
forwarders with SRS (rewrite MAIL FROM but you get to discard before DATA) 
vs. PRA (Add a header, reject after DATA).
04 Sender ID
The same forwarded message, showing only PRA, indicating that this is one 
part of the Sender ID merged proposal, that we use PRA and delay checks 
until after DATA -- for now.
05 Merged proposal info
I talked about the differences between SPF and CID, in some key areas (see 
slide for details).  The green areas show the areas where each is perceived 
to be stronger.
06 Merged proposal 2
I then talked about the merger proposal and how it has 2 out of 3 strong 
points from each... easy for forwarders, easy TXT format (or the choice of 
one anyway) and delaying checks until after data -- again, for now...
07 Submitter RFC extension
I explained the idea for a change to SMTP that allows a "sneak preview" of 
the PRA before DATA, thus giving us back our third advantage, after a time.
08 Where to go from here
Talked about the next steps for the various stakeholders, but the stress 
was on "Publish your records now".

Next speaker was Miles Libbey, who talked about Yahoo Domain Keys. 
Basically it was an overview of domain keys and how it works.

Next was Pat Patterson of Ironport who spoke about reputation systems. 
Some points I remember:
 Don't set expectations too high for these proposals - we don't want 
people to think we are solving spam and then get disappointed.
 Don't use authentication as a whitelist - spammers will certainly publish 
their own records.
 Do use reputation systems
 Spam fight will be ongoing


Next was Rand Wacker of Sendmail Inc.  He put up a slide showing 
authentication and reputation as a part of a larger system, which was 
sensible-looking :)  He also put up a sample of a MUA program that had some 
visible feedback when the mail was verified (in this case it was the 
company logo of the sender in the header area next to the From:).  The 
point seemed to be that we need to make the technology readily visible and 
accessible to the user for it to get widely used.

Next was Phillip Hallam-Baker of Verisign.  Here are some points I remember:
- Problem with online fraud, one theory is that the phreaks and hackers of 
the 90s are "all grown up now" and trying to make a living off of gaming 
the system, and hence graduating to new and different kinds of fraud.
- 3 stages: Authentication, Reputation, and Enforcement.
- Need to have real consequences:  Legal? Financial? Economic?  If you 
fine some big company $10,000 they might not notice, but if you can cut off 
the CEO's email for a day, that would get noticed :)
- Need to question our assumptions, sacrifice our dogma:
   - A system is as weak as its weakest link?
     No, we have seen that attackers will attack where there is the most 
profit to be made from breaking something, they don't attack more 
frequently where the defense is weaker.
   - Bad security is worse than no security?
     No, the perfect is the enemy of the good.  (Example of SSL exploits 
and updates).  We can produce good protocols and update them after 
deployment, much faster than we can roll out perfect protocols.

Last was a Q&A session, focusing on "Where to go next?"
- Reputation systems got mentioned a lot.  What if someone has a new 
domain and doesn't want to pay for accreditation?  They will build up a 
good reputation by sending email and not abusing it.
- How soon can Sender ID be implemented?  Rand Wacker said "Pretty fast". 
:)
- What about the forwarder problem?  How soon are they going to be 
compliant, and how can we tell if they are?  I made the point that some of 
the large receivers will be in a good position to help themselves and the 
community as a whole by turning stuff on in "log and report" mode at first, 
and they will put pressure on the non-compliant forwarders anyway.
- Possibilities of using rate-limiting with a reputation system - if 
someone has no good and no bad info, rate limiting might be good, until 
they start to show one way or the other.
Ended with a show of hands.  How many folks will be implementing Sender ID 
or something like it within the next year?  (About 2/3)  How many folks 
have already implemented Sender ID or something like it?  (About 1/4)

After the session, I went out into the crowd to talk to a couple people who 
had asked questions.  One guy had asked if he would need to support XML in 
his MTA (John L and I both said, "That issue is being hotly debated as we 
speak") and he expressed that he would never support XML.  I figured it 
would be someone I know from the lists.  Turns out it was Julian Haight 
from SpamCop!  (More accurately, SpamCop is from him :)
I talked to Julian and a few people who hung around... I expressed that 
even if XML was in the spec, SPF format would be "grandfathered in" and 
would be well-poised to become a de-facto standard anyway.  Also we talked 
about forwarders and false positives, and I managed to convince one ISP 
person (Matt I think was his name) not to discourage his customers from 
publishing... it would be much better to encourage them to publish ?all 
records than to discourage them from doing anything... and I also mentioned 
trusted-forwarder.org and he said he would check it out.

Other interesting tidbits... the trend of people mentioning Sender ID 
continued from the main session into the breakout session.  I think Sender 
ID was mentioned more than SPF, more than Caller ID, and more than domain 
keys.  MARID wasn't mentioned much, strangely...

I headed home, and after 1 hr 40 min on trains, found my car still in the 
spot I had left it.  I have a pretty good feeling about everything and it 
was really cool to see not just how many people were interested, but to see 
how many people already knew about Sender ID.
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>