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