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.
Yahoo & sendmail cooperating
Most if not all Spam sent this way claims to be comming from some place other then the computer that sent it. If you get a message claiming to e from Microsoft and its source is some DSL IP range in the UK, this filter will chuck it. If you are only getting spam from known sources then you dont realy have a spam problem.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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).
Yeah, I see some actual hope that something like this would be effective. Perhaps if the servers simply exchanged certs, for example. Requiring a cert to run a mail server is NOT a heavy burden, and you could always accept unsigned messages if you wanted to. It raises some tech issues, and current SSL certs wouldn't work exactly. But a system of verifying the sending server and tying it to an identifiable individual or company would help a lot. Even the barrier of having it cost $50 or so to get a server cert would be enough to stop a lot of spammers.
Even better, such a solution is implemented at the server level, it's transparent to users, and it's backwards compatible (you could still configure your server to accept unsigned mail, or just filter it more aggressively), making gradual implementation a possibility. So there's a good chance it could catch on if major ISP's were to adopt it.
I confess to not having thought through all the details, but something along these lines is probably going to be the answer. Makes a lot more sense than any of the "pay per message" proposals, that's just Libertarians Gone Wild.
http://www.sendmail.com/sender_auth.shtml
Apparently, 60% of the world does.
And therein lies the problem. No vendor, no matter how well placed, should just run off and try to implement a solution. Why? Because odds are good it will not take off. Everyone involved needs to agree on a solution THEN implement it.
As with any change to infrastructure, the conversion is likely best done in a phased approach.
Step 1: Impliment authentication, but don't block messages from unauthenticated servers.
Step 2: Adjust existing SPAM filters to weigh mail from unauthenticated servers as having x % (where x is initially some relatively low number) greater liklihood of being SPAM than messages from authenticated servers.
Step 3: Increase x gradually over time. At the end of some period (say, one year), x appraoches 90%, effectively blocking most mail not on whitelists from unauthenticated servers. Leave x at this high value for some time (say another year)
Step 4: stop accepting mail from anauthenticated servers completely.
End of SPAM? Probably not (as SPAM mailers can authenticate themselves, and Microsoft WORMS and Viruses can hijack legitimate mail servers which authenticate themselves and send SPAM anyway) but it is a start.
The Future of Human Evolution: Autonomy
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.
Although the parent post was moderated as "funny," I think the question is a serious one. I use sendmail exlusively because it is the only mail server that supports the powerful milter API and allows me to use mimedefang, which cannot work with any other mail server. Mimedefang can drive antivirus software and spam filter, not to mention sanitizing of html email and so forth, is a very powerful piece of software.
For many people postfix or exim work very well, and should be used over sendmail. But in a larger environment, sendmail is the standard. Qmail, well, I've never liked it.
>>I must be missing something.
.05%. In the traditional direct mail world (old style mail), 2% was a huge return.
You are. 5% is way too high, it's more the
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)!
This has been rehashed a million times...
Basically forging email addresses is going to have to stop, just like using open relays had to stop years ago. SMTP AUTH has been around for years & every mailserver supports it.
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.