Hi, On Tue, 9 Mar 2004, Nick Fisher wrote:
> > On Mon, Mar 08, 2004 at 06:34:23PM -0800, Bart Schaefer wrote: > I have to say that I'm still much more into the Microsoft idea of putting > all this in the headers and keeping with the RFCs. Has anyone else read > their plan? I've seen to talk about it. Can anyone here poke the same huge > hole in the MS plan as with the SPF plan? I can't. If anyone would like to > read their plan and tell me why it's not better than SPF I would love to > hear the argument. You can find the details here: > http://www.microsoft.com/mscorp/twc/privacy/spam_callerID.mspx Ask that question on SPAM-L and see what kind of answer you get. But to respond, briefly: 1) It's patent-encumbered and therefore a non-starter. The license agreement reads, in part: "Microsoft and its Affiliates hereby grant you ("Licensee") a fully paid, royalty-free, non-exclusive worldwide license under Microsoft's Necessary Claims to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations, provided, Licensee, on behalf of itself and its Affiliates, hereby grants Microsoft and all other Specification Licensees, a reciprocal, fully paid, royalty-free, non-exclusive worldwide nontransferrable, non-sublicenseable, license under Necessary Claims of Licensee to to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations." Explain what rights you cede to MS by accepting that license and what assurances we have that they won't revise the spec and start charging royalties once it gets wide adoption ("embrace and extend".) 2) XML is too much overhead for DNS. Compare the simplest useful SPF record: "v=spf1 mx -all" (14 characters) to the MS equivalent: "<ep xmlns='http://ms.net/1'><out><m><mx/></m></out></ep>" (56 characters) The overhead just gets worse with the more complicated policies. 2.a) Explain the "HashedPuzzle" element in their schema. (See "embrace and extend" above...) 3) It requires a lot of message header rewriting, breaking a lot of MUAs and MTAs. Unworkable at present due to its reliance on parsable, spec-compliant Received headers. Meaning as-is, the proposal breaks forwarding, mobile mail, and mailing lists just like SPF. 4) In the MS proposal, judgment cannot be made on the message envelope alone, making this a non-starter. Judgment must be performed prior to the SMTP data phase, first to save bandwidth of the receiving system, and second, so the mail can be rejected prior to taking responsibility for message delivery. Once an MTA has accepted the mail it either must deliver it or bounce it back to the sender with an explanation of why it can't be delivered. That's fine for Exchange and qmail which (IIRC) only accept-then-bounce; it does nothing for Sendmail, Postfix, and Exim users. I only see more overhead and IP encumbrance in the MS proposal with little (if any) additional advantage to show for it. Overall, I don't see how this is less broken than SPF. Regardless, the SATalk list is probably not the right forum to discuss this. -- Bob
