Forum Moderators: open
Recently I read that so many return-paths are spoofed that it's really a waste of time to bounce spam. That makes sense, but my own experience indicates that whilst this may sometimes be the case, bouncing spam has got me off some lists.
What does everyone else do? Is there a consensus as to whether we should or should not bounce spam?
In some cases you are simply signalling to SPAMmers that they have some sort of valid (or near-valid) address. Dump SPAM, don't bounce it, however tempting.
In the case of faked From: addresses you are probably hurting an innocent 3rd party (eg me) and their mail machine, not a SPAMmer at all.
Rgds
Damon
As a recipient of a fair amount of bounced SPAM using my domains in faked From: headers I can tell you that it IS detrimental, especially when accompanied by anguished-but-dim calls from all over Europe asking me to stop doing whatever scam it is that I have no idea about being done in my name with my email address.
Drop SPAM in the bit bucket: don't attempt to retaliate, because if *anyone* is hurt it won't be a SPAMmer.
Rgds
Damon
In some cases you are simply signalling to SPAMmers that they have some sort of valid (or near-valid) address.
the whole point of bouncing a message is to send a "not a valid address" message. If the originating e-mail address was valid (and the SPAMmer's), not getting a bounced message is an indication of a valid e-mail address, which almost guarantees your e-mail will be listed as a verified address and sold to yet more SPAM lists.
That's been my rationale behind bouncing the spam.
If, as a number of replies have advised, simply delete spam instead of bouncing it, what can we do to alleviate spam? Surely my inbox will start filling up with greater number of spam as my email address stops resulting in bounced emails?
I have seen some improvements with this approach in the SPAM rate to my accounts. The more intelligent spam software seems to recognize the 4xx en 5xx error codes and eventually removes my email addresses from the list.
Rejecting with an SMTP errorcode instead of bouncing to the (spoofed) sending address is also the preferred method mentioned in RFC2505 [ietf.org], which gives recommendation how to deal with email spam.
Rejecting based on SPAM content is only the last in my chain of protection.
Rejecting instead of bouncing also has the advantage that your email server is not overloaded. A simple DNS lookup rejects the largest part of the incomming SPAM before the message body is uploaded. The resource intensive content filter techniques of Spamassassin are therefore only used for a small fraction of the incomming messages.
I prefer sending a 4xx temporary error. Most SPAM software stops trying after one or two retries, but legitimate SMTP servers will try for one day or longer when they receive a 4xx temporary error. This gives me the ability to add a legitimate SMTP server to my whitelist in case it was accidentaly blocked.
In most cases, no. Pretty much all spam uses fake sender addresses nowadays, so that bouncing does nothing but generate yet another unwanted message to an otherwise uninvolved third party.
If everybody bounced spam, then that would indeed double the number of unwanted messages out there. Just because most other people don't is no excuse.
the whole point of bouncing a message is to send a "not a valid address" message.
This is only the case when your SMTP server refuses to accept the message in the first place, which isn't technically bouncing. As soon as your system has accepted the message, the only correct action is to drop it silently. Sending a post-SMTP bounce doesn't say "invalid address", it says "filtered address where it might be worth trying to trick the filter". No spammer will stop sending spam to an address returning such bounces.
Am I correct in thinking that it's only possible to check the To: address, From: address and sender IP when deciding whether to reject the email? If you want to check the content you must accept the email and then bounce it if required?
I see a lot of spam emails where the sender email address is different from the return-path address. OK so the sender address is fake, as all probably agree on that point. But could the return-path pick up on bounced and remove them from spam lists? If not, why not just use the faked sender address as the return-path?
[edited by: barns101 at 10:48 pm (utc) on Sep. 13, 2006]
As a recipient of a fair amount of bounced SPAM using my domains in faked From: headers I can tell you that it IS detrimental, especially when accompanied by anguished-but-dim calls from all over Europe asking me to stop doing whatever scam it is that I have no idea about being done in my name with my email address.
DamonHD, have you tried to setup SPF records? I have fairly restrictive SPF records in place for most of my domains and judging on the small number of bounces I receive compared to a year ago I assume that it helps somewhere in the process. Maybe spammers avoid From: addresses from domains with a strict SPF record, or maybe bounces to these domains are not sent by some email software because they can determine from the SPF record and sending IP address that the From: address was spoofed.
For example: I send emails from only a few domains. The other domains are either sleeping, or setup as receive only. For these non-sending domains I use the SPF record "v=spf1 -all" which tells that I never ever send emails from these domains.
Am I correct in thinking that it's only possible to check the To: address, From: address and sender IP when deciding whether to reject the email? If you want to check the content you must accept the email and then bounce it if required?
In most situations this is the case. The SMTP standard allows you to reject a message during the whole process of accepting it, also when the message body is comming in. Unfortunately most mail server software is not flexible enough to filter during the data acceptance session. They can only filter during the connection setup, based on IP, From and To, or afterwards when the connection is closed and the message is already in the local delivery queue.
This is also in my setup. Spamassassin is called when the message is totally accepted and in the delivery queue waiting for delivery to the mailbox. My filtering at the door already blocks so many incomming mails that I have no problem with that. The filtering based on IP and non-existent To: addresses stops at least 90% if the incomming messages in my situation. The remaining 10% is just a handful and not a real waste of time. But I am talking of 200 SPAM messages per day of which a maximum of 20 reach Spamassassin. These are luxery figures compared to the flood of SPAM others have to process. In those cases looking for an MTA which is capable to do real-time content filtering while the SMTP connection is still alive and the message has not been received totally yet can be a real advantage.
Just as a reminder, I'm asking specifically about bouncing after email has been delivered, as I don't currently run my own email server (I just have POP3 mailboxes).
Yes, the 10,000+ SPAM attempts per day is inspite of my having SPF records!
Actually, for a while I had to have my main mail server behind a custom-written reverse SMTP proxy that, in addition to the steps you listed, greylisted for a while any incoming connection from a new SMTP server that I had not seen before/recently, and tarpitted egregious SPAMmers too.
The greylisting was to allow time for a newly-compromised machine (if that is what it was) to find its way into a DNS BL.
The tarpitting gave me a nice warm feeling inside, and is about the only legitimate way to respond to SPAMmers and marginally reduce their ability to send SPAM elsewhere.
Currently, after an upgrade to Solaris 10, I am finding sendmail with just two filtering rules (a DNS BL and checking for reverse lookup) to be fairly tolerable without my reverse proxy.
Rgds
Damon
Nowadays most regular SMTP servers are protected against abuse and spammers have moved their activities to infected user PCs. These infected PCs have often no reverse DNS record, or their DNS record easily identifies that they are not a regular mail server. I block for example all SMTP requests from dynamic.*.isp.tld and dialup.*.isp.tld for some larger ISPs. The chances that a genuine SMTP server is located behind a dynamic IP address or dialup connection are very small.
I also highly dislike receiving the bounce messages that other people send after receiving spam purporting to be from my domain...