back to article Stamping on the spam or wading through it?

It's messy, slippery and gets everywhere, particularly the high-quality stuff. Spam is still the scourge of the unwary company, and if you don't know your whitelists from your blacklists, you might want to check out our new primer for some spam management pointers. As far as external business and IT annoyances go, spam is …


This topic is closed for new posts.
  1. Geoff Mackenzie

    Lol ...

    Stop spam! Enter your details here, use this product. :)

  2. Anonymous Coward


    Well, one thing admins should do is turn off that bloody feature where spam mail is automatically bounced, ie, returned to the sender.

    Problem is, spammers either use a non-existing email address, or a working address they have picked up through whatever means those slimy dirtbags use. And as a result people whose email addresses have been "hijacked" as a from: / reply-to: can expect hundreds if not thousands of delivery failure messages.

    I speak from experience, and I sincerely hope that admins either turn off the damn feature, or locate a suitable cliff and hurl themselves off it.

  3. Tomothy Toemouse

    @AC Re: Anoniempje

    I've been in the same position except with a virus email - some of the bounced messages had the virus removed and some "returned" the virus to our company complete.


  4. Dave Harris
    Dead Vulture


    You're talking about backscatter. What most reasonably competent mail administrators do is not accept the message and then bounce it back when classified as spam, because that way, we end up with shitloads of dead mail, ie, NDRs that can't go anywhere because the "sending address" doesn't exist.

    What we do is try to work out ways to not accept it at the handshake stage, so that it doesn't even get processed. This is normally based on DNSBLs, ORBLs, sending IPs in our honeypots, or anything else.

    There was recently a spate of spam which was all purporting to come from "Canadian Pharmacy". Essentially, that was always the local part of the sending address, whereas the real address was always a address. Actually, this was a massive failure on Yahoo's part, because Yahoo failed to acknowledge the mails were coming from their servers (I have the routing headers to prove it), yet these mails were sent by an SMTP, rather than webmail, client, ie, a genuine Yahoo account.

    See for more (the guy who writes the blog is acknowledged as the King of anti-spam for Domino).

    Anyway, in my organisation, if the From header contains the phrase "Canadian Pharmacy" it does not get accepted at the handshake level. If it was just a botnet (as far as I'm able to determine), it wouldn't even be allowed to connect, but I'm not allowed to blacklist Yahoo.

    We also recently had a spate of dodgy NDRs where a customer's employees' contacts', not the employees' themselves, local address books on their home machine had been compromised and used to grab spoof sending addresses for shitloads of spam, mostly for non-existent addresses. Had the targeted organisation refused mail to non-existent addresses at handshake, our customers would not have received the NDRs, and spared us having to implement a rule that quarantined all ReturnPath="<>" messages, which included legitimate NDRs that users need to know about.

    I've said this before, but the simplest way to hit spam would be for ISPs to block port 25 for their domestic broadband customers, unless those customers could prove they had a safe environment with a legitimate need for outgoing SMTP traffic. We already block whole swathes of identifiable domestic networks, by our own mentods and by, but some ISPs could help by submitting their ranges to Spamhaus and let the mail guys make their own decisions. Of course, if you're billing your customers by MB sent, that may not be in your interest.

    What end users can do is treat their email addresses like their home and mobile phone numbers, ie, only give it out to people and organisations they trust, and that they trust to do the same.

    And not use a compromisable client like Outlook.

  5. Dave


    It depends on how mail is 'bounced'. If it's done properly on initial connect then most spam just disappears[*]. However, some places initially accept the stuff, process it and then email out a fake bounce message to the apparent From: address. This is what usually causes the backscatter. I know the virus scanner stuff used to be particularly irritating telling me about viruses that had been detected in stuff I never sent. I was seriously contemplating writing a filter to spot such things and send them straight back to postmaster@virus-scanner with a note that they needed to sort *their* system out and stop it spamming me. Some companies would have received a lot of those messages had I implemented it.

    [*] This is based on my unscientific observation that when I bounce spam that has been forged to come from an address @my domain, I never, ever see the expected attempt to deliver the bounce back to that address.

  6. Shane Rogers

    How to fix backscatter

    I once had a nasty backscatter problem, until I wrote a script to forward all the bounced mails to the email address the company was using on their website.

    Amazingly, over 6000 emails and 2 days later, the problem suddenly stopped. :)

  7. Stephen


    To fix backscatter you really need to properly implement SPF checking on inbound traffic and have a SPF record against your domain's DNS.

    Most mail hosts are checking using SPF these days and its a great tool for cutting down the backscatter.

  8. Seanie Ryan


    greylisting.... simple.

  9. Jonathan Richards
    IT Angle

    It's messy, slippery and gets everywhere


    I once saw the aftermath of a burglary, in which a safe had been prised from its fixings on the floor, which happened to be in a school kitchen store room. The clown with the crowbar had attempted to use a large can of Spam (tm) for a fulcrum, which of course had merely crushed the can, causing an explosion of dead pig product in all directions.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019