Slashdot Mirror
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?
regardless of whether it comes out the back port or the front(both are equally likely).
Monstar L
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.
Welcome to my hell. I've had this happen to 8 of my domains over the last couple of years, typical spam runs of 30k at a time, based on all of the 'bounce back' messages that tell me 'my' mail is spam, or worse "go F** yourself, spammer" crud. SPF might fix this, but only if it was mandatory and ALL ISPs blocked non-commercial email servers (DO NOT WANT the latter to occur).
Good Luck.
Toil is Stupid. Don't be Stupid.
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 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.
.. 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.
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]
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..
XenoPhage
Technological Musings
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.
It's great to set up your mail server to reject the mail up front. But many spammers know people are doing this, so they connect to backup MX, often the one with least priority. From what I've read, that's how spammers' mail blasting programs are written these days.
Are you running your own backup MX? Probably not. It's often a generic spooler your ISP lets you use for convenience. Even if you do, does your backup MX have all your rules in place, so it knows what to reject? No, I bet not. So this backup server accepts the mail without question, then passes it to the primary, and then it gets bounced.
We need to either have a way to give our backup MX our rulesets (which the people who run the backup servers understandably won't like), allow backup and primaries to just silently discard (which legitimate senders and receivers won't like), or, quite possibly, stop using backup MX entirely, and then if the primary goes down, the originating mail servers should do their normal pattern of retrying for 5 days, or whatever.
Large companies who need 100% instant availability of mail shouldn't be using backup MX anyway, (I've seen backup MX servers configured to hand off to primary hourly or even daily, not to mention those that hold until the primary asks for the mail) they should be using a ring of servers sharing primary preference. I'd expect the ruleset to be identical across the ring, thus allowing for instant rejection all the time.
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).
- Don't use catch-all addresses. Normally blowback is not addressed to a valid user. This was not an option for me, but it may be for you.
- Reject invalid bounce messages. Any message coming with an empty envelope sender to an address that has never sent mail on my system is considered invalid and rejected during SMTP with a message stating why. This is what I chose.
The reason for my choice is that it consumes minimal resources (all that's required to reject a message is one SQL query against a small, in-memory table), informs the bouncer of the problem, and eliminates 99.99% of blowback (some incorrectly-configured MTAs produce bounce messages that don't have empty envelope senders... I get like one of those per month).And I second your pleading: Please, please, please, mail admins, please reject email during SMTP instead of producing bounce messages! Please!
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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...
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.
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 ashawuiefgfyig@example.com, so most of the bounces will just disappear into the ether(net).
There is a Postfix backscatter HOWTO at http://www.postfix.org/BACKSCATTER_README.html
Take a look at Bounce Address Tag Validation (BATV). http://mipassoc.org/batv/index.html There even is an implementation for EXIM. This drops spam bounces like you wouldn't believe.
Check out the Envelope Sender Signature technique described here:
- MX/collateral.shtml
http://howtos.linux.com/howtos/Spam-Filtering-for
The idea is to tag outgoing messages in such a way that legitimate DSNs are distinguishable from illegitimate backscatter (which can then be discarded).
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:
Spam is spam. I don't care if it was relayed by using the victim address in 'rcpt to:' (traditional spamming) or 'mail from:' (blowback spamming). So you stuck three lines of text above it then relayed it on to the victim. Good job, by bouncing instead of rejecting you're an open relay. You even add some additional bayesian slaying text to the top. That's how I see it.
It's really not that difficult to configure your mail systems to reject instead of accept then bounce. I see this as becoming manditory, similar to how it used to be ok to have an open relay, then over time it became a sin.