> > 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. I only mentioned it as we do seem to be talking alot about this sorta stuff.
> 1) It's patent-encumbered and therefore a non-starter. The license > agreement reads, in part: Agreed. I think this is the No1 reason that it's going to get nowhere. We can always pick the corpse for ideas though. > 2) XML is too much overhead for DNS. I thought the XML was kinda heavy too. It does allow for alot of flexability though. > 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. Now this is where it's a bit more intresting. I frankly thought that doing all this in headers rather than in the envelop sender would make this easyer. Alot of MUAs and MTAs are already setup to add/remove headers, there would just need to be an expansion of that.... rather than changing the way SMTP works as you need to with SRS. I'm also not sure why you make a point of saying that you need 'spec-compliant Received headers'. As far as I can see they are just normall Received headers.... arn't they in the RFCs and implemented already? > 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. You say this like it's a bad thing.... frankly it seems to me that it makes more sence to take the burden of determining where the mail is actually from away from the MTA. It seems to me that the MTA should be there to transport mail not process it. Yes it would require that more bandwidth is used. However (IIRC) most MTAs do not reject mail untill the DATA phase of the mail is over, thus even if the MTA does reject the only bandwidth saved is that of the bounce message. > 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. Err..... I know that postfix can bounce mail after it's recived.... I would be amazed if the other MTAs you mention cannot. > 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. I would agree that both are broken in some respects. However it still seems to me that trying to auth the message is much easyer to do in headers than through the envelope sender. In my mind it breaks less and is easyer to deal with. Having said that I think it would need to be reinvented without the legal crud tying it down to be worth anything. > Regardless, the SATalk list is probably not the right forum to discuss > this. Fair enough... but as there seems to be a SPF thread rolling I thought I could throw it in without being too OT. Nick
