-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all.
I have visited the MAAWG[1] fourth general meeting[2] in Düsseldorf,
Germany, in the past week. I had been invited by MAAWG to represent the
SPF project there. Meng and Shevek were there, too.
Having Fun (Monday)
- -------------------
I arrived on Monday, one day before the conference's official start. In
the evening, I met with Meng and Shevek, and we were soon joined by a few
other visitors of the conference. We had some drinks and talked about all
kinds of things. We were having some fun driving around with Meng's
segway in the hotel lobby, too. ;-)
SPF/Sender-ID Interoperability (Tuesday Morning)
- ------------------------------------------------
The first thing on Tuesday was the "SPF/Sender-ID interoperability" BoF
session. Andy Newton introduced me to the crowd and I explained the
SPF/S-ID interoperability problem, i.e. that there were nearly a million
of v=spf1 records already out there, and that Microsoft was trying to make
use of that. I explained that their PRA algorithm did not yield results
perfectly compatible to the MAIL FROM, because a lot of deployed software
did not set the header identities as expected by PRA, and that a
non-trivial amount of false negatives would arise from that.
Interestingly, no one from Microsoft was there. Doug Otis was there,
though, and raised a lot of general objections to SPF, some of which was
really off-topic for the BoF. His main on-topic point was that nobody
outside the inner circles of the SPF project would care about the
incompatibility caused by S-ID's reuse of v=spf1, and that the v=spf1
record type was effectively burned and beyond rescue. He said that the
world wanted to see a constructive solution to the problem, to which I and
everyone else agreed. However, I objected to the idea that the
incompatibility problems would go away if we just stopped advocating the
publication of v=spf1, which apparently was what Doug wanted us to do.
Doug also tried to suggest that the project was fighting a battle against
Microsoft that it couldn't win against their superior market force, but I
insisted that we weren't actually trying to gain a big market share by
fighting MS, but that we wanted to produce a technically sound standard
that actually worked instead and that we were expecting to draw our
followers through that.
Doug insisted on v=spf1 being scorched territory and that there were
verious implications of publishing v=spf1 in general. To that I responded
that we were aware of those implications and that it was in the project's
full intent to educate publishers about them. I noted that in contrast,
MS wasn't actually taking steps to educate owners of existing v=spf1
records about the implications of not reviewing their policies and not
publishing updated spf2.0 records.
I also noted that I didn't believe that MS actually was in a position to
dictate Sender-ID and the patent-encumbered PRA onto the e-mail world. To
that, some didn't agree, in particular Doug and Meng. Someone said that a
lot of MTA vendors had already announced finished or upcoming support for
Sender-ID, but it was quickly pointed out that a large portion of that
alleged S-ID support was probably really just support for SPF AKA v=spf1.
After it became clear that there was little chance to convince the SPF
project of making some sort of peace agreement with Microsoft to resolve
the contention about the checking of the PRA against plain v=spf1 records,
the discussion actually went constructive:
Throughout the BoF, I had explained multiple times that, although there
were some people in the SPF project's community who had fundamental
objections to having anything to do with MS, the project as a whole was
not against working out a standard in cooperation with MS, provided that
v=spf1 records were left alone, but that MS had never really shown the
desire to directly discuss the issue with the project.
Then Andy suggested that perhaps the MAAWG could play an arbitrating role
in achieving an amicable agreement between the SPF project and MS to
commonly agree on and promote a new, post-v=spf1 record format that would
be feature-compatible to both SPF and S-ID. I responded that I could very
well see this as a possible solution, even if that format would support
the PRA -- as long as MS stopped to re-use v=spf1 for non-RFC2821
identities. Going from my view that domain owners would be advised to
always publish policies at least for the MAIL FROM scope, and that MTA
makers could always choose to simply ignore the patented PRA algorithm and
only check the MAIL FROM (like with v=spf1), I offered to incite
discussion about this within the project. (I'm going to expand on it in a
separate mail soon.)
After the BoF, Doug Otis came to me and tried to convince me that neither
SPF nor Sender-ID (but only DomainKeys & co.) could be considered sender
authentication methods, and that no reputation whatsoever could be based
on the results of SPF/S-ID checks. I objected (search the spf-discuss
archives for why I think that there's no fundamental difference between
authenticating a "domain" entity through authorization of sending MTAs and
authenticating a "person" entity through the verification of some secret
information), but it was kind of difficult to get Doug listen to anything
I said.
Hacking Mail::SPF::Query (Tuesday Afternoon)
- --------------------------------------------
In the afternoon, Shevek and I chose to sit down in a quiet corner and
design a new API for a new incarnation of Mail::SPF::Query (the Perl-based
reference implementation), which would also be used for an XS wrapper for
libspf2 and for a number of other SPF implementations (for instance,
Shevek said he planned to write one in Java, too).
Then we pulled out our laptops and Shevek set up a temporary Subversion
repo so we could start hacking on the new M:S:Q (which will be called
Mail::SPF, by the way) right away. Suffering from the Hilton's extra-
ordinarily bad WLAN connectivity, we hacked for a few hours and found a
number of vaguenesses and ambiguities in the draft-schlitt-spf-classic-02
specification, most notably the IPv4/IPv6 address handling (I'm going to
expand on that, too, later).
We got large parts of Mail::SPF working already, and Shevek promised to
move the code to a permanent Subversion repo after the conference so we
would be able to continue hacking on it then.
In the evening, the entire conference crowd got out for dinner, and I had
another verbose chat with Doug Otis. I guess he tried to probe me for how
well I was able to argue on the various problems of SPF in order to
prepare for his (and my) appearance on the sender authentication panel
that was planned for Wednesday. In particular, he was very determined
that SPF was a great tool for DoS attacks due to its programmability for
extensive DNS querying, however his arguments were mostly based on worst-
case scenarios and unflexible (i.e. unintelligent) behavior of the DoS
target.
The Sender Authentication Panel (Wednesday)
- -------------------------------------------
I spent most of Wednesday preparing my slides[3] for the sender
authentication panel. Originally, Craig Spiezle from Microsoft had been
invited to speak at the panel, too, but he had canceled his appearance in
advance, seemingly for personal reasons. With me on the stage sat Meng,
Doug Otis for Trend Micro, J.D. Falk for Yahoo, Ashok Ramaswaml for CISCO,
and David Mayne for Earthlink. Tripp Cox introduced us and moderated the
panel.
I presented SPF and some aspects about its deployment, such as potential
problems, deployment recommendations, and details about the adoption.
(See my slides[3] in PPT or PDF format.) I exceeded my 10min timeslot by
about 5min, and Tripp Cox got a bit nervous about it, but I think it was
OK since the largest part of the remaining time was spent by the others
telling about DomainKeys, IIM, DomainKeys/IIM, DomainKeys deployment
experiences, DomainKeys implementation details, etc. pp., and of course by
Doug Otis more or less explicitly ranting about SPF.
A 10-15min Q&A round was planned subsequent to the presentations, but since
the panel had gotten started late and also my presentation had taken a bit
longer than expected, the Q&A round was not performed.
Finally, the panel ended and while the others headed for the evening's
reception, I had to pack up and leave for the airport in order to catch my
flight back home.
Conclusion
- ----------
All in all, I think the BoF was quite productive for all who attended
(myself included), and I think that with the help of some of the MAAWG
members and/or Andy Newton, a resolution for the SPF/S-ID problem can
actually be found with MS, if we want to engange in that direction. Also,
I think the presentation at the panel was a good opportunity to clarify
some of the most common misconceptions about SPF and S-ID. And finally,
Shevek and I managed to get some code done for the new Mail::SPF.
Julian.
References:
1. http://www.maawg.org/about/
2. http://www.maawg.org/news/GeneralMeeting_June05/
3. http://www.mehnle.net/papers/spf-maawg4.ppt
http://www.mehnle.net/papers/spf-maawg4.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCv3XWwL7PKlBZWjsRArzwAKDyoC5hoPnxaZpyLLBhnMzt65syAgCgt8BM
g3lNPnUwQiVSy6BAiK855pk=
=qssY
-----END PGP SIGNATURE-----