Slashdot Mirror
MS and Sendmail work together on Spam Solution
fudgefactor7 writes "Powerhouse software vendor Microsoft and the venerable Sendmail, have formed an alliance to launch a sender authentication plug-in which is hoped will combat email fraud and spam. The plug-in lets organisations verify a message's source before accepting it by automatically checking to see if an email came from where it claims it did. Could this be a sign of the beginning of the end of spam?" Update: 02/26 08:01 GMT by S : Though Microsoft and Sendmail are both working on solutions, there's no official alliance in place between the companies.
Microsoft is one of several companies who are also working to combat spam with a "caller ID" system. Yahoo's DomainKeys is another one.
MS is a footnote. Aside from headline, the article mentions nothing about an 'alliance' or even Sendmail and MS working together.
You have a good point, but THIS combined with other solutions could make a difference. Yes most of the PCs sending Spam won't be stopped by this, except that they don't have proper MX/PTR records. So if we use this with some DNS filtering to only accept mail from "real" mail servers, this could take out a large chunk of spam.
"Luke, I am your node.parent();"
It says nothing about Sendmail and MSFT working together. Only that they're working on their own solutions to the same problem.
While it's nice to see this type of work being done, the headline is misleading.
wbs.
Huh?
Eh? The point is that the receiving server will verify with the sending server that the email is really coming from where it says it is. SPAM usually lies about where it is coming from and the servers using this plug in will reject such mail.
If the SPAM isn't lieing about where it's coming from then it's easy to block all SPAM from a web server, notify the offending servers admin if possible, get the spammers accounts revoked, etc.
I don't know, am I missing something? The problem isn't that this won't help, the hurdle is getting the modification to the protocal accepted and used widely.
There's something at least very similar to that already available as a milter. milter-sender does an email callback to the mx of the domain the email claims to be from and verifies that the address exists. Unlike some of the other solutions available, it doesn't expect the sender to send another mail to verify he's a genuine sender, but accepts the email if the mx doesn't fail to the "RCPT TO" command (exceptions requiring a "full callback" can be configured for mxs that only find out they don't know the recipient after the DATA command has been sent).
Apparently, 60% of the world does.
If you look on the sendmail site, it says that they are also working with yahoo on domain keys. It looks like sendmail is going to create their own compatible version of everyone's anti-spam solution
source, http://www.sendmail.com/sender_auth.shtml
-CPM
---You're all I need, When the water runs deep, You're all I need, Now I cry my soul to sleep -- Collective Soul, Needs
3) France wins a war (without American help and without being led by a non-frenchman)
Even if you don't count the French Revolution, doesn't the Norman Conquest count? French invade Britain, French win, Britain ruled by Frenchmen for several hundred years. I'm pretty sure William of Normandy was French, and I'm pretty sure the Americans didn't intervene in that one.
In fact, if you search the /. archives, you'll find a somewhat recent article.
For the average /. reader who can't be bothered to RTFA, the short of it is that works like a reverse MX record. Only hosts listed in your SPF (Sender Policy Framework) rules (published in DNS) are considered allowed senders of email from your domain. Recieving MTAs can then make an informed decision on whether to accept mail that has an envelope sender from you domain, based on whether the sending host is listed as permitted. This means that for any domain that is publishing SPF rules, spoofing the sender address while using an open relay/M$ zombie box becomes impossible, as long as the receiving MTA checks SPF.
It won't put an end to spam, but when enough domains have implemented both publishing SPF rules as well as checking them for inbound mail, it will cause severe headaches to the spammers, and cut down their arena significantly. Best of all, if there ever are any false positives that are rejected, it's due to the originating site policies, not the receiver's or middleman (as the case easily is with distributed blacklists)!
There are currently 3 solutions competing on the internet. Only one actually works right now as we speak.
(1) Caller ID is Microsoft's big proposal. Domain owners put XML in the TXT records in their domain. Receiving email systems can determine if a message is valid only after seeing all of the headers.
(2) SPF (http://spf.pobox.com/) is already implemented and is already blocking joe-jobs and phishing schemes. It relies only on the envelope FROM and the owners of the domain publishing a short TXT record. Currently, aol.com and many more domains (around 6,000?) publish SPF records. Implementations for filtering based on SPF exist in perl, python, C, and for Exim, postfix, qmail and sendmail.
There is a small problem in forwarding email properly, but that is being resolved with SRS (same website).
(3) DomainKeys (Yahoo!'s solution) is still being researched and is looking more and more like S/MIME or PGP but for an entire domain. The domain owners would publish the public key via DNS (probably a TXT record as well) and receving mail servers can verify that the message is indeed from said domain. There are some severe limitations: If someone gets your domain private key, you are screwed. It's also subject to a replay attack. The attacker would send a valid email to themselves through a server using domain keys, and then replay that message to the rest of the internet.
Both SPF and Caller ID can't work around DNS poisoning or IP spoofing. But they both limit the number of machines that are allowed to send email for a domain.
It is important that if you own a domain, that you publish SPF records - even if it is only "v=spf1 !all" or "I don't send any email for this domain". SPF, if it is going to be adopted, is going to be adopted at an exponential rate.
Caller ID is mostly Microsoft's response to the rapid success of SPF. They want to own the solution to spam, and they want to take credit for cleaning up your email box, even though their idea is really other people's ideas + XML. The protocol is heavy, burdensome, and subject to the whims of the XML interpreters out there right now. Plus, it is a huge proposal that is detailed and complicated, ripe for incompatibilities that could force users of Sendmail, Exim, Postfix, or Qmail to "upgrade" to Exchange.
The radical sect of Islam would either see you dead or "reverted" to Islam.