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 [e-mail] and [e-mail] have gone unanswered for quite some time. Only automated responses are received which say Google isn't doing anything wrong."

Translation

My mom's was getting a ton of spam and she kept calling me day and night, saying her computer was broken. I tried to resolve the problem by contacting Google but they ignored me. The only option left was to badmouth them on the front page of Slashdot so the bad PR would force them to fix her problem. MOM, YOU CAN STOP CALLING ME NOW OK!!!

*goes change his gmail password*

*goes change his gmail password*

Seriously though, there's something else that bothers me about gmail (not the only one to do it): that apparently anyone can get your contact list if they have your address.

Ever happened to you? I was signing up on a music website with a gmail address, and then they asked me if I wanted to send invites to all my contacts, which magicaly appeared on their page. Even if it is apparently a common practice, I find it very disturbing.

Re:*goes change his gmail password*

Did you have an active session with gmail going at the time? As in, you didn't click "log out"?

Re:Mod Parent Up

If you want to use email securely:

Use POP3 for all your email. That way no website can ever get access to your contacts or personal data.

Re:Mod Parent Up

Warning: offtopic

IMAP and MAPI are two separate protocols. IMAP is a standard protocol used for semi-connected work on folders actually hosted on a server (it can work disconnected and sync up later), whereas MAPI is a Microsoft proprietary protocol that accomplishes approximately the same thing.

