Slashdot Mirror


AOL Blocks 2 Billion Spam/Day

T_moz writes "According to this article AOL has blocked over two billion (2000000000) SPAM emails in one day!" This figure is 70-80% of all mail incoming to AOL users. Utterly insane. Unfortunately, all this blocking means spammers will just send more mail to make up for it until a real solution is found.

9 of 108 comments (clear)

  1. no wonder by DanIncognito · · Score: 4, Funny

    No wonder I can't get any help with my nigerian bank account problems!

  2. :D by Anonymous Coward · · Score: 3, Funny

    Wow, the filters are sooo good they blocked all the comments to this story.

  3. Want a solution? by DA_MAN_DA_MYTH · · Score: 5, Funny

    Execute a spammer. It's clean, it's quick, and it's efficient. Desperate times call for desperate measures.

    See if people will keep sending unsolicited email then. Matt Groening had it right with Futurama.

    Computer: "You've got mail!"
    Leela: (Groans)
    Computer: "It's not spam!"
    Leela: Ohhh

    --
    "It takes many nails to build a crib, but one screw to fill it."
  4. Good for them!!! by iwillrefuse · · Score: 4, Funny

    Now, if I could only stop these assholes who send me unwanted CD-Rom's to my home 3 times a month...

  5. That's emails, not spams. by AnotherBlackHat · · Score: 4, Interesting

    Funny how nobody ever mentions the false positive and false negative rates in these stories.

    If AOL has a false positive rate of 0.01%,
    That means over 200,000 incorrectly blocked emails per day.

    If they have a false negative rate of 1%,
    That means over 20,000,000 spams got through.

    2 billion sounds like a big number, but it's still only 10-30 spams for the typical AOL user.

    -- this is not a .sig

  6. That's just the tip of the iceberg by Anonymous Coward · · Score: 5, Interesting
    Two billion every 24 hours is about right. AOL has LED banners in their offices that show the daily spam count.

    There is the graph they have on the wall in one of their Dulles offices that shows how the filters are working. It's scary, when a new type of spam filter is put out, AOL mail traffic decreases about 60%. The graph line plummets. Then, you watch it creep and spike until barely a month, maybe even a couple of weeks later, it's back up again. The spammers have found another way around it. People joke and laugh about AOL and spam, but AOL is really serious about getting rid of it. It costs them uncountless piles of money just to keep spam from breaking down their walls.

    I have also attended some pretty heavy security conferences about spamming for ISP folks. It's not just a mail flood technique anymore. Spammers are not just some freak in China with an ISP who looks the other way, some spammers are actually crackers. Crackers who break through an ISP's security, just to get around mail filters, or relay it from within. Some of the spam you get is not just because the ISP didn't filter it, it's sometimes because some cracker found a new way to bypass the filter, a back door to the ISP's internal services, so they send it in, even relaying spam from personal accounts. These are not script kiddies doing this, there are bonafide hacking geniuses working as spammers.

    Spam can shut down an ISP, and AOL knows that all too well.

  7. Re:That's easy. A tale of bouncing AOL spam. by dmeranda · · Score: 3, Informative

    Most email that appears to come from AOL in fact comes from somewhere else. Same for all the big ISPs like yahoo, msn, hotmail, and so on. Not only do spammers forge the From: headers, they are also forging the SMTP envelope MAIL FROM as well.

    Actually we were inadvertently relaying undeliverable spam back to AOL customers and found ourselves blacklisted by AOL until we cleared it up. No, this is not an "open relay" problem; this was an "undeliverable bouncing" problem. But the effect was similar. You really need to be careful because spammers are getting very smart.

    What was happening was that mail which got through our SMTP gateway (running sendmail) and into our back end internal email server (running Exchange) was being bounced as being undeliverable because of the made up recipient addresses that spammers use. The problem was Exchange was creating these "bounces" as NEW email messages rather than as an SMTP DSN rejection, mearly prepending "Undeliverable:" to the subject and sending the message to the supposed sender. But those forged senders turned out to be real AOL user accounts, and being AOL users they flagged our bounces as being spam, and poof, after about 15,000 in one day we got blacklisted....actually I can't blame AOL at all.

    The AOL postmasters were surprisingly helpful and courteous in helping us resolve this. What I now do is to take the connecting IP address and do a reverse DNS lookup. If it is not from within the aol.com or aol.net domains, it is rejected as being forged (regardless of what the headers or even the envelope say). Likewise I also check the responce on the HELO/EHLO greeting to make sure it is also from aol.com. And just as an extra check, I finally configured our sendmail milter interface to use LDAP to the exchange backend server to reject mail for invalid mailboxes before it is ever passed through to our backend server.

    Now if there were reliable was to detect forged mail from the other big ISP players. I can only perform those forgery catching tricks with them because AOL has a policy that ALL outbound mail from AOL will ALWAYS be sent from an SMTP server registered within the aol.com DNS domain. I don't know if that is necessarily true for the other big ISPs.

  8. A solution to spam by Peaker · · Score: 3, Interesting

    There seems to be a solution to the spam problem - but one that is not backwards compatible.

    I have seen this solution posted as a comment to some story in the past - so the credit is not mine, but of some comment writer I do not recall.

    The idea is to create a complicated and expensive hashing algorithm that costs quite a few cycles - and use it as a "signature" for each mail's content, including the from and to addresses.

    This would mean that sending mail could require a few seconds and be cpu-bound instead of network bound, but this is almost nothing for the average mail user. The spammer, however, would be required to calculate the hashes of the hundreds of thousands of mails he is sending - which could be a costly calculation.

    Perhaps, (and this is my idea :), the hash function could be controlled by the server which would require the sender to sign using a function of higher complexity when loads are higher.

    Perhaps (another idea of mine), users could signify as part of their email addresses - the complexity of the hash function required to send them mail, or at least know what complexity of a hash function was used when sending them mail.
    This could allow users to reject mails that weren't at least a bit costly for the sender to send, thereby making spam too costly to practically send.

    White lists can also be used by users to save their friends from the trouble of calculating a hash of their mails - but this is probably unnecessary as it should only take a few seconds at most.

    Ofcourse verifying the mail's hash should be trivial, no matter the complexity of the hash function - and mails with unmatching hashes would simply be thrown away immediately.

  9. Re:If you're blocking it you don't know WHAT it is by caouchouc · · Score: 3, Informative

    Same thing here. I know legitimate email from my server is part of their 2bn figure. AOL may block 2 billion emails a day, but that includes a larger number of false positives than ever in light of their cable/dsl blockage months ago.

    I can't even receive from AOL now as they've landed on a RBL I reference. Not because they're blocking cablemodems (which is their choice), but because their implimentation violates the SMTP RFC. The RBL blocks non-compliant servers, confirmed open relays and smtp agents confirmed vulnerable to exploit (via correlation between version # and security advisory).

    AOL's mail server sends a 550 and disconnects you the instant you connect. 220 and 554 are the only allowed responses at that point, and immediate disconnection is not permitted; The server must wait for the client to send a QUIT before closing the connection.
    Since you're disconnected immediately, this behaviour also indirectly violates the requirement that the server always accept e-mail for postmaster.