Google Mail Servers Enable Backscatter Spam 344
Mike Morris writes "Google email servers are responsible for a large volume of backscatter spam. No recipient validation is being performed for the domains googlegroups.com and blogger.com — possibly for other Google domains as well, but these two have been confirmed. (You can test this by sending an email to a bogus address in either of the domains; you'll quickly get a Google-generated bounce message.) Consequently spammers are able to launch dictionary attacks against these domains using forged envelope sender addresses. The owners of these forged addresses are then inundated with the bounce messages generated by the Google mail servers. The proper behavior would be for the mail servers to reject email traffic to non-existent users during the initial SMTP transaction. Attempts at contacting them via abuse@google.com and postmaster@google.com have gone unanswered for quite some time. Only automated responses are received which say Google isn't doing anything wrong."
Comment removed (Score:5, Funny)
Re:Translation (Score:4, Funny)
*goes change his gmail password* (Score:5, Interesting)
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* (Score:5, Informative)
Mod Parent Up (Score:3, Informative)
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.
Re:Mod Parent Up (Score:5, Informative)
Use POP3 for all your email. That way no website can ever get access to your contacts or personal data.
Re: (Score:3, Interesting)
Not particularly secure, that...
Re: (Score:3, Interesting)
You want secure email you GPG to encrypt it.
Re: (Score:3, Informative)
Re:Mod Parent Up (Score:5, Informative)
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...)
MAPI != anti-IMAP (Score:5, Informative)
Re: (Score:3, Funny)
Comment removed (Score:5, Funny)
Re:*goes change his gmail password* (Score:4, Informative)
The "russian" kind?
And I'm absolutely positive I didn't give them my gmail password.
Re: (Score:3, Informative)
Re:*goes change his gmail password* (Score:5, Informative)
Re:*goes change his gmail password* (Score:5, Interesting)
Seriously, I barely trust myself with my personal info -- why trust a complete stranger (or set of strangers) that are based out of a country where the gov't can just lean on a company to get private data?
The staff at Facebook don't give two shits about privacy, otherwise all those stupid "apps" which you add to your profile wouldn't be able to spider your friends or send them stupid form letters to encourage them to allow/add them (furthering the data-mining by the app writer). Try turning the privacy settings up by disabling everything when adding an app. It won't let you, because then the app "wouldn't work" correctly.
Re: (Score:3, Insightful)
Already Google admitted to being in cahoots with the NSA/FBI/CIA (etc) in providing them with data on their Google web app usage.
Link or it didn't happen. I could find info on Google providing technology that allowed the NSA/FBI/CIA to cull through its own information, but nothing on providing these agencies with private information.
Facebook is just as bad with their beacon source
This proves the parent poster's point. Facebook tried it and there was hell to pay.
Try turning the privacy settings up by disabling everything when adding an app. It won't let you, because then the app "wouldn't work" correctly.
Then don't add the app. Facebook gives you fine-grained control over what you want to let applications do, so they can't spider your friends.
Re:*goes change his gmail password* (Score:4, Insightful)
What? Some site asked for your email password, and you gave it to them? Shouldn't people reading Slashdot know better than this?
Re:*goes change his gmail password* (Score:5, Interesting)
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* (Score:5, Funny)
Re: (Score:3, Informative)
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 emai
Re:*goes change his gmail password* (Score:5, Informative)
Re: (Score:3, Informative)
Yes, but Javascript doesn't share data between domains without pop-ing up a pretty nefarious-looking security warning (of course, if the music site had been installed as an IE extension, or a firefox extension, or a separate spyware executable, or if the user had manually turned off that default security setting, those would have been other ways to
And google wonders why ... (Score:5, Insightful)
I wonder how much of this has to do with the Microsoft to Google employee migration bringing the corporate culture with the people?
Comment removed (Score:5, Funny)
Re: (Score:3, Insightful)
Re:And google wonders why ... (Score:5, Insightful)
Re: (Score:3, Insightful)
Re:And google wonders why ... (Score:4, Informative)
Besides which, google had basically no choice but to go public - the SEC rule would have require them to file financial papers as if they were public - so why not get the benefit as well?
Re:And google wonders why ... (Score:4, Insightful)
Re: (Score:3, Insightful)
So let me get this straight, the share holders want google to allow backscatter spam?
Finally, a voice of reason in this thread. I can't imagine why anyone would think this is part of some diabolical plot. I fuck up at my job sometimes, so does google, why does it have to be a conspiracy when it's a big company?
I forget who said "Never attribute to malice that which can be adequately explained by stupidity." but I think that applies here.
Re:And google wonders why ... (Score:5, Funny)
just point it out to them more clearally. (Score:5, Interesting)
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. (Score:5, Funny)
abuse@gmail.com has an auto-response. bogus@gmail.com 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....
Re: (Score:3, Funny)
No fucking shit :)
LOL. I learned that one the hard way. A mail server grinding to a halt and an entire raid filling up with messages. I almost could not even get the machine to respond at all via the console, let alone remotely administrating it. Took out the whole mail server during the middle of the day for about 3 hours.
You never heard such squawking from the users and the Pointy Haired Ones. The CrackBerries went do
Re:just point it out to them more clearly. (Score:3, Informative)
Proper? (Score:5, Insightful)
Ummm, how about the only behavior
It never ceases to amaze me how some mail server administrators setup policies on their networks. If you are running a mail server you are THE POSTMASTER. If you don't know where it should go, or who it is supposed to be going to, how can you accept it?
Refusing email and stopping the transaction when you do not control the domain, service the domain, or even know the mailbox user is about as obvious a policy as not relaying for domains outside of your control.
If it is an honest mistake on the part of the sending server, acting as an agent for the user, then a simple message informing the sender that the account does not exist is a trivial matter.
To do anything else just amazes me.
Re: (Score:3, Insightful)
Re:Proper? (Score:4, Informative)
got a tip for you:
spammers don't care if the addresses are valid or not
What you describe is called a 'rumplestiltskin' attack - it's well known, and nobody has ever suggested that the best way to counter it is to start spamming people with backscatter.
Re: (Score:3, Informative)
Re:Proper? (Score:4, Insightful)
Actually both are crap.
Unfortunately there are no good ways to handle it, that I know of. They all allow for harvesting or backscatter. The only way to avoid both would be to accept everything and never respond. But then every blackholed email is potentially a genuine error for which there is no indication.
Re: (Score:2, Informative)
That would be the best thing to do, but it's not always trivial. In fact, sometimes it's impossible [slashdot.org].
I've seen e-mail setups where after the mail is sent to the servers in MX records it goes through several MTAs until it's finally delivered. In order to be possible to reject the e-mail at SMTP time, you'd have to do some kind of synchronization between the MTAs so that the MX server could know whether the addresses exist. Plus, the same domain could read users from several databases at the same time (e.g.
Re: (Score:2)
Re: (Score:3, Insightful)
Those who fail are likely to find themselves on numerous blacklists -- correctly listed as spammers.
Re:Proper? (Score:5, Insightful)
I am not sure what "it" refers to. We are talking about two different things here, which is what occurs inside a SMTP transaction and what occurs outside of it.
Inside these SMTP transactions nothing is occurring that is facilitating the delivery of SPAM directly. Just the harvesting of good addresses for those domains. Afterwards, they can use the good addresses to send SPAM directly to those mail boxes.
What is stupid here, and I use that word deliberately, is Google's apparent policies. Regardless of any other considerations, you should not be sending bounce messages to FROM headers. Any action taken should occur within the SMTP transaction with 5xx or 2xx codes. Doing so is, for lack of a better word, just plain STUPID. When those FROM headers contain users within your own domains makes it just that much more retarded. Why would you be sending a bounce message to your own user from activity that did not originate within your own systems? Last time I checked you would not be doing so.
Any messages that came from your own users would be through authenticated SMTP transactions and any recipient errors would have bounce messages routed locally back to the sender. You don't even need the FROM header if it is in an authenticated session from your own user. You already knew which user it was from the authentication process. If you have SMTP transactions, that are not authenticated in most cases, coming from systems outside of your direct control, then it can't be from your users and therefore you should not be sending messages to them.
As for the SMTP transactions themselves being used for harvesting there are other methods to deal with that. You don't need to bug the crap out of your own users doing it either.
If I have a SMTP transaction attempt delivery to an unknown address outside of my domains (relaying), I explicitly add them to the block lists for 60 minutes. Sending mail servers should be using the domain in the TO header to obtain MX records of my mail server. For my mail server to get a message for domains that I don't control is a huge red flag. If it is to an unknown address within my domains I block them for 20 minutes, but only after 3 such transactions within 10 minutes. That will allow any honest typos from stopping service from valid mail servers.
When you get a ton of these SMTP transactions in a row maybe, just maybe now, you should be adding that IP address to a dynamic suppression system for longer periods of time, like say weeks. Here is the kicker too, if these SMTP transactions came from a Zombie machine then you are not even interfering with that person's ability to send mail since they will be doing through a web based email system such as Google or an email client that will send their email (through an authenticated session) to a real mail server that will then send it out.
There is a LOT more to this, but I can tell you that Google is doing it in about the stupidest way possible right now. That's just my opinion, but I do operate several mail servers right now and I can't see anything smart about these policies.
In beta (Score:4, Insightful)
FWIW, I use Google Apps to host my e-mail, and I have found Google to have horrible support.
Instead of fixing the problem, they'll just point you to a loosely moderated Google Groups newsgroup for Google apps, and you'll rarely receive a response, let alone a workable fix for an issue.
Do no evil? Or do nothing at all?
Not Gmail. (Score:4, Interesting)
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.)
and? (Score:3, Interesting)
Inaccurate title/summary (Score:4, Insightful)
We're writing to let you know that the group that you tried to contact (example12345) doesn't exist. There are a few possible reasons why this happened:
* You might have spelled or formatted the group name incorrectly.
* The owner of the group removed this group, so there's nobody there to contact.
If you have questions about this or any other group, please visit the Google Groups Help Center at http://groups.google.com/support [google.com].
Thanks, and we hope you'll continue to enjoy Google Groups.
The Google Groups Team
In other words, while this causes backscatter, this is not an avenue for "backscatter spam", since Google isn't delivering the contents of arbitrary messages to arbitrary users.
It sounds like the submitter wants to blow this out of proportion by equating general backscatter (which nearly all mailing list managers on the Internet generate with their "confirmation" messages) with backscatter spam.
Re:Inaccurate title/summary (Score:5, Informative)
Hey, look. It's a kdawson article!
Re: (Score:2)
Re: (Score:2)
Re:Inaccurate title/summary (Score:4, Informative)
Re:Inaccurate title/summary (Score:5, Informative)
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.
MOD PARENT UP (Score:3)
Re: (Score:2)
Just because one isn't evil, doesn't mean one is competent or incapable of error.
Re: (Score:2)
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.
Yes, but the contents of the message can't be controlled in any meaningful way, so as you said:
No spammer is going to send a million messages with different forged addresses ...
... unless they can control the content of those messages.
The distinction is obvious. If spammers can't control the contents of the bounces, the bounces won't get them paid.
Re: (Score:3, Insightful)
Nobody is claiming spammers are getting paid for the backscatter. Backscatter is just collateral damage to the original spam. Spammers don't care because it doesn't cost them anything, but they aren't doing it on purpose. That's why it is the responsibility of the mail administrator to ensure that THEY don't involve third parties in their spam by generating completely new messages and sending
Re: (Score:3, Informative)
1) mailing list confirmations can't be used by spammers to identify existing or non-existing e-mail addresses
2) spammers, unlike your test, will use spoofed From: headers, making the mail you got be bounced back to someone who wasn't involved in the first place
3) yes, right now (1) isn't true for Google either, since they accept all mail, but that is indeed the problem right now, and there are stupid spammers out there who will blast thousands upon thousands of e-mails o
Re: (Score:2)
You're telling me that you would prefer thinking that you sent an e-mail to someone, and that they received it, even if you mistyped the address by one letter?
I don't see what they're doing as wrong at all. They aren't bouncing the original message, so spam is not originating from google's domains. They're also announcing e-mails which failed to arrive at their intended destination.
Re: (Score:2)
The server trying to deliver mail (server X) contacts the destination server (server Y). The destination server immediately says "nope, sorry, that user doesn't exist" so server X sends a mail back to the sender saying "Server Y said 'user not found in user lookup'" or somesuch
Re: (Score:2)
A suggestion for Gmail spam-fighting (Score:5, Interesting)
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.)
Re: (Score:3, Informative)
http://craphound.com/spamsolutions.txt [craphound.com]
Please tick the appropriate boxes....
Re: (Score:3, Insightful)
That form was a funny joke the first few times it was used. Since thing it has simply become a generic excuse for "No, we cannot."
Actually, I don't think there is any way to truly address the spam problem without dealing with the TANSTAAF
Re: (Score:2)
Re: (Score:2)
The FUSSP is just another irrational argument for "No, we can't." The world is not perfect, and obviously there are no perfect solutions--but that doesn't mean we should just give up on good or even partial solutions.
Re: (Score:2)
Re: (Score:2)
Perhaps you don't get enough email? Even if the spam detection is 99.9% accurate, if you get 1,000 pieces of non-spam email, then one them will be tossed in the spam folder. Based on my data, I'd say that Gmail is probably higher than 99% but
Re: (Score:2)
I've been using gmail for just under 4 years and in that time I've received about 30,000 messages, 90% of which are from mailing lists. I've never had a false positive for me personally and I've only had a small number (<20) of false positives for mailing list emails (and none in the last year). Overall I think the detection is probably on the order of 99.5% accurate for me, but seems to have got bett
Re: (Score:2)
Re: (Score:3, Funny)
( ) technical ( ) legislative ( ) market-based (*) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the mone
Re: (Score:2)
If they're invited to a meeting by their manager and they don't want to deal with it, what do they do? Mark it as spam.
They don't delete it, they don't move it, they don't decline it or accept it... they reported it as spam.
Seriously guys, WTF?
Re: (Score:3, Insightful)
Just this week they apparently discovered a botnet larger than Storm. (http://www.theregister.co.uk/2008/04/07/kraken_botnet_menace/) The report says that the botnet was spewing out vast quantities of spam for the usual quasi-legal scams. So how the heck could they miss it? Possible answer
Re: (Score:2)
Re: (Score:2)
However, I certainly can say a lot about the other side of it. You don't want to fight spam, then don't use it. Me? I really hate the spammers and I would gladly do anything I can do that harms them.
You can argue that the harm of a particular piece of spam is very small. Perhaps a second or two if I'm just checking for misfiled ham--but the cumulative effect of *MILLI
250 Accepted (Score:5, Interesting)
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: (Score:2, Insightful)
Re: (Score:2)
Re:250 Accepted (Score:5, Interesting)
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.
Re: (Score:3, Interesting)
Universal filter? (Score:2)
(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 p
Re:250 Accepted (Score:5, Interesting)
Since SMTP is defective by design, this is an acceptable response. Doing anything else allows spammers to confirm valid accounts using dictionary attacks.
Re: (Score:2)
The problem with the initial reject is that it creates the same problem, once removed, when done over an open relay. This way gmail keeps some control. I would be interested to see whether they are actually answering all messages or have some limiting in place. It is also quite possible that they never thought of this issue and their architecture does not allow initial reject at the moment. P
Take note of the date and time (Score:2)
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
Google Groups must DIE (Score:3, Interesting)
Re: (Score:2)
And almost as bad, if you use Google Groups to read and post, you see a great swamp of spam -- much of it FROM Google Groups accounts - (EG, take a look at comp.programming [google.com]) over recent weeks. Many ISPs no longer provide NNTP servers, Google Groups is
Re: (Score:2)
Not Gmail... (Score:2)
So it's googlegroups.com and blogger.com, but not Gmail? Interesting.
Fishing, maybe... but do spammers really care? (Score:2)
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
Qmail has done this for years (Score:2)
It is not that easy.... (Score:5, Interesting)
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.
Secondary MX hosts declared bad! Film at 11. (Score:2)
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 h
Re: (Score:3, Informative)
Let me repeat that: they are required to unconditionally accept mail for the domain.
Bull. Fucking. Shit.
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 not just go back to Blue Security Model? (Score:3, Interesting)
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!
Behaviour isn't WRONG wrong, but Not Good. (Score:3, Interesting)
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.
Collateral spam (Score:3, Insightful)
Is what I know this as. I used to get so much spam it drove me crazy. I set up filter rule after rule, used RBLs and everything but it only helped partially. I could still live with it. But eventually, I was hit by huge waves of collateral spam and eventually got more of that then the real thing*, and that was when I decided email was either going to be entirely useless to me or I had to do something very drastic.
I opted for something drastic. I still have a large number of filter rules, but in addition to that, I use a whitelist instead of a blacklist to filter email, and everything not on my whitelist that survives the spam filter rules ends up in a bulk mail folder I check about once a week. Now if someone I don't know emails me, that stinks, and I constantly have to adjust my whitelist to allow for more addresses, but at least I barely see any spam - real or collateral - anymore. Without that I'd have given up on spam altogether.
*) In the order of several 1000 a day
MFROM signing (Score:3, Insightful)
Google clueless? (Score:3, Interesting)
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).