Microsoft Releases Patent on SenderID

wayne writes "Microsoft has now put the SenderID patents under the OSP. The Open Specification Promise was discussed on slashdot before in conjunction with web services and it is good to see that they are opening up even more. There are still technical problems with SenderID compared with SPF and, of course, SPF isn't problem free. Still, over the last year, the number of SPF records has more than doubled from around 1.7 million to 4.1 million, with rate of growth increased in the last 6 months."

Comments

Re:Sender ID, SPF, DomainKeys

[ldspartan]

DomainKeys doesn't break forwarding and... you know, SMTP. DomainKeys doesn't require mail servers to rewrite the headers on every message ever.

In short, DomainKeys wasn't designed by idiots, while the other two apparently were.

I'm unbiased! pffffft :P

--
phil

Re:Huh?

[Shados]

Office probably has crazy R&D and coding costs(even if you find the quality of Office to be lacking, it doesn't change that, outsourcing aside, the programmers coding it for MS don't work for peanuts...they probably make 2-3 times what I make, and I don't work for peanuts myself!), so recoding the whole damn thing (even if you port the Mac version, I'm sure it uses a lot of Mac-only API), plus support, etc, it most likely would come down to a loss, or a very tiny profit margin: not worth the customers they'd -lose- from people who would move from Windows to *nix when they see Microsoft's alternate products available there.

Re:Have they released a SenderID SDK?

[grcumb]

Although I may not be a fan of M$, I am a fan of anything anti-spam.

I'm not. Not a fan of anything at all, that is. I'm a fan of open systems (preferably officially endorsed standards) that are well understood and secured for use many years into the future. SMTP, for all its baggage, is one standard that has actually aged fairly well over the years.

There are fundamental flaws, of course, and now these flaws are costing us a lot of money, time and effort trying to stop people from preying on the system and on human naïveté.

Microsoft's approach to this can be summarised as, "Hey gang let's all get together and fight spam my way!" This is okay, but in the opinion of this hoary old curmudgeon, I'd rather people said, "Hey gang, let's all get together and figure out how to fight spam!" There's a small but integral difference between those two statements. It lies in the potential for Microsoft to stop in mid-fight, take its ball and go home.

What Microsoft is trying to do with this latest move is to convince the world that it will not do this. I'd like to believe that's true, but their track record gives us every reason to believe the opposite. Even if they're perfectly sincere about this right now, people will still be suspicious that at some time in the future they might try to lock things down again.

It's unfortunate that we have been led to feel this way, and I suppose it's never to late for a leopard to change his spots. I doubt this one will, though.

Re:Sender ID, SPF, DomainKeys

[DA-MAN]

DomainKeys doesn't break forwarding and... you know, SMTP.

DomainKeys breaks a lot of things. As one of the maintainers of the QmailToaster project, I've run across a lot of people where DomainKeys breaks their entire setup.

