Google Mail Servers Enable Backscatter Spam

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."

Comments

And google wonders why ...

[micheas]

They are getting tagged with the moniker "the new evil".

I wonder how much of this has to do with the Microsoft to Google employee migration bringing the corporate culture with the people?

Re:And google wonders why ...

[dnoyeb]

Scapegoating the shareholders as an excuse for executive abuse is getting old.

Proper?

[EdIII]

The proper behavior would be for the mail servers to reject email traffic to non-existent users during the initial SMTP transaction.

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.

Re:Proper?

[EdIII]

Actually that's how they're doing it.

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.

In beta

[SkullOne]

Didn't anyone notice that Gmail is still in beta?

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

[Schraegstrichpunkt]

Sending to example12345@googlegroups.com, I get this (my email address replaced with name@example.com):

Hello name@example.com,

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.

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.