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.
If anything gmail accepting email to all addresses prevents spammers from running dictionary attacks against gmail. I'm sure they have some sort of limit to prevent people from sending too many emails from each ip to bogus addresses.
Also with no references listed in the post, its probably someone over reacting about a single mis-addressed bounce they received.
Comment removed based on user account deletion
Translation: Everything that Google does wrong is actually right. When I think about Google I imagine that it's a big red penis that I can suck.
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.
There is a good chance that in the future we will look back at this as the point at which the groupthink regarding Google as evil or not, flipped polarity.
There has been an increase in the level of geek angst about Google (check out the Google App Engine post). I predict its only going to get worse and that by the end of the year most Google stories will be tagged "theNewMicrosoft" or as someone else suggested "theNewEvil". Of course, the fact that a bunch of geeks are no longer enamoured of Google will not halt their continuing traction among non-geeks (much like other companies you could think of).
It will be interesting to contrast how they respond to this over the next year and compare this to, say, Microsoft's PR machine.
Having said all this, I still find gmail and calendar extremely useful, and I wouldn't even think of using a different search engine. For now.
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.
Re: "do no evil."
"All that is required for evil to prevail is for good men to do nothing." -- Edmund Burke
Is this some kind of inevitable, organizational entropy that accumulates as companies become larger and more ambitious - or is that just what growing, influential orgs tell themselves once they realize they like being growing, influential orgs?
Either way, it's disappointing.
That which does not kill us makes us... st
I guess the slogan needs to change from "Do no evil" to "Do nothing about the evil".
Don't worry. GoogleBackscatter is currently in Beta. When it goes into production backscatter will be even better!
Or at least, it's correctly refusing to accept mail for accounts that don't exist at my domain. (We're using Gmail for corporate email.)
So it's googlegroups.com and blogger.com, but not Gmail? Interesting.
Don't thank God, thank a doctor!
The google fanboys are wrong on this one.
I don't think most spammers are trying to validate addresses. They find some open relay, and then unleash millions of addresses on it. If you don't believe me, create a generic mailbox somewhere. bill@somedomain.com, and see how long it takes to get spam. Especially if there is another mailbox on that domain that is already receiving spam.
Now, I do believe hackers would want to get valid addresses, to get valid login information, or get bank login information, etc.
Spammers are about bulk. They play the odds. Millions sent, hundreds of thousands delivered, thousands read, and hundreds not deleted, and tens invoked.
-- You can't idiot-proof anything, because they're always coming out with better idiots.
The Google domains are being blacklisted by various e-mail and Usenet admins.
To all of the legitimate Gmail users, sorry about that. We won't be receiving your messages. Perhaps its time to move on and find a better service.
Note to my stockbroker: Sell my Google.
Have gnu, will travel.
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.
So, Mr. Tarmail, would you care to answer the following question: Can I easily use tarmail in front of my existing postfix/amavis/clamav/f-prot rig? I don't mind processing mail twice (or more, really) -- I've got plenty of CPU to spare. If your MTA is really as slick as you say, I would to make a somewhat easy transition away from my current, complicated arrangement and onto yours.
(I'd research this myself, but I'm on my own time right now and would rather be looking into a strange issue with my car's parking brake than do pro-bono work for the company.)
Kid-proof tablet..
This sort of behaviour is nothing new. qmail accepts all mail immediately and then if it bounces, generates its own bounce message and sends it back to the envelope sender. Relays, by necessity, do the same thing too. OK, so it would be nice if Google could reject the messages right away, but accusing them of being evil because of this is a huge stretch.
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.
I don't get this article, I really don't. When mail arrives for a domain, and the main mail server for the domain is unreachable, it is supposed to be sent to the lower-priority MX hosts for that domain. They are required to accept it, and forward it to the primary MX for the domain once it becomes available. That's how MX records are supposed to work.
Let me repeat that: they are required to unconditionally accept mail for the domain. So, unless I am missing something here, every single secondary mail host on the Internet should exhibit the behaviour mentioned in the article.
If I'm wrong, or I've missed something, please by all means correct me. But this really seems like a tinfoil-hat tempest in a teapot. Since when is it considered bad form to send a NDR?
We run the WPBL blocklist, which is a small but relatively well established blocklist service.
Our policy is to treat backscatter as spam, and we do block some hosts due to this backscatter. Google's mail servers are whitelisted at our service, as are other major ISPs, so realistically Google would not get blocked.
However there are many minor mail servers on the internet that constantly spam us with backscatter, and these hosts do get blocked. Some of our members receive thousands of backscatter spam daily. In the last few days in fact there has been a flood like we've never seen before, mailbombing all coming from mail server backscatter.
If you run a mail server, I encourage you to study and understand backscatter. Unless you have put measures in place to avoid being part of the problem, I can virtually guarantee you that you are sending out backscatter. Go right now and run a quick mailq and see if there are a lot of mailer errors in your queue to fake addresses... if there are, you are sending backscatter. It is very common, and very annoying. It is preventable with the right configuration. I have argued this with plenty of admins, but I guarantee you that you can avoid sending backscatter with a proper configuration.
Backup and secondary MX hosts do not have to be vulnerable by design. Solutions: 1) distribute valid recipient lists to MX's and reject mail at the correct transaction, or 2) check and respect SPF for the sender, or 3) run an anti-spam filter, check heuristics, and only send back mailer errors on high confidence ham.This "story" is idiotic. What google is doing is not only not wrong, but about as "right" as it's possible to be.
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.
Just put a cap on the number of bounce messages that can be sent to each from: address per hour/day/whatever. If additional bounces come up they can be summarized in a digest bounce email at the end of the day.
YES. THE HEADING IS QUITE MISLEADING.
The summary says it would allow a dictionary attack against the groups...
FTA... "Consequently spammers are able to launch dictionary attacks against these domains using forged envelope sender addresses.."
And you are spot on. The "backscatter" does not appear to include the orininal message.
And since the sender of the reply is "noreply@googlegroups.com", I can't actually see how you would use it to dictionary attack (except on googlegroups).
You could, however still use it for a DOS attack vector (by spoofing the sender address), but mainly, this will only enable a dictionary attack of the googlegroups (but what can you do about that anyway?)
This would appear (to me - just quickly) to comply with RFC 2821, so I actually fail to see the point of the story... hmmm
Move along... there is no sig here.
This "Google is evil" meme needs to end. Crushing competition, violating anti-trust laws, turning political dissidents over to China and turning over search records to the DoJ without warrant or hesitation. That's evil, and those are just some of the combined misdeeds of the two companies that are about to merge and become the largest search, news and mail portal on the Web. Hint: neither one is Google.
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]
Scammers, err, Spammers are famous for being happy with a 0.01% hit rate. So.. here is how we protect ourselves, slow every body down, just a little. Make any SMTP transaction take 1/2 second each. no big deal. that limits the thruput of any spammer... very much! Or.... financially.... if some one is found to be spamming (100 Failed emails from one IP) we'd bring the $$ hammer down on the sender. Charging $.01 per message might also do it too. Either of these might not scale in all cases, but, it might make cost/profit of spamming less tasty. Its free??? I'll take 20! (sounds too much like my company!) See Attached.
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
The best part of this is the loop created when abuse@[domain] sends the canned response to abuse@[domain], followed by the typical "we've got your e-mail, we'll get right on it when we feel like it" response to abuse@[domain], and another and another, until all of google's storage space becomes full of them.
<Possible Humor> Then the e-mail monster gains a mob mentality and becomes self aware and uses the president's gmail account to order a nuclear strike on Russia in an attempt to trigger a nuclear holocaust, but no-one believes it's a real e-mail because the government's linguistic experts compare the key phrase 'Launch all nuclear weapons at assigned targets in Russia' in the message and compare it to the president's typical grammar and conclude he would have written 'Lunch allo them there newcler wepons and blow them ruskies away.'</Possible Humor>
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
You can't be right because this is still creating an abusive situation. Keep in mind that the major issue with spam has nothing to do with the contents. So the fact that the backscatter does not include the spammer message just means the spammer can't make use of it to pass the message. But it still causes the same problems as spam, which is bogged down mail servers.
I have had one of my hosted email addresses used by a spammer in a large spam run of several million or so. My server once got hit by about 250,000 pieces of backscatter in just 3 days. About 6000 mail servers were the abuse vectors in this. They all got blocked. They will stay blocked until they can prove they fixed the issue. Google was NOT one of them (most were in Russia and the spam run was in Russian). But Google could have been one of them if they were doing then what they are reportedly doing today.
Sending back a bounce message after the fact is abuse ... if the bouncing server did not verify that the return email address it is using designates the sending server as appropriate for it. Google may well be applying that test (I see references to SPF in the headers on Gmail). So they could well be limiting backscatter to situations where the forged email address is one that matches the sending address (for example a botnet infected machine on Comcast forges a different Comcast user when sending mail through Comcast's outbound servers over to Gmail).
But any mail server not applying the appropriate test could be an abusive (and therefore evil) server. The correct logic is to never send a bounce message unless you have an unambiguous positive verification of the address via SPF, MX, etc. The RFC requires sending the delivery notification to the sender. The sender is the spammer. But you don't have the spammer's address; you just have some forged address. So you cannot send it correctly. So just don't send it. FYI: do not assume that a lack of negatives on that email address means it is a positive. It does not mean that at all. I just means you don't know if it is forged or not. If the domain administrator did not set up SPF to designate the outbound server AND that server is different than the inbound server identified by the MX record, then it's their loss to not get a delivery failure notification for otherwise legitimate mail (they can fix it).
BTW, it is not well known, but mail servers testing for email address validity could do an "MX test". An "MX test" never gives a negative because the domain involved may be using a separate outgoing server. But, if the mail is in fact coming from a server identified in the MX records, that can be treated as a positive for the purpose of bouncing. This is a usable test if SPF records are lacking for the email address domain.
now we need to go OSS in diesel cars
NDRs are evil if sent to the wrong address. You need to send them to THE SENDER ... not some victim the spammer has fingered. In the case of spam, the spammer is THE SENDER (regardless of what he puts on as the return address). So that means NDRs are not evil in cases of legitimate mail where the sender address is not a forgery. SMTP is flawed in the sense that if fails to provide a means to correctly identify the sender. Better do your SPF and other tests to be sure. Or just do the "safe harber" and do rejects during the SMTP session.
now we need to go OSS in diesel cars
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!
That is, you're right, this won't get them paid.
It also costs them very little to try.
And they aren't trying on purpose.
More importantly, what possible legitimate reason could there be for doing this, other than sheer incompetency?
Don't thank God, thank a doctor!
Or maybe they're running qmail ;-).
Google already has a very simple button to mark a message as spam, or as not spam.
Google also has the Google Cluster to throw at the problem of figuring out which messages (reported as spam) are actually spam, and which ones aren't, and what patterns they can glean from this to block future spam.
I'm really not sure what your solution gains in terms of additional UI. I think most of your ideas either could be implemented, or already are, with the simple "report spam" or "not spam" buttons.
Don't thank God, thank a doctor!
No, this is not how it works (when implemented correctly). What should and mostly does happen is the recipient server sends back an error code in the 500s, eg 550 no such user. The sending server may then generate a non-delivery email to the sender. This is OK behavior. In the case being discussed, this would *not* lead to backscatter because the sending server is the spammer's server not the legitimate mailserver for the domain. What is happening is that instead of google's mailserver sending a 500-response it is accepting the email (probably with a 200 response) and *then later* sending the 'bounce' email which has been quoted above.
In theory, there's no difference between theory and practice; in practice there is.
Rather than pointing at anything else as evil, Anyone who truly believes that Google is evil, when they so obviously are'nt, either has some weird axe to grind, or is insane.
Im not joking. Google have done so much for the industry, rather than holding any corner of its business to ransom. To call them the "new evil" is completely absurd.
Move along... there is no sig here.
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?
Well, you grab the nearest person that looks like (s)he might be spamming, apply the technique. If the spam stops, success. Otherwise you try to bury the story and find a new suspect
/sarcasm
You know, a bit like modern copyright enforcement, anti terrorism or the RIAA. Easy.
This may also throw a different light on the Brazilian that was shot dead by police in the London Underground transport system without any visible provocation. Must have been a spammer, which may explain why they got away with it.
Insert
Parent is correct. Scale is the issue. GMail is probably receiving billions of emails per day, most of them spam to invalid accounts. They are in effect being DDOS'd and it is very difficult for them to check every destination address in real time. The solution that scales easiest is for them to queue incoming emails for processing by lots of generic MTAs. So probably this is what they are doing. But unfortunately it means the SMTP connection is long gone when an address error is detected, so they have to respond to an error by returning a bounce.
One solution is roughly as follows. Google would program routers to crudely split the incoming SMTP traffic by first character(s) of the email address - all SMTP traffic for email addresses starting "aa-aj" are handed off to one server, all starting "af-at" to the next, and so on. This means each server is handling a manageable volume and can do a real-time lookup within just its slice of GMail addresses and return an immediate error. I think Hotmail does something a bit like this. But it is definitely non-trivial for Google's volumes. And yes, I do work in this field.
Reduce, reuse, cycle
Thank you, that really explains it. I'm releived that this is the case, actually.
Sorry for the alarming post, then.
Another win for the slashdot method ^^.
Don't take my posts literally; it's just code to control my botnet.
An italian hacker got it deeper
http://translate.google.com/translate?u=http%3A%2F%2Fpunto-informatico.it%2Fp.aspx%3Fi%3D2247078&langpair=it%7Cen&hl=it&ie=UTF8
(translation from italian)
On the other Porcacchia warning: "We think, for example, a user interested in a product that loses an object to a boom: an attacker could send an e-mail using the address of the seller, stating that the item has not been awarded and the rioffrendolo victim to a discounted price. who receives the email will control the header? Probably not. " The risk is that you find in a case invischiato phishing well orchestrated, despite the spam filter: "My hope - concludes Porcacchia - is that Google will soon resolve this issue."
I thought a back scatter was somebody who took a dump on your back.
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
Did anyone attempt to actually verify the veracity of this story? Or was it simply fixed just minutes or hours ago? I just did a manual SMTP session to all of gmail.com's listed and reachable Mail eXchange (MX) servers, and RCPT TO to a bogus address gets immediately rejected every time. No backscatter is generated by any of the MX servers. Here is the proof. (I tried to include it in the comment, but couldn't get past the lameness filter.)
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.
While it may be the case that the internet would be a happier place if everyone agreed to avoid generating "backscatter," people seem to consistently ignore the fact that "backscatter" is not a misconfiguration but rather a strict adherence to the standard. RFC 3461 (which is responsible for outlining delivery status notification for SMTP) is pretty clear that any failure to deliver a message in which the sending MTA has not specifically set the NOTIFY parameter to not contain "FAILURE" must result in a bounce. (RFC3461 sec. 5.2.6) http://www.faqs.org/rfcs/rfc3461.html Can we really jump down google's throat for adhering to an accepted standard instead of a loosely defined "best practice" which exists in direct violation of standards?
I opted-out of the API and blacklisted every application I could find.
Attempting to add even one will opt you back in, ostensibly because you have to manually add the application. (I don't see this as a WTF.)
However it's quite annoying because if I don't want to see any information in my mini-feed about application spam I have to blacklist every application my friends add. (Blacklists, as we know here on /., suck.)
"We see you have opted out. These are all the wonderful things you are missing! Please opt back in! Please, please please?!"
Another company slides into maturity inertia.
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).
Argh. My bad for not reading the freaking summary. Sorry about that.
...I trust those sites not to store it because there'd be hell to pay... Who cares about hell? By the time you find out some malicious actor could be trawling your email putting together enough information to hurt you financially. I only trust one person with my email password. Me.What they're doing is not wrong according to RFCs. It is wrong according to current best practices invented in the face of truck loads of SPAM. So, technically, they're correct in saying they're not doing anything wrong. That doesn't mean I agree with that statement though. I have a process that dumps our corporate LDAP database to a "relay-recipients" file every night so that Postfix knows what it's allowed to receive and what it should reject with a 550. The previous administrators did not have this configured and we ended up on Spam Cop's list several times before we finally got buy-in to make the requisit changes. We also do some basic checks for message correctness, which drops a whole lot of stuff right up front with a 550. As an example, no FQDN with the HELO/ELHO command ... 550 it is.
Vint Cerf was a well known apologist for spammers when he was at MCI. There's a good reason the mail community protested when Cerf was given the Turing Award. He's disgraced himself, it's just too bad more people don't know about it.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I know this probably isn't highly favorable, and very geeky, but why
can't everyone just sign their email with PGP/GPG, and then mail-servers
check with public key servers to verify that the mail is legitimate?
I suppose spammers could submit their own public keys, but these could
quickly be flagged as spammy, listing the signed email as proof. Keys
being signed by others who trust it would also help to elevate regular
users and keep spammers out (short of a system compromise where
someone's private key is copied).
I'm sure there are holes in this, beyond just the technical hurdles
(user training, key exchanges, CPU load on email servers, etc.). What
am I missing?
-----BEGIN PGP SIGNATURE-----
iD8DBQFH/Qr0d34OvcZ8P2oRAiFDAJ9ug8DwebZXFjd40cNUhrrk9qr2WACgtwsX
4TEm527Wu7S/hTGynY8bpdY=
=oKFZ
-----END PGP SIGNATURE-----
Im not joking. Google have done so much for the industry, rather than holding any corner of its business to ransom. To call them the "new evil" is completely absurd
And this was exactly how MS was viewed in the early 90s... Windows was the anti-establishment Environment, MS didn't do copy protection on disks, etc. They were the company that was doing good for consumers...
How long before Google catches up with itself?
Google is a marketing company hidden behind software, tools, and the guise of being open. They started out being more evil than MS, it is sad that most people think Google is a search company and doing good for anything non-Google.
From combing GMail and cross identifying searches to IPs and even getting Firefox to help report back user habits for more marketing, Google is pulling a fast one on the kiddies, and other fools, that don't know any better.
Evil? Well the word isn't quite so easy to pin down. But if you want to go on honesty or personal invasion, then they are Evil. If Google said, hey we are a big marketing company that will use everything we know about you to sell to everyone and focus marketing at you, and hand over the info to governments if asked, then at least they would be more honest.
All the Google projects have a unified goal, and people that work there know this, but still don't understand how it is underhanded. They don't built products for consumers to help consumers, they build products to lure consumers to learn more about them. This makes MS look like angels in the tech industry.
Just use the simple solution: Send a number of faked emails FROM one of their domains' faked addresses TO one of their domains' faked addresses. The email servers will commonly bounce back & forth until they die a horrible death. If not that, it'll at least be noticed.
Any email that *fails* a DKIM check is forged, and is therefore automatically spam.
..." followup*
So use DKIM to authenticate senders, and you can immediately SMTP reject any forgeries. The only messages that are left are:
1. Legitimate email, which should get through
2. Spammers who use real email addresses
once your only problems are number 2, accountability becomes much easier.
*waits for the "your approach to fighting spam advocates a
I see this coming up every time there's a gmail discussion...
IT'S NOT TRUE!
If you register "foobar", any dotted variation of it is yours, from "foo.bar" to "f.o.o.b.a.r". Likewise, if you register "foo.bar", "foobar" is automatically yours. There are no "other people owning the same address without dots". All of "them" are you.
I just got this message in my gmail. It contained base64 encoded bulk mail, but the header may make for interesting reading:
Delivered-To: "my address"@gmail.com
Received: by 10.114.209.14 with SMTP id h14cs32506wag;
Wed, 9 Apr 2008 08:03:33 -0700 (PDT)
Received: by 10.100.122.8 with SMTP id u8mr407885anc.46.1207753410386;
Wed, 09 Apr 2008 08:03:30 -0700 (PDT)
Return-Path: <121834869@qq.com>
Received: from isqbhofm.edu ([121.34.60.164])
by mx.google.com with ESMTP id 8si368499agd.30.2008.04.09.08.03.26;
Wed, 09 Apr 2008 08:03:30 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning 121834869@qq.com does not designate 121.34.60.164 as permitted sender) client-ip=121.34.60.164;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning 121834869@qq.com does not designate 121.34.60.164 as permitted sender) smtp.mail=121834869@qq.com
Date: Wed, 09 Apr 2008 08:03:30 -0700 (PDT)
Message-Id: <47fcdac2.08045a0a.2c21.32a4SMTPIN_ADDED@mx.google.com>
[base64 encoded chinese spam here]
An alternative scenario -- those other people uploaded their contact lists, and your e-mail was in there. When you signed up, LinkedIn ran a global search for your address and then presented the results to you as potential contacts.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
Set up SPF on your domain to cut down on backscatter spam. http://en.wikipedia.org/wiki/Sender_Policy_Framework
Are you sure that these other people weren't on LinkedIn and didn't upload *their* contact list (which contained your email address?)
Whether or not people want to admit it, understand it, or whatever, Google is contributing to email abuse with what they are doing. So are other email systems which don't properly validate recipient addresses during the initial SMTP conversation. By allowing this backscatter to occur they are abusing innocent third parties. What makes this even worse is that email admins have the ability to stop backscatter without breaking anything and without violating any RFC.
Some people have argued that by accepting all email for a domain they are stopping successful dictionary attacks. Not only is that false, it isn't a very valid point. There are still ways to figure out valid email addresses on a system: Spammers can use a valid envelope sender address so that they receive the bounces, and if no bounce is received the address is likely good; they can embed images, JavaScript, etc. in HTML emails to track which messages have been opened. That's all assuming spammers even care about valid email addresses. For a large part they don't care. Rather it is fire and forget, and hope the messages find real recipients. That approach is inexpensive for them. If they throw enough darts eventually one will hit the dart board. This is backed up by keeping track of email sent to non-existent recipients on your mail server over time. Recipient addresses that were rejected years ago are still getting attempted deliveries. If spammers kept track of bad addresses this wouldn't happen. If mail admins configure their mail servers to accept and bounce email for non-existent users, rather than reject, they are only further hurting innocent bystanders on the Internet. Even if this approach did make dictionary attacks impossible it most certainly doesn't stop anyone from trying one. If the envelope sender address of the spam was spoofed, which is usually the case, then someone else who had nothing to do with the sending of the email will now need to deal with the backscatter. Whether that is some end user who gets flooded with bounce messages reporting emails they never sent, or an organization's email system whose resources are being consumed by the backscatter, the result is someone else being abused. That abuse could have been prevented by the receiving mail server.
Other arguments have stated that mail systems that backscatter are simply complying with the RFCs. Some have taken even further to state that any other approach would actually violate some RFC. The "complying with RFCs" argument is a cop-out. That completely ignores the fact that all a mail system is doing by accepting and bouncing is forwarding the abusive traffic to someone else who had nothing to do with it in the first place. As far as rejecting mail that is sent to non-existent users actually violating some RFC, I challenge anyone to find which RFC makes that statement.
Another argument has revolved around multi-MX systems and how it would difficult or too resource intensive to maintain lists of valid recipients. If doing so is too difficult, or requires too much resources, for an organization I suggest they don't have multiple MX hosts or outsource their email to someone more competent. This has been done for a long time using RDBMS backends and LDAP. Those technologies aren't new. The fact is that Google *does* do recipient validation for the google.com and gmail.com domains. If it can be done for those domains then the argument that it is too difficult or too resource intensive for Google can't be valid. If Google can do it for google.com and gmail.com certainly they can for their other domains. In fact a very large number of email providers of all sizes properly handle recipient validation and do not produce backscatter. Scale is not a valid argument against doing so. If an organization is large enough to need the redundancy of multiple MX servers then they should be large enough to properly implement whatever redundancy is required by their backend to validate the users.
Not only does proper recipient validation on an MX
Hi SlashGang:
This may turn out to be overly simplistic and your criticisms are invited.
How about a system of personal blacklists/whitelists?
All users outbound mail RCPTs would be whitelisted by default.
Any mail received that is not on their whitelist would be blacklisted,
but kept temporarily in the mqueue.
When a user checks their mail, the server would send them a notice that an
unknown email from: is pending their approval.
The enduser then replys to postmaster with:
accept , in which case its removed from the blacklist and cleared in the mqueue
reject , in which case its deleted and permanently blacklisted
I realize that this would add an extra step for the enduser when getting mail from
someone unknown to their MX, forcing them to go thru
a 2-step process of clearing an unknown 'sender' on their MX.
and that personal blacklists would add overhead to the MTA
Also, any mail submitted by some user on a remote server (say through a form on a website)
would have to accomodate this new schema by first requesting to be whitelisted before
actually sending the actual reply to that formmail.
And there may be other considerations that i'm missing, but its just a thought.
( x) technical
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) This is a stupid idea, and you're a stupid person for suggesting it.
resist propaganda