Google Mail Servers Enable Backscatter Spam 344
Mike Morris writes "Google email servers are responsible for a large volume of backscatter spam. No recipient validation is being performed for the domains googlegroups.com and blogger.com — possibly for other Google domains as well, but these two have been confirmed. (You can test this by sending an email to a bogus address in either of the domains; you'll quickly get a Google-generated bounce message.) Consequently spammers are able to launch dictionary attacks against these domains using forged envelope sender addresses. The owners of these forged addresses are then inundated with the bounce messages generated by the Google mail servers. The proper behavior would be for the mail servers to reject email traffic to non-existent users during the initial SMTP transaction. Attempts at contacting them via abuse@google.com and postmaster@google.com have gone unanswered for quite some time. Only automated responses are received which say Google isn't doing anything wrong."
And google wonders why ... (Score:5, Insightful)
I wonder how much of this has to do with the Microsoft to Google employee migration bringing the corporate culture with the people?
Proper? (Score:5, Insightful)
Ummm, how about the only behavior
It never ceases to amaze me how some mail server administrators setup policies on their networks. If you are running a mail server you are THE POSTMASTER. If you don't know where it should go, or who it is supposed to be going to, how can you accept it?
Refusing email and stopping the transaction when you do not control the domain, service the domain, or even know the mailbox user is about as obvious a policy as not relaying for domains outside of your control.
If it is an honest mistake on the part of the sending server, acting as an agent for the user, then a simple message informing the sender that the account does not exist is a trivial matter.
To do anything else just amazes me.
In beta (Score:4, Insightful)
FWIW, I use Google Apps to host my e-mail, and I have found Google to have horrible support.
Instead of fixing the problem, they'll just point you to a loosely moderated Google Groups newsgroup for Google apps, and you'll rarely receive a response, let alone a workable fix for an issue.
Do no evil? Or do nothing at all?
Inaccurate title/summary (Score:4, Insightful)
We're writing to let you know that the group that you tried to contact (example12345) doesn't exist. There are a few possible reasons why this happened:
* You might have spelled or formatted the group name incorrectly.
* The owner of the group removed this group, so there's nobody there to contact.
If you have questions about this or any other group, please visit the Google Groups Help Center at http://groups.google.com/support [google.com].
Thanks, and we hope you'll continue to enjoy Google Groups.
The Google Groups Team
In other words, while this causes backscatter, this is not an avenue for "backscatter spam", since Google isn't delivering the contents of arbitrary messages to arbitrary users.
It sounds like the submitter wants to blow this out of proportion by equating general backscatter (which nearly all mailing list managers on the Internet generate with their "confirmation" messages) with backscatter spam.
Re:And google wonders why ... (Score:3, Insightful)
Re:250 Accepted (Score:2, Insightful)
Re:A suggestion for Gmail spam-fighting (Score:3, Insightful)
That form was a funny joke the first few times it was used. Since thing it has simply become a generic excuse for "No, we cannot."
Actually, I don't think there is any way to truly address the spam problem without dealing with the TANSTAAFL problem. The creators of email pretended that it would be mutually beneficial, so they did not need to design any accounting into it. While I actually admire Al Gore, I feel like I have to blame him as the root of the spam problem. He kept telling them 'Don't worry about the money--I'll get it for you.'
Re:A suggestion for Gmail spam-fighting (Score:3, Insightful)
Just this week they apparently discovered a botnet larger than Storm. (http://www.theregister.co.uk/2008/04/07/kraken_botnet_menace/) The report says that the botnet was spewing out vast quantities of spam for the usual quasi-legal scams. So how the heck could they miss it? Possible answer: Because the filtering approach was mostly working.
Remember that the spammers are dividing by zero. At least that's how they think about it. If another million spams finds one more sucker to send them $39, then they think the RoI was $39/0 = infinity. They aren't concerned with your spam filters. If you're smart enough to filter their spam, then you probably aren't dumb enough to send them the money--but they're still hoping to catch you with their next scam.
Re:Proper? (Score:3, Insightful)
Re:And google wonders why ... (Score:5, Insightful)
Re:And google wonders why ... (Score:4, Insightful)
Re:Proper? (Score:3, Insightful)
Those who fail are likely to find themselves on numerous blacklists -- correctly listed as spammers.
Re:Proper? (Score:5, Insightful)
I am not sure what "it" refers to. We are talking about two different things here, which is what occurs inside a SMTP transaction and what occurs outside of it.
Inside these SMTP transactions nothing is occurring that is facilitating the delivery of SPAM directly. Just the harvesting of good addresses for those domains. Afterwards, they can use the good addresses to send SPAM directly to those mail boxes.
What is stupid here, and I use that word deliberately, is Google's apparent policies. Regardless of any other considerations, you should not be sending bounce messages to FROM headers. Any action taken should occur within the SMTP transaction with 5xx or 2xx codes. Doing so is, for lack of a better word, just plain STUPID. When those FROM headers contain users within your own domains makes it just that much more retarded. Why would you be sending a bounce message to your own user from activity that did not originate within your own systems? Last time I checked you would not be doing so.
Any messages that came from your own users would be through authenticated SMTP transactions and any recipient errors would have bounce messages routed locally back to the sender. You don't even need the FROM header if it is in an authenticated session from your own user. You already knew which user it was from the authentication process. If you have SMTP transactions, that are not authenticated in most cases, coming from systems outside of your direct control, then it can't be from your users and therefore you should not be sending messages to them.
As for the SMTP transactions themselves being used for harvesting there are other methods to deal with that. You don't need to bug the crap out of your own users doing it either.
If I have a SMTP transaction attempt delivery to an unknown address outside of my domains (relaying), I explicitly add them to the block lists for 60 minutes. Sending mail servers should be using the domain in the TO header to obtain MX records of my mail server. For my mail server to get a message for domains that I don't control is a huge red flag. If it is to an unknown address within my domains I block them for 20 minutes, but only after 3 such transactions within 10 minutes. That will allow any honest typos from stopping service from valid mail servers.
When you get a ton of these SMTP transactions in a row maybe, just maybe now, you should be adding that IP address to a dynamic suppression system for longer periods of time, like say weeks. Here is the kicker too, if these SMTP transactions came from a Zombie machine then you are not even interfering with that person's ability to send mail since they will be doing through a web based email system such as Google or an email client that will send their email (through an authenticated session) to a real mail server that will then send it out.
There is a LOT more to this, but I can tell you that Google is doing it in about the stupidest way possible right now. That's just my opinion, but I do operate several mail servers right now and I can't see anything smart about these policies.
Re:*goes change his gmail password* (Score:1, Insightful)
Not evil, Not spam (Score:1, Insightful)
1. Giving an immediate "yey" or "nay" to every "Is this a valid email address?" is a terrible idea. This would allow anyone to trivially dictionary attach google for valid email addresses. Having a valid from address and checking responses is MUCH more difficult for spammers.
2. Google doesn't include the message on the bounce! THERE IS NO SPAM INVOLVED WHATSOEVER.
So the hypothetical abuse this whiner is complaining about is that a spammer could "hypothetically" indirectly flood a mail account with Google bounce messages. Ok, great. So why not send 1000 messages straight into your mail account, instead of sending 1000 messages indirectly through Google into your mail account? In the latter scenario you can actually deliver spam in those 1000 messages, in the former they're getting a Google form letter.
This makes no sense at all. There is no "abuse" and no "evil", and not even any "spam" here. Whoever wrote this story, and whoever OKed it at Slashdot (*cough*kdawson*cough*) are clueless about how e-mail works.
Re:And google wonders why ... (Score:3, Insightful)
Re:Inaccurate title/summary (Score:3, Insightful)
Nobody is claiming spammers are getting paid for the backscatter. Backscatter is just collateral damage to the original spam. Spammers don't care because it doesn't cost them anything, but they aren't doing it on purpose. That's why it is the responsibility of the mail administrator to ensure that THEY don't involve third parties in their spam by generating completely new messages and sending them to everyone whose domain was used in a forged address (note these are not bounces, this is Google "helpfully" making a new message and sending it out).
I thought we were done with this idiocy years ago when antivirus programs finally stopped spamming innocent third parties with incorrect notifications that they sent someone a virus.
Re:*goes change his gmail password* (Score:2, Insightful)
Follow usual security guidelines-
1> Read before you enter
2> Use different passwords for different sites
3> Never give password of site A to site B.
FYI, the sites also have a microscopic "skip" link present on the *send invitation* page.
Re:Proper? (Score:4, Insightful)
Actually both are crap.
Unfortunately there are no good ways to handle it, that I know of. They all allow for harvesting or backscatter. The only way to avoid both would be to accept everything and never respond. But then every blackholed email is potentially a genuine error for which there is no indication.
Re:*goes change his gmail password* (Score:4, Insightful)
What? Some site asked for your email password, and you gave it to them? Shouldn't people reading Slashdot know better than this?
Collateral spam (Score:3, Insightful)
Is what I know this as. I used to get so much spam it drove me crazy. I set up filter rule after rule, used RBLs and everything but it only helped partially. I could still live with it. But eventually, I was hit by huge waves of collateral spam and eventually got more of that then the real thing*, and that was when I decided email was either going to be entirely useless to me or I had to do something very drastic.
I opted for something drastic. I still have a large number of filter rules, but in addition to that, I use a whitelist instead of a blacklist to filter email, and everything not on my whitelist that survives the spam filter rules ends up in a bulk mail folder I check about once a week. Now if someone I don't know emails me, that stinks, and I constantly have to adjust my whitelist to allow for more addresses, but at least I barely see any spam - real or collateral - anymore. Without that I'd have given up on spam altogether.
*) In the order of several 1000 a day
MFROM signing (Score:3, Insightful)
Re:*goes change his gmail password* (Score:3, Insightful)
Re:And google wonders why ... (Score:3, Insightful)
I forget who said "Never attribute to malice that which can be adequately explained by stupidity." but I think that applies here.