Proper Ways to Dispose of Spam?

An anonymous reader asks: "My domain name is being stolen by spammers; they forge outgoing mail using my poor innocent domain name. First, I'd like to plead with mail server administrators out there: please REJECT spam and undeliverable mail. If you reject instead of bouncing then legitimate mail senders will still know there is a problem. Second, do you have any tips for dealing with a flood of spam bounces? Exim is pitching the bounces pretty quickly, but my server is still getting overwhelmed." In the case of stolen sender addresses, SPF attempts to address this problem but has it been effective?

SPF!

[Alphager]

Two of my domain-names are in several spammer-tools and i was inundated by spam-bounces (and auto-replies). With SPF, i am down to one bounce every now and then.

SPF somewhat effective

[asc4]

SPF is only somewhat effective as unfortunately only some have adopted it. Still, it takes all of a few seconds to add an SPF record for your domain. It can't hurt. Also, try reporting the servers hitting you with backscatter to Spamcop. Again, it might not help much, but it can't hurt.

SPF is effective... sort of

[XenoPhage]

SPF is only effective if everyone uses it. It's pretty much that simple. Problems with forwards and mailing lists aside, SPF seems to work pretty well. I've been using it for a while now and I like it.

As for what to do... It's a tough call. You're being affected by a "Joe Job" [http://en.wikipedia.org/wiki/Joe_job] .. Defending against this is not the easiest thing in the world. Filtering is probably the only route you can go right now. you should be able to filter based on the subject and To: address, looking for MAILER-DAEMON messages to the users being affected. That's how I would deal with it to begin ... Then perhaps limiting SMTP from the outside world, prioritizing local user traffic. That should calm the server down a little.

For the record, every mail server I've worked on has been set up to reject. I learned a long time about that bounces and double bounces can easily kill a server. Great idea in theory, but the low-lifes on the net make good ideas regretful..

SPF is Marginally Effective

[prothid]

I am having this same issue. I have SPF set up with '-all' on the end of it. This still lands me with a lot of bounces every day. I am using Gmail for my mail and I have about 10 to 20 bounces that didn't get caught by their spam filter sitting in my inbox every morning.

Here is the SPF line I am using with Gmail (with an irrelevant ip4 entry omitted):

@ IN TXT "v=spf1 mx include:aspmx.googlemail.com -all"

I figure that at worst, I am keeping myself off blacklists because the ones likely to blacklist my domain have at least implemented SPF. It is still a fairly annoying situation. It is probably worth noting that I have a catch-all alias for inbound emails. I like to give a different email address for each site I go to so that I can track who is sending me spam. The downside to this apparently being that it potentially opens your domain up to being used TO spam.

Re:SPF!

[crow]

I found SPF to be nearly useless. I would think that spammers would automatically avoid domains with SPF records to increase their hit rate, but apparently not.

Re:SPF is Marginally Effective

[Neon Spiral Injector]

Spammers *love* domains with catch-all aliases and specifically target them for impersonation. I would suggest finding an easy way to add new aliases as needed (so you can create one just before you sign up on a site) and kill the catch-all.

Re:No

[Neon Spiral Injector]

You should not generate the bounce, a 5xx responce to an SMTP command is all your server should do. If it is a real mail server talking to yours it will generate the bounce for the user that is relaying through it (hopefully including the text of your 5xx reply).

Why the forging in the first place?

[mabu]

I believe the main reason why spammers are forging in the first place is to taint relay blacklists. RBLs hurt spammers more than anything else. When they forge from addresses they cause legitimate relays to be spammed by other legitimate relays and this in turn may prompt some relays to blacklist legitimate smtp servers and tarnish the effectiveness of RBLs. However, most admins are now wise to this and differentiate between the different types of traffic.

If you run any mail server for a reasonable amount of time, until the feds decide to get off their lazy asses and prosecute these criminals, you're going to run into this problem. It usually passes after a few days. If I run into it, I will sometimes change the MX record of the offending domain to 127.0.0.1 temporarily. And rule number one is avoid *@domain.com mail mappings...

Re:SPF!

[qbwiz]

Right, but that post was saying that he thought that spammers would avoid forging a domain with SPF on it, because it would be more likely that their mail would be rejected. Therefore, if you add SPF to your domain, you shouldn't get as many bounces, as spammers won't want to forge that as the sender.

Re:Why the forging in the first place?

[Robotech_Master]

In my experience, some spammers will also forge the 'from' address to be the address of the intended recipient of the spam, and then send it to an address they know will bounce (i.e. with an autoresponder) to try to get past spam filters or something.

Simple, check the Received: envelope headers

[Anonymous Coward]

You start by rejecting outright email for non-existant email addresses. That gets rid of all bounces that come from addresses the spammers have made up. Then you look at the Received headers of the email that you supposedly sent and validate that it did indeed come from your IP and the header is of the form that your MTA generates. If not, somebody was impersonating you and you reject the bounce. See Stopping Backscatter Email [postfix.org].

Don't use a catch-all

[Kelson]

The problem of invalid bounces drops dramatically if you set up your incoming server so that invalid addressees are rejected with a "User unknown" note at SMTP time. If you're using Sendmail with a virtual user table, this is as easy as adding the following at the end of the file

@example.com error:nouser 550 5.1.1 User unknown

It's important to do this on the server that accepts mail from the outside. If you have a setup with an antispam/virus gateway that then relays to an internal server, you need to make the gateway aware of the valid/invalid addresses.

By rejecting invalid senders in the SMTP transaction, you only get bounces from the few messages that forged an actual sender. In my experience, the addresses tend to look like [e-mail], so most of the bounces will just disappear into the ether(net).

Postfix Backscatter HOWTO

[alanxyzzy]

Knowing that a common term for this is "backscatter" may help you search for other hints and tips.

There is a Postfix backscatter HOWTO at http://www.postfix.org/BACKSCATTER_README.html [postfix.org]

Re:SPF somewhat effective

[Albanach]

The DNS system is heavily loaded worldwide now

I'm not sure what you mean by this - surely with a properly caching nameserver, you add almost no additional load to the root nameservers by performing SPF lookups as the query never goes near them? Your own DNS servers might be heavily loaded - in which case you should can additional ones or pay for someone else to provide DNS service. DNS scales easily so that shouldn't be an issue.

A DNS request is tiny compared to bouncing about bits of mail - if you can reject the message before even processing the body thanks to SPF you significantly reduce bandwidth consumption, much more than that spent on a DNS lookup, especially now there are so many image based spams floating about.

Re:Backup MX is to blame for some of this bouncing

[GreggBz]

Your right. I work for a smallish ISP and notice that spam-bots usually prefer the backup MX record.

For smaller domains and people with fewer resources having one MX record is impractical. For larger systems, like say an ISP, their is typically only one MX record, which really points to a virtual server that exists in a Foundry switch or some such. This is then load balanced round-robin style to a group of identically configured servers, preferably that are geographically distributed. This is a little more straight forward then the ring of servers, but has it's own issues.

The one headache that I have with this set up is the tedious log searches that you end up doing trying to find out what happened to customer x's email, or just troubleshooting in general.

It's a pain shelling into 4 different servers and greping through each maillog. I'd like to find a solution to this.

BATV

[Patrin]

Take a look at Bounce Address Tag Validation (BATV). http://mipassoc.org/batv/index.html [mipassoc.org] There even is an implementation for EXIM. This drops spam bounces like you wouldn't believe.

Envelope Sender Signature

[mossmann]

Check out the Envelope Sender Signature technique described here:

http://howtos.linux.com/howtos/Spam-Filtering-for- MX/collateral.shtml [linux.com]

The idea is to tag outgoing messages in such a way that legitimate DSNs are distinguishable from illegitimate backscatter (which can then be discarded).

Rejecting spam bounces

[CustomDesigned]

Speaking from 2 years experiences with rejecting 11000+ spams a day, publishing SPF records helps, but not enough folks reject mail with SPF fail for it to help a lot with spam bounces. The real solution to spam bounces is to "sign" your MAIL FROM, using SRS for example. (SRS is not just good for forwarding.) Then you just reject bounces without a proper signature. After signing, your MAIL FROM would look like this:

<SRS0=WHEtL=GU==[e-mail]>

The current main benefit to SPF is that when you get an SPF PASS, you can be reasonably sure that the MAIL FROM wasn't forged. This is comforting when I get mail from online banks and vendors (that I actually use). Also, I reject not only on SPF fail, but on softfail for selected domains (e.g. ebay.com). Getting an SPF pass is a two edged sword for a spammer. I track reputation (using pygossip) for validated MAIL FROM and HELO domains. So after a few trips through the content filter, they get rejected in SMTP envelope:

2007Jan11 14:19:47 [244] Received-SPF: pass (mail.bmsi.com: domain of identity-star.com designates 209.205.201.41 as permitted sender) client_ip=209.205.201.41; envelope_from="42991_VMTA2574-alb=BMSI.COM@identit y-star.com"; helo=mx2574.identity-star.com; receiver=mail.bmsi.com; mechanism=mx; identity=mailfrom
2007Jan11 14:19:47 ham: 0, spam: 23
2007Jan11 14:19:47 ID identity-star.com:SPF reputation: -76.159416,2.209194
2007Jan11 14:19:47 [244] X-GOSSiP: 0Q1xs3S.9Tt$ySk.$6w1Mg,-76,2
2007Jan11 14:19:47 [244] rcpt to <[e-mail]> ()
2007Jan11 14:19:47 [244] REJECT: REPUTATION

Re:Rejecting spam bounces

[CustomDesigned]

I use pysrs from the pymilter [sourceforge.net] project for MAIL FROM signing. It adds a macro to sendmail, and installs a pysrs daemon as a sendmail socket map. The SRS library could be used by a python script to integrate with mutt I suppose (I always do all my filtering in the MTA - so I can't offer advice). Example code (with random spaces inserted by slashdot):

>>> srs = SRS.new(secret='boo')
>>> srs.sign('[e-mail]')
'SRS0=dqj5=GU==user@ example.com'
>>> srs.reverse('SRS0=dqj5=GU==[e-mail]')
'us [e-mail]'
>>> srs.reverse('SRS0=fake=GU==[e-mail]')
Tra ceback (most recent call last):
...
AssertionError: Invalid hash

There are also C libraries like libsrs and libsrs2.

Detecting the bogus bounces in mutt is less than optimal - because you have already received the SPAM. By checking in the MTA, you reject the bounce before SMTP DATA.

Re:SPF!

[Medieval_Gnome]

My domain (and email) is hosted with godaddy, and it was trivial to set up SPF.

Go into your hosting account, then open the control panel for the domain you want to set up SPF for.

On the page that opens up, select DNS Manager.

Scroll down to the bottom of that page, and there should be a button saying something like "Add SPF Record."

Assuming you use smtpout.secureserver.net to send your email, the defaults should work splendidly, and it should be good to go.