- Traditional auto-responders
- Misdirected bounces
- Challenge/response spam filtering
- Why not allow bounces?
- Mitigation techniques?
Lately, people find their automatic responses are being reported as spam or blocked. These "auto-responders" respond indiscriminately to forged and legitimate email. Spam and virus messages are almost invariably forged so as to appear to be "from" an unrelated third party. When an auto-responder receives one of these forged messages, they in turn send misdirected mail. Because of this, they become spam sources themselves and are the subject of blockades. There are several types of email, detailed below, which we refer to generally as "autoresponders".
- Problem: The traditional auto-responder
- Description: A message is sent in response to inbound email informing the purported sender that you are on vacation, listing FAQs or otherwise sending a standard message - all too often, to the wrong person.
Solution: Do not use these systems. Inform your normal corespondents of your absence before you depart. Or let a co-worker answer your email in your absence. Publish FAQ information on a web-site. If you wish to dispense information via email, it's easy to reject a message while referring the sender to a FAQ web-page. Using sendmail, this is done in the access.db table like so:
to:email@example.com 550 Old address no longer valid, please see: http://www.example.com/NewAddressInfo.html
- Problem: Misdirected bounces
- Description: When a mail server accepts a message and later decides that it can't deliver the message, it is required to send back a bounce email to the sender of the original message. These bounce emails are often misdirected.
Solution: Upgrade and/or configure your mail server software so that this situation is never encountered. Configure your software to either reject messages during delivery or accept them permanently. Do not let your software make choices about delivery after it has accepted a message. If you must accept delivery before you know the status of a message, then file it internally - do not send, forward or bounce it outside your organization. The errant message can be placed in a special folder or routed to your postmaster.
Avoid offloading your filtering task onto random third parties. You must filter your own mail, not ask others to do it for you.
- Qmail is one popular mail exchanger which suffers from this problem by default. If you use qmail, please apply a patch: spamcontrol or
There is also an experimental patch for qmail which allows you to send bounces, but isolate them on a different IP address (so that spamcop can block them without blocking other mail): Richard Lyons' BOUNCEQUEUE patch
John Simpson has provided a set of qmail patches that enjoy wide distribution. Check out qmail validrcptto.cdb Patch
PZInternet.com reports chkuser is a very good qmail patch to avoid misdirected bounces - very easy to install too! http://www.interazioni.it/opensource/chkuser/
For users of qmail-toasters, check out the simscan patch
- Microsoft Exchange:
- Microsoft has updates available for their Exchange Servers to control whether the Internet Mail Service suppresses or delivers non-delivery reports:
Microsoft Exchange Server 5.5
Microsoft Exchange Server 2000 and 2003
- If you know or find other tips for fixing this problem in other popular software, please Post it to the forum and we will be happy to add it to this FAQ.
It is important to prevent a global plague of misdirected bounces - already many people are filtering out *all* bounces because they can't sort the misdirected ones from the real ones. This further degrades the reliability of email.
- Challenge/response spam filtering
- Description: This "selfish" method of spam filtering replies to all email with a "challenge" - a message only a living person can (theoretically) respond to. There are several problems with this method which have been well known for many years.
- Does not scale: If everyone used this method, nobody would ever get any mail.
- Annoying: Many users refuse to reply to the challenge emails, don't know what they are or don't trust them.
- Ineffective: Because of confusion about these emails, many of them are confirmed by people who did not trigger them. This results in the original malicious email being delivered.
- Selfish: This is the problem we are mainly concerned with. By using challenge/response filtering, you are asking innumerable third parties to receive your challenge emails just so that a relatively few legitimate ones get through to the intended recipient.
Solution: Do not use challenge/response filtering. Although it may stop most unwanted email for the person shielded by it, it generates more unwanted email for others.
Since more and more sites will rightly block these challenge emails, you can never be sure they will reach their target even when they are not misdirected themselves. So these systems will lose legitimate mail in an attempt to stop unwanted mail.
In general, all these types of autoresponders are sending mail to people who have had their email addresses used without their permission. The recipients of these messages rightly consider them unsolicited. In extreme cases, sites have been "bounce-bombed" with misdirected mail, preventing them from receiving legitimate mail.
Q: Why not allow bounces? They are required by RFC822!
A: Originally, SpamCop made attempts to forgive misdirected bounce messages - to reject them as evidence of spam. However, there are two factors conspiring to force us to rescind this policy. First of course, is that these misdirected messages *are* spam as we define it (Unsolicited Bulk Mail). They are objectionable to recipients and can even cause denial of service to innocent third parties. Users of our blocking service want us to stop them.
Second is that spammers have taken advantage of this policy, disguising their spam as bounce messages in order to avoid SpamCop. If we did not change the policy, this would become a highly popular way to "beat SpamCop".
Although bounces are required, it is possible to avoid the situation under which they are required (see above). So they aren't really required unless you have already 'painted yourself into a corner.'
Q: Is there any way to mitigate the problem without entirely disabling auto-responses?
A: Yes, due to recent attempts to "fix" the problem of forged email, there is. If you must continue to use an auto-responder, you can greatly increase it's accuracy (and perhaps avoid being blocked). Using this method, the auto-responder may not always respond to every legitimate email. It will respond to the vast majority, and it will send much less (although not zero) misdirected mail.
To do this, your responder should use SPF and/or Domain Keys to verify the authenticity of the message being replied to. The details of these methods are beyond the scope of this FAQ, but here are a few notes about the proper implementation of SPF for auto-responders:
- If the SPF record is too broad, use only the explicitly listed IP ranges or mx fields.
- If the sending domain lacks an SPF record, accept mail only from the IP addresses listed as the domain's MXs (inbound mailservers). Large domains have mostly adopted SPF already. Smaller domains are likely to use the same servers for inbound and outbound mail.
SPF is much more widely used, but Domain Keys is more reliable and error-proof. Most senders who use Domain Keys also use SPF (there is no disadvantage to using both). In short, implementing SPF checking will give you the most benefit with the least effort.
Q: If I disable delayed bounces, won't I be vulnerable to a directory harvest attack?
A: Yes. If you do nothing else to prevent harvest attacks, spammers will be able to more easily try many possible usernames to check which ones you accept mail for. There are other, better ways to mitigate this problem beyond the scope of this document (tarpitting). Sending delayed bounces to all and sundry is not a good way to prevent directory harvesting - it harms others and does not really prevent harvesting.