Slashdot Mirror
Some Anti-Spam Vendors Blocking and Slowing Gmail
fiorenza writes "Google's Gmail (and corporate mail) are being throttled and sometimes blocked by some anti-spam services, including MessageLabs and Antigen. Ars Technica reports that the blocking is a result of the Google CAPTCHA crack, which has allowed a deluge of spam from Gmail's clusters. Most users won't get blocked mail, but Ars confirmed with MessageLabs that Gmail delivery delays are to be expected."
I definitely agree with you, if a mail server accepts my mail with a 200 code, then the mail *should* be delivered. Even if its put in someone's spam folder, the message should get there. That's one of my pet peeves. That being said, from my experiences when setting up my mail server, Gmail was probably one of the best about not blocking legit mail (I've had an SPF record since the beginning though). I had lots of problems with Hotmail, and I think my mail was usually marked as spam by Yahoo until I enabled DKIM signing. With SPF records and DKIM, I don't think I have any major problems (though my mail server handles a pitifully small amount of mail, so its not like we're going to get marked as a bulk sender).
Every time you post an article on Slashdot, I kill a server. Think of the servers!
Just to add something, the problem with 5xx replies is filter is *before* queue so some mail may be delayed and servers need to be contacted a few times before they get a delivery slot. For example, say gmail can filter 1 million messages at a time. That means 1 million open connections. So, if you are connection 1,000,040 you get 4xx response - temporary failure due to no available resources. So try again later.
/dev/nulling spam while accepting it with 2xx code is like burning unopened envelope at post office because it was typed instead of handwritten indicating possible spam.
This is not a problem, really. You can wait a few days until you can deliver the message as long as it is *delivered* eventually.
Pre-queue filter with only 1 unique IP connection at a time to mail server. Problem solved.
Huge email servers get reasonably constant and predictable amount of mail per day and per hour and even per minute. They can plan pre-queue filtering with some margin for any spikes. And if there is a huge bomb and your mail doesn't get there for 7 days and your server gives up, hey, at least you get a "Could not deliver the message because destination was not available". Much better than "err, never got any mail from you" from the destination party.
I think the safest thing they can do right now is return to their invitation only registration in an effort to close the breach. Then they have to start deleting spam accounts quickly before the spammers adapt to inviting themselves. If they are lucky they will be able to delete spam accounts faster than they multiply.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
welcome to spamtrap@donotreply.com (just kidding, but donotreply.com gets a lot of interesting e-mail, I just wondered what they'd do if they started getting 'spamtrap' addressed mail)
well, making special spamtrap e-mail addresses and putting them in the clear on usenet, message boards, or even on social networking sites owned by google, and making sure the content is boring drivel no one would e-mail that person about. well, i mean how could you decide how to make boring drivel that would still put their address out on sites? 'first post' messages?
wouldn't someone notice that google got 'first post' every time on 123 consecutive front page articles? wouldn't they? though and e-mail them a congratulation and get spam busted?
i mean i know i can post boring irrelevant information, but i can't guarantee that if an e-mail is tied to that identity that someone won't e-mail me....
so spam traps are harder to implement than one would think, unless they're in 'hidden' code. EG: you go to a website, the e-mail is in the html, but never shows on the page... and if you do that, then they might make a scanner that nullifies those addresses... once the realize what's happening.
https://www.gnu.org/philosophy/free-sw.html
Expect to see a technological solution, this isn't a company full of middle managers or people who are used to losing technical battles.
If I were a betting man I'd say Google will either A) release a new authentication/authorization scheme for creating new accounts, or B) they'll evolve their current system to be resistant to delivering false negatives on bot provided responses.
Because honestly, isn't this just graphical/visual acuity based Turing test that needs to be treated as "passed" by the industry? The reasoning being: the equivalent of Alicebot now exists for the graphical world, so the test needs to be re-engineered to test another (currently) unpassed Turing style evaluation.
Based on that realization: the whole reason capcha's are stupid is that if you keep the existing design but try and make it "harder" to break, the designer of the Bot need only account for that change and not an entire redesign.
All this sounds like a great technical challenge: think up a new Turing test... When in reality those posting go back to invite only are absolutely right but it's likely we won't see that come out of Google.