procmail
[Top] [All Lists]

Re: Dealing with current backscatter spam

2008-10-17 13:26:10
At 20:06 2008-10-15 +0200, Michelle Konzack wrote:
Am 2008-10-14 10:47:11, schrieb Scott Edwards:
> Where is your mail hosted?

In Germany/Nürnberg.

I'm certain the question was meant more as in "how does it relate to your network connection" - is it on the internet side of your GSM, with your GSM being your workstation link to download mail for you to read.

Some likely configurations:

        (big, bad internet)
        (mailserver + procmail)
        (GSM)
        (workstation)

        (big, bad internet)
        (GSM)
        (mailserver + procmail)
        (some link, possibly local)
        (workstation)

        (big, bad internet)
        (mailserver)
        (GSM)
        (workstation + procmail)

> You're threatening to DoS?  It's apparent you're frustrated, and that's
> understandable, but it doesn't justify retaliation.

HOW do you want to stop such things?

DoS certainly wouldn't be the answer.

While I am writing this here, I prepare my "commercial" servers to  stop
the DoS'ing servers...  I have 16 STM4 and 4 STM16 and many  E2/3  which
should be enough...

Today, my GSM provider has  desactivated  my  GSM  card...  No  internet
access anymore...  I have top pay an Invoice of over 3000 Euro.

Okay, so the GSM problem is solved?

Do you honestly think that some admin who can't secure their mailserver is going to notice that they're getting a bunch of bounces BACK to them? Really - they apparently didn't notice that they're being used as a relay in the first place. And, you'd be generating THAT MUCH MORE TRAFFIC that you're grumbling you are paying for.

> What have you tried instead? Are you using a whitelist? What's the role of

Whitelisting what?

I have Friends, Customers and others in Russia, Corea, China...

I must kill the backscatter sendes One-by-One

Seems that it would be much easier to whitelist a finite list of friends. If nothing else, to elevate them above the spam. Less close friends would still be subject to passing through filters, but if your filters are well organized, this shouldn't be a huge problem.

> this email address you're receiving so much backscatter to?  tbh, your
> approach is very unprofessional.

The MAILER-DAEMON messages attaching always the original  message  after
the MTA reports and there are spamers using my E-Mail  to bomb over 2000
ISPs...  I get arround 30-100 messages from each targetet host back.

Is this ONE email source address of yours, or are they using random addresses at your domain? Widespread use of wildcard addressing at domains leads to an enormous spam hit for people, because spammers don't need to use a legitimate address to get mail to you, and when they forge with a randomized address, they still manage to bounce someplace.

If you're getting bounces for messages you didn't send, perhaps you should be checking the content for references to From: with your address and no reference to your legitimate sending servers in the embedded Received: lines.

Consider using a subdomain, such as mail.tamay-dogan.net for your email. REJECT all mail to the base domain, except perhaps abuse and postmaster (or provide a link to a webpage explaining how to contact those roles). This will sharply reduce the amount of crap you get, because spammers tend to use the base domains - they're not bright enough to look around for required mailhosts.

The spamers are targeting 90% in all cases russian domains where  those
crapy MTAs are siting which can not detect the forged From:.

So, uhm, consider blacklisting those hosts.

        In your nameserver, set up a zone for a new LOCAL dnsbl.  You'll
        populate this with known backscatter hosts.  Do not make this a public
        zone - only your hosts should have access to the zone.

        Configure your MTA to use this new dnsbl to reject mail.

        Use procmail to scan backscatter bounces, grab the relay server
        (caution: if you have backup MX's that are not under your control,
        you'll need to take extra precautions) and add them to a zone update
        file.

        Every 5 or 10 minutes via cron, invoke a perl script which parses
        the zone update file and merges it with the dnsbl zone.  This could
        track how recent and how much volume you've seen from any given host,
        and use this to determine whether a given host should be in the
        backscatter dnsbl or not.  You could track info in the zone file
        using TXT records.  After updating the zone file (and serial), the
        perl script can tell the nameserver to reload the zone, instantly
        propogating to the MTA.  Perl script could have an ancillary file
        which is used to remove or block hosts or domains from being listed.

Then, as you get backscatter, it'll cut off those hosts responsible for the bulk of it. You could have the perl script generate automatic email notifications every few days of processing for hosts which have been listed, delisted, and listed again (meaning it wasn't a one-time hiccup) - do whois lookups, or standard RFC postmaster or abuse addresses at those domains.

I did this sort of thing with my Vermicide worm defence mechanism for Apache. An attempt to compromise my hosts would trigger a script which would perform whois and netblock lookups, and notify responsible parties, with cacheing of the attempt so that I wouldn't be tagged as a spammer for sending the notifications.

My backscatter spamcount is now arround  98.000 ~ 1.5 GByte  of  traffic
since Friday 2008-10-10.

If I ventured a guess, it'd be that your massive sigline must have irked somebody.

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail