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
Either call the EPA and get them to declare a superfund site in your compost pile, or use it as fuel in home-brew nuclear fusion experiments. The end results will likely be simmilar. I'm told its also a good substitute for bathroom grout.
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.
I get about 50-75 bouncebacks a day on my domain, although I believe some of them at least are "false bouncebacks" from spammers, the idea being im more likely to read a bounceback than a spam.
SURELY NOT!!!!!
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
Two big guys and a baseball bat
Oh, you mean SPAM, I read that as spammer...
how long until
for refference, the point of Joe Jobbing some one is to ruin their reputation.
General spoofing is just there to hide their tracks, and make it more likely that the mail will be delivered.
Do Or Do Not, There Is No Spoon, There Is Only Zuul. Everything in the above post is probably opinion.
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.
Also usefull as bait for carp. They seem to really like, and fight to get on the hook.
Cubed with diced potatoes and onions. Fry in a bit of butter. When it's nearly done toss in a few cubes of Velveeta. As soon as the "cheese" melts toss it on a plate and enjoy! I prefer some pickled jalapeños with mine and a nice cold Diet Pepsi.
*drool*
The Master (Angelo Rossitto) in Mad Max Beyond Thunderdome, "Not shit, energy!"
I've been hit by the same problem (and eventually gave up on my own domain and decided to let GMail deal with it) so I sympathize, but this simply isn't true. Bounces are much more effective.
What I'm listening to now on Pandora...
I own a handful of domains, and I have little if any problem setting up autoreject for invalid email addresses. The only problem I can't easily handle is when a valid email account is used by a spammer. I think you should strongly consider changing your domain host if you've got these issues in 2007.
-BA
If I haven't eaten it...
:P
[Please insert wow ur fat joke here.]
I put the spam into the trash, tie the top of the trash bag, and throw trash bag into the dumpster outside. I don't know what the fuss is about disposing spam. Spam is spam.
But doesn't follow the spec and reject on fail
So I'm not sure what value that is, and I'm not sure if google forms a bias against spam from my domain, even though it's verifiable that the spam is a forgery and that my domain had nothing to do about it.
Other lameness are domains like hotmail.com and aol.com which publish records which indicate you shouldn't reject mail claiming to be from them from servers that they don't control. (soft-fail or neutral results).
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
You'll need a dog. I simply feed him my excess cans of spam. If you're dealing with spam e-mail, then simply print out the spam, and use it to paper train the dog after it's gorged on Spiced HAM.
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.
- 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 that smalltime is accepting cans of spam to fuel their "Find-the-Spam" game. They're capitolizing on the idea that this is obviously something that only a hobo would eat, and turning it into a fun game.
PS. - For added entertainment, try the text version!
I have an old FreeBSD mailserver that uses Exim. You should set up an intermediate domain/DNS system that can destroy the wrong usage of your name outgoing through the system. Then, I reccomend looking through Perl scripts, because though one is not definative, try, try again and you might partially suceed. Also, be sure to do security and firewall updates as mine was hacked... I don't know everything that you've tryed, but if you haven't done all of those thouroughly, then you're screwed:) It'll never be perfect, though.
"Okay, I'd like to send you some more information and need to verify your e-mail address."
"Alright"
"Is it jay ewe inn kay at blah blah blah dot com?"
"uhh...Yep, that's me. John Unk."
Only trusted vendors get real e-mail addresses here. I don't even get spam on my home e-mail. Absolutely none, after three years of having the same e-mail.
120 characters for a sig? That's bloody useless.
Simple: Burn it onto DVD-minus-R. Then nobody will ever be able to read it ever again!
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).
...are MAILER_DAEMONs and their friends who are so stupid they bounce instead of reject likely to be intelligent enough to check an SPF record before sending a bounce message to someone who obviously didn't send it?
I too get loads of spam bounces sent to non-existent addresses "from" (random string)@(my domain), not to mention "please validate your message" challenges and autoreplies; my approach is one enormous blacklist that just autodeletes any messages from postmaster, mailer_daemon etc that aren't to my sending address, which works until some stupid postmaster decides to call himself Mail Delivery System or Mail Delivery Subsystem and so on, plus non-English versions, and the numer of variants on "undelivered mail" is equally astonishing - that, Mail delivery failed, delivery status notification, returned mail, delivery failure, mail system error, undeliverable, cannot be delivered, foreign variants...
It should be "Proper Ways to Dispose of Spammers?"
I propose the firing squad or hanging. By their balls (if they have any).
Maybe evisceration?
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. .*crowell\d\d@mydomain.com. That way if some spammer is just trying to guess an address like dave@mydomain.com, it's not going to work. If I start getting a pile of spam to, say, the slashdotcrowell07 address, I just stop accepting mail at that address. The year is because most addresses eventually start getting more and more spam. So right now if someone sends mail to me at an 07 address, it goes to my inbox; if they send it to 06, it goes in a special box so I'll realize I need to give them the new one; if they send it to 05, it gets marked as probable spam, and I won't look at it until I get around to looking through my spam box; 04 goes straight to the bitbucket.
I could probably get away with doing a catch-all on a subdomain
What I do is I use e-mail addresses that look sort of like this: slashdotcrowell07@mydomain.com. On the front is the name of the business, so if I get mail at that address, I know it was because I gave it to them. Next is my name. Next is the last two digits of the year. In my mail filters, I reject anything that isn't of the form
Find free books.
There is a Postfix backscatter HOWTO at http://www.postfix.org/BACKSCATTER_README.html
You add an encrypted header to all outgoing emails which says "Yes, this email came from this server." Then, when you receive a bounce message, you check for the key. If it has it and its correct, it gets through, and if it doesn't, it gets rejected. This stops ALL normal bounces that result from spammers, and the only thing you do get are auto-responders which aren't actual bounces.
r e-authbounce.txt
Here's the Exim howto http://psg.com/~brian/software/authbounce/configu
Can someone tell me the differences in terms of when each happens, and what happens on the other end between a bounce and a reject? I _think_ I understand the difference, but I'm not certain.
My understanding is that a reject is sent by the receiving SMTP server before it's accepted the mail. I.e. server a->server b, server a says mail is to: bill@serverB_Domain.com from: john@spoofedaddress.com. Server B can then accept the mail, or reject it (with various different codes for each). If B accepts it, it's server B's responsibility to handle it. If it rejects it, it's server A's responsibility to handle it.
So, (if I understand this right) the problem the submitter is getting at is that server B accepts the mail, but then later bounces it. (Because a spammer is obviously not going to bother bouncing the mail when it's rejected).
Why would Server B accept mail from Server A if it's only later going to bounce it? I can think of at least once case (and one I have experience with). If Server B is acting as a relay host for Server C, then it's difficult (but not impossible) for Server B to know if Server C will accept or reject the mail. So Server B just accepts all mail, but later has to bounce some of it when Server C rejects the mail.
I've dealt with this problem, and only recently fixed it when I rebuilt the relay server. I use Postfix, which now supports validating recipient addresses for relay hosts. Essentially what happens (in terms of my little scenario) is before Server B accepts a message, it connects to server C and sends a test message addressed to the recipient. If server C rejects the message, Server B rejects the message from Server A. (Yah, it's a little more complicated than that and involves caching, but that's the general idea). The previous version I was using didn't support this feature, so I wound up with a lot of bounce messages going out for spam addressed to invalid addresses.
The other scenario I can think of is that Server B later figures out that the mail is spam. But why in the world would you decide to bounce the mail at this point, since it's very likely the return address is fake, will never accept mail, etc? Either throw the mail away entirely and forget about the whole ugly mess, flag the mail as spam and delivery it to its destination, or squirrel it away somewhere just in case someone really really needs to see it (like it's a false positive).
What I do is flag the mail and stick it in the users spam folder. Then no one complains about not getting mail.
AccountKiller
I've been dealing with this a lot recently -- I just wrote up a short howto doc over on my blog yesterday, in fact, using Postfix on the MX to catch most of the bounces, with SpamAssassin to filter out the remainder.
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:
Gmail sends the mail as coming from your domain, but the sender header is listed as coming from your gmail address. Because of this, the SPF testers seem to care about Gmail's SPF check, not your domain's. For example, send an email to the address given by this site:
http://senderid.espcoalition.org/
For example, in my case, I see:
In the headers send in the email, I see:
For a while I actually had my domain's SPF records set to deny all. Worked out well enough, since Gmail sent all of my domain's email back then.
I assume you're using a catch-all email account, like I do. I get about 100 SPAMs/bounces a day. Here are techniques that I use:
No, I will not work for your startup
Eaaasssyyy. Just set your MX record to 127.0.0.1!
You will never get a bounce.
hey there
gmail will be correctly set as the sender so SPF records will be correct
the problem is other domains that do not...
basically we need DKIM that signs the message so that when we get somthing back we examin the sig and if it does not have our DKIM we reject it
simple we need both SPF and DKIM in the real world