The following describes in detail what I hope to accomplish
today at the SPF/ID BOF at the Inbox Event. Patches welcome.
For background, please see
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0463.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0468.html
Tentative Agenda, rather wordy
estimated reading time: 3 minutes
Note that "AGREED" shows what I hope for people to agree on
for that topic.
1) Introduction by Meng.
These next two hours will not be the be-all and end-all of spam.
Even if this meeting goes well and SPF/ID rolls out
successfully, there is no doubt in my mind that there
will be many more campaigns and meetings and efforts just
like this one. Spam is a moving target. Protocols
change. And crypto should become a standard part of the
email of tomorrow. Until that day comes, our work is not
done.
2) The goal today is to set a schedule for widespread
deployment of SPF/ID. SPFv1 has already been in the
field for half a year in testing/experimental mode. Time
to kick it up a notch. Deployment has two parts:
publishing and receiving. Publishing comes first,
receiving comes second. We'll talk about both today.
AGREED: majority of people in room agree that the time is
right to move ahead.
3) Also, we need to pick a name.
Caller SPF?
Sender-ID?
SPF-ID?
Microsoft SPF?
SPF v2?
I think the community should decide. Letting the
industry community pick a new name gives them unity
and emotional ownership of the project.
Also, there may be some legal problems with the name
"Caller ID for Email" --- see
http://www.calleridforemail.com/CallerIDForEmail.asp
Samantha McManus may give some input on strategic
communications.
AGREED: working name SPF/ID or something like that.
4) The industry needs to coordinate a deployment schedule.
The industry leaders in the room are sufficient to
provide critical mass. All they need to do is agree :)
Dave Anderson can help Meng make this case.
Before the train leaves the station, stakeholders should
get a chance to help set the schedule.
AGREED: a coordinated deployment schedule / project
timeline is worth developing today. And by "today" I
mean June 3rd 2004.
5) The industry leaders also need to work together with the
people who are not in the room. To reach them, we need
to use the media effectively. Changing SMTP means a big
PR campaign. I expect the events that occur today will
be reported in the media under the headline "Industry
Leaders Agree to Roll Out Antispam Standards". We've
waited long enough.
Exec types and PR people in the room may comment.
AGREED: if we agree on dates later, or at least agree to
agree, press in the room may report that the industry is
finally moving and the email community will soon be put
on notice by, uh, the email community.
6) SPF/ID has two major applications:
- improved IP whitelisting.
- enabling forgery detection.
They are two sides of the same coin.
Which is more important? It depends who you are.
In rollout terms, whitelisting probably comes first.
Carl Hutzler to share plans for SPF whitelisting.
AGREED: while SPF/ID is not a perfect solution, it
provides enough value today that we should direct serious
effort at it now, while also pursuing other avenues.
7) note that the SPF/ID specification is still in flux re
the XML stuff and the header algorithm. But the actual
SPF evaluation logic, which operates against a set of
parameters passsed to the API, is stable and has been
implemented far and wide.
The way to manage this uncertainty is to write modular
software.
Commercial implementations should not wait; but they
should, however, design for change: today the address
parameter comes from MAIL FROM, but tomorrow the address
parameter may come from SUBMITTER or the PRA. That
should be a very easy tweak.
Theo Schlossnagle may wish to assure people that
implementation is really easy.
AGREED: MTA vendors will allocate resources to implementation.
8) If the SPF/ID effort goes well, the next round of
industry change should be in the direction of DomainKeys
or something like it. The SPF community is already
thinking of how to extend the SPF/ID syntax to describe
DK, SMIME, PGP and so on for author verification as
opposed to sender verification.
Mark Delany to state DK's requirements for the policy
document space.
AGREED: we don't have to do everything today; we don't
have to get it right all at once.
9) These are the key events for adoption/deployment.
Some degree of coordination would smooth the process.
Some of the dates depend on other dates happening first.
Some of these prerequisites are local, others are global.
Dave Anderson to lead this discussion.
Whitelisting comes first; then spoof detection; then the
strong form; then we move to crypto.
I want to set dates today for A, B, C, D, and E.
I expect this to be lively; people may say "oh, but we
can't make X date for Y reason" and others may say "but
the sooner the better". So we need to find consensus.
AGREED: dates for A, B, and C at least, and projections
for D and E.
---- WHITELISTING ----
A) receivers who want to use SPF for whitelisting
develop a capability: the ability to test SPFv1 on
the inbound side against the return-path.
NOTE: This is already well underway.
B) senders who want to be used for whitelisting publish
SPFv1 records with a "?all" or "~all" default.
NOTE: This is already well underway.
A and B go together. Accreditation services nascent in
this phase. Aim: mid-July 2004.
---- SPOOF DETECTION ----
C) affected senders implement workarounds (either SUBMITTER or SRS)
- forwarders (acm.org)
- web generated emailers (evite.com, ebay, amazon?)
- mobile devices (blackberry)
- ISPs support SMTP AUTH and educate users.
NOTE: This is already underway, but needs a kick.
Microsoft can help by providing use cases.
IETF can help by putting spec on standards track.
D) receivers who want to use SPF/ID for spoof detection
implement SPF/ID on the inbound side against
SUBMITTER and the 2822 headers.
E) senders who don't want to be
spoofed/joe-jobbed/phished publish SPFv1 records.
The default record should be "~all" or "-all".
Domains that never send mail, including the big
parking services, should publish -all.
NOTE: This is already well underway.
C, D, and E go together. Accreditation/reputation
services will arise during this phase. Aim: November
2004.
---- THE STRONG FORM ----
F) when a majority of legitimate senders are publishing
SPFv1 records,
G) receivers begin to apply a best-guess default to
domains that do not publish SPFv1 records. This
solves the legacy, unmaintained MTA case.
The best_guess default is "a/24 mx/24 ptr".
H) receivers put the world on notice that incoming mail
that does not pass best_guess and that does not have an
SPF record may be scored negatively by spam filters.
F, G, and H go together. Aim: May 2005.
---- THE FUTURE ----
I) "~all" needs to to become "-all" at some point.
J) crypto; aim: June 2005.
Aim to finish by 9 because restaurants seem to close at
10pm. If we feel a sense of progress on the points above,
let's all have some champagne or something.