1) If you forward your mail to an upstream server (sendmail smarthost, Exchange SMTP Connector, etc), DomainKeys will always be void.
2) If you have a backup mail server or a scanning mail server that receives and then transfers to your primary mail server un-modified (IE doesn't remove the DomainKeys) then your main mail server will reject it.

DomainKeys sucks. SPF sucks, SRS is a hack.

Breaking SMTP not a solution

[fruey]

All of these solutions have flaws. I'm with deBoynePollard on this:

• SPF is harmful
• Anti UBM don't work

An interesting take is to make the sender responsible for storing mail: suggested by Dan Bernstein (DJB), the qmail guy.

There's always politics in it. Some people don't like DJB's attitude and they're anti-qmail and go for Postfix or sendmail.

Wietse Venema, the postfix guy, isn't too happy about SPF either: but he does provide plugins for Postfix.

SPAM needs a solution, but breaking SMTP isn't the way to go IMHO. I think a well configured email server, RBLs, requiring reasonable RFC compliance and such will eliminate much SPAM. Spending energy on evangelising good mail server configuration is still the best way to go.

Re:Breaking SMTP not a solution

[Just Some Guy]

An interesting take is to make the sender responsible for storing mail: suggested by Dan Bernstein (DJB), the qmail guy.

As per typical DJB ideas, it's broken and only implements half the functionality of what it intends to replace. I've used this example before, so skip this if it sounds familiar:

A friend of mine hosts a customer that sends weekly newsletters to about 25,000 subscribers. With SMTP, my friend can spool the whole set and then watch as the mail queue flushes over time (measured in a small number of hours). It takes advantage of the fact that if 10,000 of those newsletters are going to @example.com addresses, it can deliver all 10,000 of them at once. In any case, his system delivers mail at the pace it can handle.

Enter DJB's scheme. Now, my friend delivers 25,000 "you've got mail!" notifications. Then, he watches in horror as 9AM EDT rolls around and 5,000 of his customer's customers simultaneously try to fetch unique copies of the newsletter to read with their morning coffee. Repeat at 9AM CDT, MDT, and PDT. His choice is to get out of the newsletter delivery business, or spend $$$$ on vastly increasing his bandwidth.

Basically, it's fundamentally broken. SMTP is more or less optimized for throughput. DJB's plan is more or less pessimized for latency.

Re:Breaking SMTP not a solution

[wfberg]

Enter DJB's scheme. Now, my friend delivers 25,000 "you've got mail!" notifications. Then, he watches in horror as 9AM EDT rolls around and 5,000 of his customer's customers simultaneously try to fetch unique copies of the newsletter to read with their morning coffee. Repeat at 9AM CDT, MDT, and PDT. His choice is to get out of the newsletter delivery business, or spend $$$$ on vastly increasing his bandwidth.

Of course, you say this as if his newsletter doesn't contain any hyperlinks to http://yourfriendswebsite.com/ - most newsletters contain such references, and deal with the onslaught on the main website just fine.

That's not to say your example is wrong, but even so, the number of times people would be hit with problems from the reverse model would be limited. In fact, many subscribers will also neglect to fetch the actual newsletter's contents, saving your friend bandwidth as well.

The reverse model is already being used (even more inefficiently since many clients disregard ETAGs etc.) in RSS, and hasn't led to the end of the world.

In the end DJBs model doesn't solve much, because you'll still have to wade through an inbox filled with spammy mail headers, which is the biggest waste of time. In fact, spamfilters will be less effective because they won't have access to the message contents, and if they do, when they retrieve the contents, maybe they're getting a different version from when you retrieve the contents (or should the spamfilter fetch the message, and if not found to be spam, store it in your local mailbox? but then you're fetching the contents without human interaction again!)

Wraught with problems, it is. But the slashdot effect would be the least of its problems.

Re:Why not just fix Windows?

[RidiculousPie]

Given that all currently supported versions of Windows, from a technical perspective, have security capabilities that exceed those of most unixes, how do you propose they do more than they already have ?

It doesn't matter if these security measures are there if noone uses them. Windows still ships with new user accounts being administrator by default. The default group policy is very permissive, and acls do nothing versus the administrator user. If windows had decent sudo capabilities (yes I have used runas and credentials storing in shortcuts), which make it painful for the average user to run as anything other than Administrator.

Poor security by default is the real issue. Corporate entities can afford to create group policy and run users as non admins and have things like standard images if systems do get infected. A home user does not have the resources. Security needs to be on by default.

Re:Have they released a SenderID SDK?

[sgtrock]

I recommend that you spend a little time studying the history of the Internet before making these kinds of statements. Spend even more time studying how electronic mail was originally designed, and how it has evolved. I think you'll find that far from being 'cruft', a client/server model was exactly the model that the original designers wanted for a variety of very good reasons.

The Internet didn't start with the Web, after all.

Dear Dumbass

[Anonymous Coward]

I'm not. Not a fan of anything at all, that is. I'm a fan of open systems

So, you are. You are a fan of something afterall. You're a fan of hypocrisy.