I tend to think that the name MAPI is a typical Microsoft attempt to get people to confuse (it worked, didn't it?) open, widely used standards and Microsoft proprietary crap. See also OOXML vs ODF (formerly OOXML, before Microsoft even dreamed of that acronym...)

Re:*goes change his gmail password*

No, this has never happened to me.

Ever.

What kind of "music" site were you on?

The "russian" kind?

Re:*goes change his gmail password*

Yeah, Facebook actually asks for your gmail password, so do other sites. A bit shady, but I trust those sites not to store it because there'd be hell to pay if anyone found out otherwise.

Re:*goes change his gmail password*

I had the same thing happen.

LinkedIn asks me if I want to "connect" to certain people that I know for sure my only contact with them has been through mail on my gmail account. LinkedIn *can* mine your gmail account for you if you provide your account info to them, but I certainly never used that feature, so it was a bit alarming to see all of my gmail contacts showing up.

Personally, I don't care if they are not the only ones to do it. They shouldn't be giving out our personal info. I did expect them to use my info to provide context-sensitive ads, but I did not expect them to share my info with other companies without my explicit permission.

Not to mention, if you and I both saw it on sites that ostensibly have no relationship with google, it's possible that anyone that can hook to their Soap API can get your contact list.

Re:*goes change his gmail password*

Strange things happen in the internet, The other day I was navigating in the internet and my wife was watching the screen, and when I was typing a url, a nasty porn site appeared as autocompleted, I swear I never visited the site. I'll show this google account problem to my wife, she might believe me now.

Re:*goes change his gmail password*

Ever happened to you? I was signing up on a music website with a gmail address, and then they asked me if I wanted to send invites to all my contacts, which magicaly appeared on their page. Even if it is apparently a common practice, I find it very disturbing.

It may have appeared on their page, but it wasn't coming from their site -- it was coming from google. Both the list of your contacts, and the request for permission to send, was coming from google. It does NOT [google.com] mean the actual music site knew the email addresses of your contacts.

Here is an actual example of what I'm talking about. Log into http://www.google.com/calendar [google.com], stick this iframe in your web site, replace the left and right parenthesis with the right symbols, and see what happens.

(iframe src="http://www.google.com/calendar/embed?title=Slashdot%20Calendar&height=250&wkst=2&bgcolor=%23FFFFFF&ctz=America%2FLos_Angeles" style=" border:solid 1px #777 " width="300" height="250" frameborder="0" scrolling="no")(/iframe)

Assuming your calendar is marked private, having the private data from your calendar appearing within the iframe of your browser doesn't mean it's accessible by the web site hosting the iframe (nor does it mean it's accessible by the javascript outside that iframe either).

And google wonders why ...

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

Won't somebody please think of the driveways!

Re:And google wonders why ...

Wow, only on slashdot does microsoft get the blame for google being evil.

Re:And google wonders why ...

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

just point it out to them more clearally.

forged from: abuse@[domain]
to: bogus@[domain]
You have issues.

If they have back scatter, they get it. If they don't have back scatter, they don't.

Re:just point it out to them more clearally.

forged from: abuse@[domain] to: bogus@[domain] You have issues. If they have back scatter, they get it. If they don't have back scatter, they don't.

Hah.

[e-mail] has an auto-response. [e-mail] has an auto-response.

I'm sending the e-mail right now. I wish I could see the "abuse" account's inbox in a few hours....

Proper?

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?

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.

A suggestion for Gmail spam-fighting

Basically Gmail is losing value for all of us as it becomes spam
soaked. Even their filtering is having troubles with false positives
and false negatives--and the spam is just increasing. Therefore I
think Google should act more aggressively to drive the spammers away
from Gmail.

My latest anti-spam idea is a SuperReport option. (Kind of like
SpamCop, but not so lazy.) If you click on the SuperReport option,
Gmail would explode the spam and try to analyze it for you to help go
after the spammers more aggressively. Here is one approach to
implementing it:

The first pass analysis would be a low-cost quickie that would also
act like a kind of CAPTCHA. This would just be an automated pass
looking for obvious patterns like email addresses and URLs. The email
would then be exploded and shown to the person making the report (=
the targeted recipient of the spam AKA victim). The thoughtful
responses for the second pass would guide the system in going after
the spammers--making Gmail a *VERY* hostile environment for spammers
to the point that they would stop spamming Gmail.

For example, if the first pass analysis finds an email address in the
header, the exploded options might be "Obvious fake, ignore",
"Plausible fake used to improve delivery", "Apparently valid drop
address for replies", "Possible Joe job", and "Other". (Of course
there should be pop-up explanations for help, which would be easy if
it's done as a radio button. Also, Google always needs to allow for
"Other" because the spammers are so damn innovative. In the "Other"
case, the second pass should call for an explanation of why it is
"Other".)

If the first pass analysis finds a URL, the exploded options should be
things like "Drugs", "Stock scam", "Software piracy", "Loan scam",
"419 scam", "Prostitution", "Fake merchandise", "Reputation theft",
"Possible Joe job", and "Other". I think URLs should include a second
radio button for "Registered Domain" (default), "Redirection",
"Possible redirection", "Dynamic DNS routing", and "Other". (Or
perhaps that would be another second-pass option?)

If the first pass finds an email address in the body, the exploded
options should include things like "Fake opt-out for address
harvester", "419 reply path", "Joe job", and "Other".

At the bottom of the expanded first pass analysis there should be some
general options about the kind of spam and suggested countermeasures,
and the submit SuperReport button. This would trigger the heavier
second pass where Gmail's system would take these detailed results of
the human analysis of the spam and use them to really go after the
spammers in a more serious way. Some of the second pass stuff should
come back to the person who received the spam for confirmation of the
suggested countermeasures.

Going beyond that? I think Gmail should also rate the spam reporters
on their spam-fighting skills, and figure out how smart they are when
they are analyzing the spam. I want to earn a "Spam Fighter First
Class" merit badge!

If you agree with these ideas--or have better ones, I suggest you try
to call them to Google's attention. Google still seems to be an
innovative and responsive company--and they claim they want to fight
evil, too. More so if many people write to them? (I even think they
recently implemented one of my suggestions to improve the Groups...
However, it doesn't matter who gets credit--what matters is destroying
the spammers.)

250 Accepted

Yes, mail to an unknown recipient should be rejected with a 550 code during the initial SMTP dialogue. But not only that - lots of people believe that *any* message you don't intend to deliver should be rejected during the SMTP dialogue. The current fashion is to say "250 OK" and then silently delete the message later, which is wrong.

I hate to toot my own horn here, but I wrote tarmail [ablative.org] with this express purpose in mind (among others). GPLed and everything. Messages that you won't accept get rejected during the SMTP dialogue.

If you don't like my MTA, then please feel free to mod this down so that others won't be needlessly bothered. But I really to believe that Tarmail is the right answer to this specific problem. Thank you for your time.

Re:250 Accepted

The current fashion is to say "250 OK" and then silently delete the message later, which is wrong.

Since SMTP is defective by design, this is an acceptable response. Doing anything else allows spammers to confirm valid accounts using dictionary attacks.

Re:250 Accepted

Yes actually I have. Postfix is extremely easy to set up with SpamAssassin. It requires cutting and pasting two configuration lines if you can't understand the manual and can do a google search. I suppose you could make the pedantic argument that it's twice as hard as tarmail since tarmail requires one line.

In fact setting up ClamAV and SpamAssassin alone is orders of magnitude more complex.

I might argue that if you have a hard time understanding the postfix manual you have no business running a mail server.

In any case, I wasn't trying to compare, just trying to understand why it was worth the effort of yet another SMTP server.

It is not that easy....

There are three possibilities for email to non-existent addresses: Silent drop, initial bounce and delayed notification. All have problems.

If the sender address is legitimate, but a relay is in the transmission chain, you have only bad choices: Silent drop may cause problems for legitimate emails. Initial bounce causes the observed problem, once removed and with real-time characteristics. The observed delayed notification behavior at least has the advantage that you can control the rate these messages are outgoing. A good strategy would be to intitially send one of these and then accumulate these per sender messages over, say 24h and send only one further notification per day. Incidentially, this strategy is something known to most people that ever implemented automatic notification emails on system failures...

I think there is just no good way to deal with this issuse, as long as open, badly configures relays are around. It is also quite possible that the gmail designers never anticipated this and not are not readily able to respont in an adequate fashion (see the 24h accumulation, e.g.). That would possibly indicate a lack of competent security people involved in the design process. As these people are scarce everywhere, Google will also likely not have enough of them.

On my own mailservers (small), I use silend drop for relay requests (which is definitely a good idea) and "drop into spambox" for unknown destinations. I look over these occasionally, and I have found legitimate email in there.

I do agree that initial bounce sounds like the right strategy, but unfortunately it does have serious problems.

Re:Inaccurate title/summary

*checks*

Hey, look. It's a kdawson article!

Re:Inaccurate title/summary

You're being either overly literal, or trying to create a distinction where there isn't much of one.

No, the responses don't contain an original message, nor are they commercial or anything like that, but the spammy thing about this form of backscatter is about the VOLUME and indiscriminate nature of the mail, not the content.

This isn't being blown out of proportion at all. It's nothing like a mailing list sending a confirmation. No spammer is going to send a million messages with different forged addresses to a single email address (the subscribe address) -- that defeats the whole purpose of spamming, which is to contact DIFFERENT addresses!

What google has done is open a wildcard on some domains so that anyone launching a dictionary attack on googlegroups.com will send a million messages TO a million different addresses FROM a million different forged addresses. Google then sends a million bounces back to a million different addresses, and if you run a domain that the spammer used as their "from", you suddenly get tens or hundreds of thousands of identical bounce messages from Google. THAT is backscatter spam -- thousands of useless messages sent to forged addresses on your domain, regardless of content. And no mail server in 2008, much less one run by a major tech company, should make that possible.