North American Network Operators Group

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

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

  • From: Daniel Golding
  • Date: Wed Jun 08 10:20:12 2005

Reputation is a missing element in all sender authentications schemes and
will (likely) be solved separately.

No approach is perfect, but building closer to a solution is preferred over
sitting on our hands and debating, which (historically) seems to be the
IETF's approach.

- Dan

On 6/8/05 12:37 AM, "John Levine" <[email protected]> wrote:

>> 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 http://www.taugh.com/weblog/patapp.html
> 
>> 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
> whatever.edu 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 phoop.com
> came from a source that is OK for phoop.com, but it cannot tell you
> whether phoop.com is someone you want to get mail from.  This is a
> real problem.  For example, I got mail the other day from
> customercenter.net purporting to tell me about the status of my MBNA
> credit card, with a link to mbnanetaccess.com.  Was that a phish?  Or
> consider mbna-account.com and mbna-accounts.com.  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 asrg.sp.am I
> sure would like it if people were working on reputation systems to
> plug the gaping hole left by all these authentication schemes.
> 
> Regards,
> John Levine, [email protected], Primary Perpetrator of "The Internet for
> Dummies",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group