Slashdot Mirror
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."
Comment removed based on user account deletion
*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.
Don't take my posts literally; it's just code to control my botnet.
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?
Work bio at MMWD
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.
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.
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?
Brent Jones
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.
http://outcampaign.org/
Comment removed based on user account deletion
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.)
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Comment removed based on user account deletion
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 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.
Google is one of the biggest culprits in the utter destruction of the highest traffic Usenet discussion newsgroups. The volume of spam that comes from those servers is ridiculous, not to mention all the former AOL idiots that were the scourge of the groups.
Don't worry. GoogleBackscatter is currently in Beta. When it goes into production backscatter will be even better!
The google fanboys are wrong on this one.
This is *exactly* why I do my email separate from all other browsing. It's not even unique to Google, they're just the biggest target.
If you want to use email securely:
* Use 'clear private data' to wipe everything out.
* Visit your webmail site (copy any links you want to visit to a text file for later).
* Read/send email.
* Log out.
* Use 'clear private data' again.
Anything less risks having information stolen.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Please show me the RFC that states you must accept email for addresses that you know are invalid.
There is *NO* such rule. If your backup MX blindly accepts mail for every address, then it is broken. Backup (actually *any*) MX should only accept mail that it knows (or has good reason to assume) it can deliver. If I'm wrong, or I've missed something, please by all means correct me. Please consider yourself corrected. Since when is it considered bad form to send a NDR? Mu. It's bad form to send an NDR when you shouldn't have accepted the mail in the first place - which is the problem here.
Why doesn't Google go with the Blue Frog/Security Method?
It was the ONLY thing that worked. In fact, it worked so well that the spammers had to declare open warfare against them.
Hah! Let's see them try THAT with Google. Oh, and seeing all of Google's Gmail customers becoming virtual BlueFrogs by default would be pretty cool, too!
[End Of Line]
The arms race against spammers has failed. There is only one method of behavior modification left: pain.
... remind them.
It's obvious to me that the only long-term cure is retribution. Swift, sure, immensely painful, intimately physical.
1. "y@y! mee sended 4 baziLLi0000n e''s!!!!!! mee grrlfrrnd crrrream bestest!"
2. Two days later, a heavy-set dude wielding an oven mitt, a meat tenderizing mallet, and a blowtorch relieves you of your upper testicle, the ligaments in your right knee, and two left fingers.
3. "wh0@! bad jewjew! mee not sended grrlfrrnd crrrream again!"
4. PROFIT!!!
Pain, or immediate, palpable fear of it, is the only behavior modification technique that works every time. When they get out of line and start spamming again
I tested this on Google Apps for my (company's) domain.
Turns out that yes, they will drop it on the floor if you give them an invalid address. It's probably not gmail.com, and definitely not yourdomain.com -- but rather, blogger.com and googlegroups.com -- which seem to be accepting mail and bouncing, rather than rejecting via SMTP.
A quick demonstration:
As you can see, it not only dropped my message on the floor, it also demanded brackets around the address -- something Postfix and Exim do for me, and I think even Qmail tolerated addresses without brackets.
I imagine it works pretty much the same way for gmail.com, so if you're going to take advantage of the bouncing to have Google DoS Google, keep that in mind. Send mail from bogus_01234@blogger.com to alsobogus_56789@googlegroups.com. (I think adding a GUID to it would be a nice touch, thus guaranteeing that it will never match an actual address.)
Don't thank God, thank a doctor!
This behaviour isn't WRONG wrong, but it's not very good practice any more.
There are some problems here.. First of all, what if the server in question doesn't know what users are 'good' or not? Say, if it's a backup MTA? The non-primary MX? Which are receiving mail due to the primary being down?
Quite common for them not to know about all the email accounts.
Now, problems with backscatter has been there for a while. It's certainly not nice, but there are only so many things one can do. If you read the original RFCs, Google's behaviour is entirely acceptable. Unfortunately the original RFCs for SMTP was written way before spam became a problem...
Other MTAs are "just as bad". Look at qmail for example. This is default behaviour in qmail. It'll accept any email without confirming whether the recipient exists or not (to prevent in-line data-mining of what accounts are there and what accounts aren't there). If the email is to a bogus recipient address, qmail will generate a bounce.
This bounce will go to the From: address.
And that's QMAIL - which is considered a secure mta.
Then you have the same problem, as I've mentioned, occuring when you've got a secondary MX which doesn't have a list of users. The choices for the MTA is to either create a bounce and inform the sender that the recipient doesn't exist - or you might silently discard the message. Neither are good options.
SMTP is kind of broken. Don't blame google for it. Different people consider different things best practices. I don't agree with googles practice in this particular case, while others would claim it's the only proper behaviour.
"Rune Kristian Viken" - http://www.nwo.no - arca
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
If a train station is a place where a train stops, what's a workstation?
Won't work unless you forge the *envelope-sender".
I get incorrectly addressed emails every day thanx to a non-standard gmail policy that most folks don't know exists. They deliver a single email to multiple addresses without any indication that more than one person has received it. ANY email address that contains a dot will have ALL their incoming mail delivered to whoever owns that same address without dots. I get emails for a two college students who have my eddress with dots. Mine has none. Every email they get, I get a copy of. I've logged into myspace and other sites with credentials that I received in links from their emails. I get job application responses and credit card sales confirmations.
Emails to abuse get an automated reply touting how wonderful this "feature" is. I finally setup a filter that forwards all these emails to abuse@gmail.com. They get at least a dozen every day, and haven't noticed in over a year. If you don't like someone who has a gmail account, you can legitimately register their address with a single dot added, and then fill their inbox with anything you want.
On the one hand you take life too seriously, and on the other, you do not take playful existence seriously enough. Seth
There is a simple solution to forged DSNs (bounces). Sign the MAIL FROM of your outgoing mail with something like SRS or BATV: SRS0=keTrY=UY==user@example.com All bounces (MAIL FROM is empty) must be directed to a signed localpart with a valid hash key. If not, the bounce is immediately rejected, with a snooty message if so desired.
Actually, MAPI (Mail API) is the old Microsoft standard for mail-related communication between Windows applications. I remember using it in Windows 3, long before IMAP was widely adopted. It was later extended to MAPI/RPC for communication with Exchange servers. This is one case where anti-Microsoft paranoia isn't justified...
(this is not a
Say my manufacturing plant is "in beta". Does that excuse it belching out toxic smoke and polluting the atmosphere? No. Gmail being in beta doesn't give them a licence to belch out spam, either.
I was under the impression until now that Google (as a business and its employees) are technically quite savy. Seems quite strange that they are clueless about spam.
From Wikipedia:
"Since these messages were not solicited by the recipients, are substantially similar to each other, and are delivered in bulk quantities, they themselves can qualify as unsolicited bulk email or spam. As such, systems that generate e-mail backscatter can end up being listed on various DNSBLs and be in violation of ISPs Terms-of-Service for being abusive."
So please help Google get a clue: look in your (spam) folder and if you find any of the emails mentioned, report it to spamcop.com. If everyone just submits one report, I am sure this will get resolved (Google will not let themselves be blacklisted for long for non-complience).
By the way, backscatter spam is a serious problem, and I am quite appeled when even ivy league school admins have no clue about it... There should be a shamelist for sysadmins as well who do not cooperate with efforts against spam (even if only out of ignorance/stupidity or even more so).
How is rejecting email to non-existent users in direct violation of standards?
Additionally, the RFC you linked to defines the DSN extension. There is no requirement for an MTA to support RFC 3461. In fact Google's own MXs do not support the DSN extension:
$nc smtp2.google.com. 25
220 smtp.google.com ESMTP
EHLO ME
250-smtp.google.com Hello obfuscated hostname [obfuscated IP address], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 20000000
250-STARTTLS
250-DELIVERBY
250 HELP
quit
221 2.0.0 smtp.google.com closing connection