Agressive Anti-Spam Measures that Cause More Harm than Good
This post had a personal info. I have removed it as I think it is irrelevant to the point I’m trying to make. Let’s just call him “Rick”. A user on a domain I maintain forwarded me an email from Rick explaining why his anti-spam swallowed the email, I replied with a set of challenges to his anti-spam’s filter effectiveness, as well as question the validity of the reasons behind it. Let’s be charitable and just say he did not seem to be open to discuss the matter.
Personal manners aside, this does bring up the greater question of arbitrary spam filters (arguably the worst ill effect spam had on the Internet) and standards conformance.
The spam filter Rick used that failed my user’s email was a strict enforcement of RFC 2142. In particular, the RFC states that each and every domain on the Internet must have, among other things, a “postmaster” and an “abuse” addresses. Rick’s spam filter enforces this by connecting to the main MX for each inbound domain received, and to check whether the MTA will accept mail for “postmaster” and “abuse” @ that domain. If it will not, the email is rejected.
A while back, one of the major spam black hole providers at the time (forgot who) started black listing MTAs merely because they would send bounces for illegal email addresses, rather than reject it while in session or dumping them to /dev/null. While the collateral damage effect of both anti-spam measures can be said to be opposite, I do group them together under the “ill thought out anti-spam measures” group.
What I Don’t Like About RFC 2142
The main thing I don’t like about RFC 2142 is that it tries to encompass ALL domains, whether used for email or not. Conforming to 2142 would mean that any domain, used for any purpose whats’o ever, would have to have an SMTP configuration as well. It is not possible to follow this RFC (which does not specify conformance levels in a standard way – using the “must” “should” and “may” keywords as is the norm) without having an SMTP server for each and every domain used. It is a small relief (and one irrelevant to Rick’s anti-spam filter – see later on) that the RFC allows not defining these emails for all sub-domains.
There is one mitigating factor at work here. The status of the RFC is “Proposed standard”. Unfortunately, this is a very flexible definition. On the one hand, many de-facto standards are only defined with RFCs that carry this status (with SNMPv2c and HTML v4 being two noteable examples). On the other, these are not standards. Their enforcability is due to their common place adoption, rather than a formal process running to its completion.
What is No Bounce Enforcement
When an email is sent over SMTP, the protocol attempts to guarantee a “delivery or NACK” policy. In other words, the email will either reach its destination, or you will receive a notification that it hasn’t. People have come to rely on this feature, to the extent that an Israeli judge has even deemed a supeana served over email as valid.
When something goes wrong, there are two things a MTA may do. The first is to notify the upsream MTA, while it is receiving the email, that this email will not be delivered. This is done by replying with an error code (either permanant or temporary error) while the email is being processed. In effect, the MTA refuses to accept the email, and it is up to the upstream MTA to handle the NACK. The other type of error is when the MTA did receive the email, but then found out that it cannot handle it. In such a case, the MTA sends out a “bounce email”. This email, usually titled “bounce action notification”, details the email that has bounced and explains why it was bounced.
The “no bounce notification” movement (of which I haven’t heard lately, thankfully) said that sending bounces is wrong. They had a fairly good reason for this statement. When a spammer forges my email address (or even merely my domain) for their spam, some of the emails spammed are invalid. If the MTA returns a permenant error, then the RFC states that it is the spammer that needs to send the bounce. Most spammers don’t bother (thank goodness). On the other hand, if the MTA accepts the spam, and then bounces it, I (the one who’s email was forged) am going to get the bounce. Since spammers usually send with extremely wide circulation, this means my email is going to be flooded with bounces. This is referred to as “collateral damage”. The “no bounces” movement aimed at solving this collateral damage, by forcing MTA operators to switch to the first mode – never accepting the spam to begin with.
What I Don’t Like About 2142 as a Spam Filter
In his last word reply, Rick defined the filter (and following email) as “a curtsy” – he is letting me know that there is something wrong with my domains configuration. The way I see it, there is nothing courteous about having your emails bounce (typically, with no possibility of appeal, as any appeal you send will come from the same domain that is forbidden to send email until the “problem” is fixed). In a way, this means that the very purpose that RFC 2142 was meant to create, of creating an easy path to contact the person in charge in case of a problem, is not served. I find it somewhat hypocritical when, in the name of a principle, that very principle is violated.
Worse, the filter is ineffective against spam. Even if every host in the world employs it, all that will happen is that spammers start forging their “from” address from domains that employ 2142 compatible email addresses. The filter does nothing to actually tag spam emails.
Worse still, merely deploying this filter on a large scale creates collateral damage. If my domain is forged by a spammer, the mere act of them sending out their spam will cause each receiving MTA that has this filter to contact my MTA. Effectively, this turned an unpleasent spam spoofing problem into an even less pleasent DDoS problem. Maybe that would have been worth it had the filter had any actual use, but I really doubt that is the case.
Another problem, relatively minor in relation to the others I mentioned, is that this filtering negate the possibility, clearly allowed by 2142, to not apply the RFC to sub-domains. The filter requires all inbound email to conform, even if it arrives from a clear sub-domain. Like I said, this is the least of the problems.
What I Don’t Like About Enforcing No Bounces as a Spam Filter
The no bounces demand is even more problematic. While I sympathize with the aims driving it, having been on the wrong end of the bounce flood more than once, what they require is an impossibility. There are many many many cases in which it is simply impossible not to accpet invalid emails. This may be due to the resources required in order to figure out whether the email is wanted or not, due to backup MTAs being in use, which do not have a live list of valid email addresses, due to an ISP MTA forwarder being used or merely because the site happens to use qmail, which does not support this. Whatever the reason, demanding that emails be rejected before being accepted is one that the Internet cannot live up to.
The “no bounces” movement had an answer to that claim as well. They said: “simply discard”. This answer I find particularly offensive. This answer effectively breaks the trust that the users have with SMTP. Just think of the following conversation: “Why did you not answer my email?” “I didn’t get it.” “But I didn’t see a bounce message!”. These users don’t even understand that it is a MTA problem that they are seeing. There is no indication as to what is wrong.
What I Don’t Like About Both Filters
In one word – coercion. The 2142 enforcement at least takes an externally defined standard to go by, though it is not a binding one. It might not have been so bad in itself. After all, we used to encourage MTAs to relay, and yet today we frown upon open relays and even refuse emails from them (through the use of black lists). Obviously, spam forces us to take things that used to be allowed and disallow them, as part of our fighting of it. The problem with this particular move is that while it suggests more vulnerability at the MTA side (see the “security considerations”, section 9, in the RFC), as a spam fighting tool it is all but useless.
The no bounce movement made a one-sided move that had no technical merit (and is, infact, an impossibility for some perfectly legitimate configurations) and suggested that anyone that does not follow is as bad as a spammer. The only thing one can say for the movement is that they do, in fact, advocate a more responsible MTA behavior which actually has an advantage over non-conformance. Maybe the movement could have picked up more followers had it been universally possible. Unfortunately, it is not.
The bottom line is that both filters are a mean to bully MTA operators into compliance with an arbitrary definition, not backed by the proper discussion that usually accompanies such rule changes. It took the Internet several years to come to the conclusion that open relays are a bad idea, and the matter had a lot of time for people to object. Rick seems to think that a Darwanistic process will eventually make me see the light. It is, of course, possible he is right. I definitely think that a Darwanstic process will make one of us see the light.