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

["william(at)elan.net" <william () elan net>]

On Tue, 7 Jun 2005, Fergie (Paul Ferguson) wrote:

> Wasn't there a lot of turmoil within the IETF last year
> on sender authentication because Microsoft was trying to
> push it's own sender ID authetication mechasnisms as a
> draft standard?

That time it did not work. But they are still trying to push it as 
experimental RFC and in the mean time continue to advocate it trying
to make it open standard despite technical and other objections.

> Or maybe I'm confused...

SenderID is bad technology. Technically:
  1. Its proposal contains recommendation that are directly opposite
     to existing RFC2822 standard (which specifically mentions in section
     section 3.6 that "using resent fields is a different operation from
     forwarding")
  2. It tries to change the meaning of message sender from real message
     source to intermediate agents, this would have problems with other
     email authentication technologies
  3. Its using spf1 records, but they are used for information on sources
     for different identity (SMTP2821 MAIL FROM) and would not always have
     the same data as what would apply for RFC2822 Sender or its
     derivatives. There is no consent being asked from those entered
     SPF1 records if they meant them used for SID and this basically
     means people who wanted to participate in SPF inadvertently are
     put in danger (it can also be viewed as attempt to steal somebody
     else's record).

For more on technical issues see my recent message to IESG regarding SID 
when they were evaluating it:
 http://www.gossamer-threads.com/lists/spf/discuss/19859

Politically it has problems too:
  1. Its patent license is not open-source compatible and so can not
     be used in any GNU or BSD licensed program
  2. The "senderid" word itself is trademarked and its use also
     basically being stolen by Microsoft

---

Since it appears NANOG continues to be used for mail-related discussions
and a some of what goes here is based on not understanding technologies
and issues involved, I'll make a link to a paper that I'm working on 
available (when its ready) and it will hopefully be good information to 
understand what's up in email authentication front and what each 
technology can and can not do.

--
William Leibzon
Elan Networks
william () elan net