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.
"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?"
:-)
Wow......this really sounds like it was written by a marketing director. A Slashdotter could have just as easily interpreted this as "The 800 lb gorilla of the software industry, Microsoft has coerced the long suffering Sendmail to provide Microsoft with a software patch that fixes security holes inherent in Microsoft products that allow for email fraud and spam to run rampant. Another side benefit is that Microsoft can exert their market dominance to further entrench the Microsoft monopoly by refusing email not conforming to Microsoft "standards".
Laugh, it's intended to be funny.
Visit Jonesblog and say hello.
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.
Isn't this one of the signs of the apocolypse?
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
First your cf syntax, now working with Microsoft?! What did we ever do to you?! Truly, a sysadmin's worst enemy.
Game... blouses.
This isn't going to fix it.
A crap load of junk mail comes from insecure personal computers that were hijacked. If these computers send their junk mail, and this system tracks them, it will send the "A-OK" because the mail came from where it said it did.
This will help, no doubt. But fix the problem? No.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
but it will need widespread acceptance to really work
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.
Could this be a sign of the beginning of the end of spam?
Dunno... but it could be the beginning of the end of sendmail. Not that it would be a bad thing...
There's much better software out there.
I doubt this will end spam.. however it will put an end to the collaterol damage caused to other people's inboxes when some other jerk spoofs their domain names. (yes I'm mad.. I have 1000 bounces from the other week when someone sent online pharmacy ads while pretending to be ME)
It will also put an end to using a free email account to recieve spam replies.
So it's not a cure but it will make the game more expensive for the spammers.
Could this be a sign of the beginning of the end of spam?"
Yes, just like computers have made the era of office paper end (I enjoy my paperless office, do you?), and how Bill Clinton in 1995 ended the era of big government.
Don't blame Durga. I voted for Centauri.
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?
&& aemula C. ab stirpe interiit
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.
Spammers used to buy a T1's worth of phone lines and then dial in to several different ISP's all at once and use THEIR mail server to send spam. With the advent of easily hacked broadband connections, this isn't required anymore. I can see it popping back up pretty quickly. While the idea is OK, spammers are adaptable. The ONLY way to make spammers stop, is to make them feel pain and this solution doesn't provide nearly enough pain.
For instance, I ws joe jobbed, I recieved about 2300 bounced messages advertising various web sites. For every bounced message I forwarded a 900k graphic that said "Do not use my return address in your spam campaign, it is illegal". Since I recieved another bounced spam before I had finished responding to these kind people, I decided perhaps another avenue of communication was approriate. I posted an order on each of the three websites I found advertised 2300 times (PERL w/LWP). Since I was unable to get a response via e-mail, I figured that I would get a response via an order form. I posted 2300 times(one for each boucne) with my contact information and a request to not use my e-mail in the shipping information box.
What happened?
1. one of the mail servers stopped responding all together. It didn't come back up for more than a week (qmail queue default lifetime anyone?)
2. During the post to these web sites (ALL on hacked machines running open proxy servers) the web site went down and stopped responding. I guess the concurrency of 2300 was a bad idea.
It appears that my e-mail address is no longer being used, although their websites finally recovered about 8 hours later. These web sites no longer accept orders from my IP address. No imagine if only 1/2 the people that recieved a spam did what I did? Think of the number of bogus orders that have to be sorted to simply get to a legitimate one? Think of the amount of traffic going INTO comcast and RR to these hacked machines (waving flag over here, over here LOOK LOOK security@rr.com!). Of course this would take time, and we alreayd have precious little of this. If enough people took the time, we would also have precious little spam. The cost would be too high.
AngryPeopleRule
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
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).
As a public service I am providing my sendmail.cf file as a configuration example.
HReceived: $?sfrom $s $.$?_($?s$|from $.$_)
HDate:@@_$_$?sfrom^*$%#%!*(()^&^&*#$##
$%@$#%&&_%#__&^#$%_#$%%___*(__Y_JY_*_*(_#$%#_
#@$@@#sonofa@#$%@@#@#$#
I know it just looks like line noise but this is a working config!
Your post advocates a
(x) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
(x) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(x) Requires too much cooperation from spammers
(x) Requires immediate total cooperation from everybody at once
(x) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
(x) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(x) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(x) Dishonesty on the part of spammers themselves
(x) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(x) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
Apparently, 60% of the world does.
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.
Doesn't this just sound like a great way to create a DoS style attack?
I: Flood many servers with email supposedly from server X
II: All servers attempt to contact server X
III: Server X crashes/is overwhelmed with requests, stops responding
IV: Some of the orginal servers might get hung trying to clear email from Server X, now no longer responding...
I admit that IV seems avoidable, but I-III don't seem like a big strech based off of prior MS security exploits...
DJMD - The fourth man - Planetary
Now my little server can do advanced reverse lookups on the over 90,000 spam messages it handles per month.
I'm thinking not...
How about making all spam a crime and holding the companies who finance it liable. Then giving consumers the power to sue for damages.
I'm not an ISP, under CAN-SPAM I can't do ANYTHING about the over NINETY THOUSAND spam messages sent to my server per month.
Needless to say, my poor little PII-400 linux box gags and chokes during spuratic 'floods' of spam through each day.
I must say, though, any efforts to thwart spam are good in my opinion. However, the problem will _never_ be solved until the companies PAYING for spam are held financially and/or criminally liable for their actions.
After all, if you PAY someone to commit murder for you -- does that make you any less guilty?
No.
Sorry, but your solution is NOT the solution.
(after all, buyviagra@biggerpenis.org is most likely sending you spam).
That statement would have made sense in 2002 perhaps, but today a _very_ large portion of email is sent through hijacked machines.
It's just as easy for the hijacking spammer to sign the outgoing email on the hijacked machine.
Consider it similar to a telemarketer that goes from house to house to find unlocked doors. When the door is open, he goes in and makes the phone call from the phone in the residence. The caller ID is not going to identify the phone call as a telemarketer call.
In the real world this would be absurd, but unfortunately there's tons of machines out there with SMTP backdoors.
I know I'm blowing my karma points on this one, but I believe it's justified and realistic.
No business partnership or alliance of any signficance has existed with Microsoft that resulted in a mutually beneficial conclusion. To put it another way, it's like trying to make a deal with the devil.
I don't expect that sendmail will be summarily destroyed as such. But I ernestly and honestly believe that the final outcome of this venture will only result in Micorosoft obtaining an absolute choke hold on email.
To expect anything less is niave and ignorant. There is no past performance which disputes this claim. Even considering legal judgements, Microsoft will not hesitate to make "all your email belong to us".
I apologize if I come off sounding like one of the slashdot anto-microsoft zealots, or some conspiracy theorist. But think it through.
Microsoft develops a means by which all email must be reverse authenticated as to the sender. Believe me, they will patent it and everything that looks like it before the night is over. This sounds great, but then all they do is just modify the email servers to require that this proprietary reverse authentication take place or you can't send any email.
The fact that they are working with sendmail, the company and not the OS project, allows them to license this technology to a Unix platform. This allows them a foothold onto the majority of email servers, which are Unix based, and to establish the means by which they have complete ownership of all email transactions. And it will be a matter of time before sendmail.com has to turn over their assets to pay the licensing fees, but then maybe Microsoft doesn't want them able to pay the fees.
Yeah, Spam sucks. But get a clue! Spam filters account for 99+% of all the spam out there. I would rather have my 1 spam a week out of 600 then to have Microsoft telling me I have to pay royalties to send email. There is nothing cool or encouraging about this.
And the real problem here isn't the spam, or the cost of sending spam, they haven't done anything to reduce either one of these. The problem is the adolescent pimple-butts who really think that herbal viagra will give them a 36" schlong that lasts all month long. Do you really want that? It's hard to pee standing on your head!
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)!
ever seen in email from your sendmail MTA where in the header it say "FORGED". usually on spam email. You know you can block on that in sendmail without any add-ons... The problem is that the majority of the internet servers must then go out and update their DNS records for MX and reverse, for this to actually work.
PS: I actually turned this on one time to get rid of spam, blocking a whole bunch of legit email in the process. Ooops. hello internet just enforce the tools that you already posses.. nuff said.
--jboss
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.
The issue you face is one of "identity distinction". By being on Comcast Cable, you appear to be one of the unwashed masses. Whether your system is secure or not isn't known, and isn't practical to find out (trying to actually crack your machine to see if one can get in, to refuse mail if the crack succeeds, has certain legal risks).
You can distinguish yourself by making your email address known and others can whitelist it. Of course that's only good up to the point that spammers start to joe-job you using that address (which may not be for quite a while). Another way (which won't work with Comcast because they are so clueless, but could work with some other ISPs) is to get static IP and arrange for reverse DNS to identify your domain name. Some (I do, for example) block Comcast based on the domain name (easier to manage than a bunch of IP address ranges), which means if your IP didn't have comcast.net on it, it might get through. And if you do have a static IP, you could just ask for that one to be whitelisted.
There are also message content ways to distinguish yourself, such as cryptographically signing your message. But the problem here is that mail servers have to accept all mail first to see that signature. That breaks the ability to refuse during the SMTP RCPT command; refusing at the DATA command not only means wasting the bandwidth always on every message, but also the inability to let users separately whitelist, or means sending bounces to unverified addresses (bad). If they would redesign SMTP to provide the crypto signature during the SMTP session, that would help a lot.
Probably the best solution is to subscribe to a mail submission service (e.g. someone who has a colocated mail server and takes your mail only via authenticated SMTP or MSA). Then the fact that you're on Comcast is hidden deeper in messy RFC headers.
now we need to go OSS in diesel cars