North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Micorsoft's Sender ID Authentication......?

  • From: John Levine
  • Date: Wed Jun 08 00:39:06 2005

>Yes, there was lots of teeth gnashing and screams of agony allegedly because
>MS refused to license the technology on the terms that folks wanted. MS was
>more than willing to let folks have it at no cost, they just weren't willing
>to give the naysayer everything they wanted, so everyone went home.
>(that is, of course, a biased assessment, but not an unfair one)

There were two problems with the patent license that the MS lawyers
offered.  The first was that it reserved to them the right to stop
granting new licenses, thereby pulling the rug out from under anyone
who'd used licensed technology in a product, particularly an open
source product.  The said they didn't plan to do that, but MS' lawyers
adamantly refused to change that, so a lot of us concluded that if
they thought the pull out the rug language was important, so did we.

The second problem was that the license was for two unpublished patent
applications that they described in general terms.  When the
applications were published (on a schedule known from the day they
were filed), they turned out to cover vastly more than MS had ever
said.  That left a bad taste in a lot of people's mouths.  See my blog
entry at

>In the mean time, nothing stops MS (and everyone else) from building
>Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF
>records to perform inbound phishing control based on PRA.

(Danger: operational content ahead.)

Sender-ID and SPF have serious practical problems.  

The first is that they don't match the way that a lot of mail is
really sent.  If all of your mail comes from a single set of servers,
like if you're a big company or an ESP, then SPF or Sender-ID work
reasonably well to tell people which mail is yours.  On the other
hand, if you're a university who lets its graduates keep using their addresses after they graduate and forwards their mail to
them, they doen't work at all.  (Other than a legalistic version of
"work" in which you publish a useless SPF record saying that mail
could come from anywhere.)

This would not be a problem except that SPF has been greatly oversold,
the SPF community has not been particularly diligent in disabusing
people of their misconceptions, and I can promise that the moment
there is a Sender-ID checkbox in Exchange, clueless MCSEs will set it
to reject anything that fails Sender-ID, it'll reject buckets of
normal valid mail, and when people complain, they will insist that the
mail must have been sent wrong because Sender-ID said it was spam.

Even for fixed senders, Sender-ID is useless against phishing, because
it can only tell you that a message purporting to be from
came from a source that is OK for, but it cannot tell you
whether is someone you want to get mail from.  This is a
real problem.  For example, I got mail the other day from purporting to tell me about the status of my MBNA
credit card, with a link to  Was that a phish?  Or
consider and  One is MBNA, one is
not.  Does your MUA know which one is which?  Spammers and phishers
can publish SPF records just like anyone else, and Ciphertrust has
said that of the mail they see that passes SPF, there's more spam
than legit mail.

I am all in favor of sender authentication, if it's real sender
authentication.  But Sender-ID isn't.  Domainkeys will be better since
it matches mail sending patterns better, but it has the same problem
that a sender that's been authenticated has nothing to do with whether
its mail is desired.

Shameless plug: over in the anti-spam research group at I
sure would like it if people were working on reputation systems to
plug the gaping hole left by all these authentication schemes.

John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be,, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.