On Jan 24, 2006, at 22:31, Mark Shewmaker wrote:
##############################################################
###Begin conspiracy alert: (This isn't something I *think* I
### believe, but it's had me thinking)
###
One thing that's recently crossed my mind is that we've all been
assuming that Microsoft truely wants SenderID to succeed. I think we
should at least consider the opposite from time to time, (although in
general I don't like trying to explain things with conspiracy
theories.)
Gentle Folk,
Dealing with Microsoft is always delicate but it is no different
than dealing with representatives of any big company. (Disclosure: In
my day job, I work for IBM.)
Inside large companies, the spam problem is seen differently by
groups with different agendas. Operations see spam as a scourge. They
need tools to help battle it. Management, in Microsoft's case, has an
image problem of having "insecure" systems that cause much of the
spam (i.e. zombies). They have to appear to be doing something. Two
year deadlines to eliminate spam ensue. Research staff (e.g. the
SenderID folks) want to meet the challenge. If they meet it, they get
a promotion. And, more importantly, they get more freedom in pursuing
problems in the future. In Microsoft's case, they also have an
internal competitive issue of who has the biggest brain. A solution
has to be seen as both innovative while being aligned with "important
corporate initiatives". The CallerID spec was aligned with the
corporate initiatives (XML) but was late to the innovation game. SPF
had already filled that niche. So, SenderID was re-engineered and
this very ugly PRA concept was hatched which leveraged the client.
(Microsoft always rewards their engineers for technologies that
require client side processing.) In other words, no conspiracy is
needed to describe the history - just normal human organizational
behavior interacting with the wider internet mediated world.
So where does this leave us in the conflict between SPF and
SenderID? I contend it leaves us where we have always been - with
SPFs destiny in our hands. The other email vendors have mostly
dropped SenderID for almost the same reasons that we have dropped it.
It has unknown Microsoft IP encumbrances and, frankly, PRA offers
little to no value after you have received the spam over a digital
signature method like DomainKeys. In fact, because DomainKeys
leverages the same out of "SMTP band" identity pattern as SPF, it
means that email operators who accept either mechanism have good
reasons to accept both mechanisms. I think we need to market SPF as
the RFC 2821 time mechanism and DomainKeys as the RFC 2822 time
mechanism. SPF allows connection time rejection of forgeries.
DomainKeys allows cryptographically assured identification of the
sending server.
I think this leads to a natural marketing campaign for SPF. SPF is
the front line defense against forgery that helps DomainKeys (by
reducing server load) authenticate the email domain. In other words,
sell to our strengths - we hit forgery. Ignore SenderID. It is DoA.
In many ways, SPF has already won. Many email servers, commercial and
open source, already support or their plug-in models allow SPF into
the mail processing stream. There is little infrastructure that needs
further development. We just need to get the experimental RFC out the
door and get on with business.
Andrew
P.S. We still have the forwarding "bugbear". In my opinion, this is a
non-issue. Many people have come down strongly on the side of
protecting their domain/brand equity with SPF versus supporting an
optional feature of SMTP. I think we really have to turn this
argument around. Spam revealed design flaws in SMTP. SPF is the
minimally intrusive mechanism to help mitigate these flaws. With
respect to forwarding, you can either change your forwarding
infrastructure into a proper emailer (with appropriate header field
rewriting) or choose not to use SPF. Most of the commercial
forwarding services are adopting the former solution. (Frankly, the
vast majority of organizations don't forward email. This is really an
issue of the IETF digerati, many of whom use forwarding. IETF seems
to have no sense of proportion of relative value of features
determined after deployment. Every feature is "special" and above
average. ;-)
____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
"To take no detours from the high road of reason and social
responsibility."
-- Marcus Aurelius
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com