Bounce Back & Backscatter Spam: Who Stole My Email Address?
So, you’re minding your own business, going about your daily tasks, checking your email, and suddenly your INBOX is flooded with a series of non-delivery reports (aka NDRs or bounce messages). But wait just a minute, you didn’t send these. How did this happen? Did someone steal your email address? How is that possible?
What has most likely happened here is that you’ve fallen victim to “backscatter“, or as it’s commonly known, bounce-back spam. As spam-detection techniques have evolved and become more accurate, the spammers have been forced to devise increasingly complicated and devious methods of getting their messages delivered. For example: email forgery.
What is involved in email forgery?
The way that email delivery is supposed to work is (more details, see: how email works):
- You connect to your mail server and upload your message (i.e. from an email program like Outlook or from WebMail)
- Your mail server then connects to each recipient’s mail server and delivers it, telling the recipient server who the message is to and who it is from
- Your recipient retrieves the message from their mail server (using POP, IMAP, WebMail, or some other means)
Now, spam in general often is sent like this: A spammer pretends to be a mail server and skips step one. Instead s/he connects directly to the recipient’s inbound mail server and pretends to be sending perfectly valid email messages. This includes telling the recipient server who the message is to and from. The spammer hopes that the recipient server accepts the message, it makes it past any email filters, and gets delivered to the recipient’s INBOX. If it does … the infiltration was a success.
In order to avoid spam filters, spammers will often forge the address from which the spam appears to come. In basic email transactions, there is no way to verify if the spammer is authorized to send email purporting to be from any particular address, so the recipient email server can’t say “Hey …. that’s not your email address“.
As such, it is incredibly easy for a spammer to use your email address and other addresses at your domain as the forged sender addresses in a spam email messages. Spammers use forged sender addresses so that:
- Blocking specific sender email address has little effect on spam as the spammers use huge numbers of different email addresses as the senders, changing them all the time.
- Using addresses in real domains makes the spam look more legitimate
- If the spammer can send email forged to be from someone that the recipient trusts or that is be on the recipient’s allow list (such as the recipient’s own email address or other addresses in the same domain), then the spam is more likely to successfully arrive in the recipient’s INBOX.
Now, sometimes this forgery is enough for spammers to hit their targets — the messages arrive in a mailbox, and they’ve spammed someone.
If, however, the address being spammed doesn’t exist, the recipient’s mail server will generate a delivery failure message. Often times this “user-doesn’t-exist” message is given during “step 2″ and the spammer gets it; however many mail servers (especially spam filtering services) will accept the message first and later determine if it is to a valid recipient or not, sending an email message back to the sender to report the failure at that time. Spammers quickly realized that, due to this behavior of sending a non-delivery report “later”, they could trick the recipient’s mail processing servers into sending spam. E.g., if the message cannot be delivered to the intended recipient, a bounce back (a.k.a. backscatter) message is sent back to the (forged) sender’s address — e.g. your email address.
- It is trivial for a spammer (or anyone else) to send an email message purporting to be from you or from anyone at your domain.
- If a message that is apparently from you “bounces”, then the bounced message will be sent to YOU.
Catch All Email Aliases
Another common issue is the use of “catch-all email aliases”. These determine how messages that don’t find a valid recipient are handled. When a “catch all” is enabled, rather than bouncing a message that is not to a valid address, the recipient’s email server will (often) send these messages to a main (administrative) email account or some other specific actual recipient. This can be a great tool, especially during migrations, helping to ensure that no email gets lost while user accounts are being created. It also used to be a good way to ensure that you do not lose email because of typos on the sender’s part.
However, leaving the catch-all email alias on and forgetting about it opens up an infinite range of valid target addresses for spammers. Not only can spammers send spam to any of these addresses directly, but they can forge email to be from any of these addresses. As spammers tend to actively use addresses that they find to be valid, having a vast pool of possible valid addresses has the effect of greatly magnifying the amount of spam and backscatter that you receive.
Again, spammers know this and rely on this. Do yourself a favor — create all email addresses (like sales@, info@, etc) that you need specifically, and turn that catch-all off!
What Can You Do To Protect Yourself?
There are several steps that can be taken to mitigate backscatter and the ability of people to send email that appears to originate from your domain.
SPF – Sender Policy Framework DNS Records
One significant step is to implement the Sender Policy Framework (SPF). This is a special DNS record that you (or your email provider) can configure for your domain; it specifies exactly which servers are authorized to send messages “from your domain”. Then, when a server that supports SPF receives a message that is supposedly from you, it can check to see if the internet address (IP) or domain the message has originated from matches the ones you’ve authorized in your SPF record.This is fairly effective, but unfortunately, not a lot of servers out there check SPF, and for good reason — it does require more processing on the part of the destination server. Also, SPF is not a perfect solution; if the message is forwarded, it’s possible that SPF will no longer accurately identify the server from which the message actually originated and thus it will look like the forwarded message is from an unauthorized sending server (and thus Spam or fraud).
DKIM – DomainKeys Identified Mail
Another approach is to use DKIM (DomainKeys Identified Mail), which is a method of message validation and authentication using public-key encryption. The public key is stored in the sending domain’s DNS TXT record, while the private key is stored on the mail server from which the messages are permitted to be sent. An special email header is added to each outbound email message containing a digital signature created using this private key. If the recipient server also supports DKIM, it can retrieve the public key via DNS and use it to validate (or invalidate) the email’s digital signature, making it easier to immediately determine the authenticity of the message.
This method is very good and works well even if the message is forwarded; however, it also has imperfections. If the message is modified in transit by filters or other legitimate agents, this can make the signature in the message no longer match and the message will appear to be fraudulent.
See also LuxSci’s DKIM Generator.
Challenge/response authentication schemes have also been implemented, to arguably varying degrees of success. Essentially, any time a message is received from an unknown sender, the message is queued and an automatic reply is issued containing a challenge. The sender then has to manually address this challenge email (usually by clicking on a link and entering some text). This is generally a captcha – you’ve most likely had to pass this challenge when signing up for a newsletter or a similar automated service. An image is presented to the user that a human being can easily see the letters and numbers in, but a computer program can’t. Once the sender has verified him/herself, s/he is added to the recipient’s allowed list and any messages queued and waiting for this validation are delivered. This sounds good in theory, and is in fact very effective at combating backscatter, but it is far from perfect.
Take for example the scenario where someone using this technique sends a message to another individual also using this technique. The recipient issues a challenge back, and the original sender then issues another challenge of their own, triggering another challenge from the recipient in an endless loop (or at least no one gets the challenges).
One measure that has been taken to avoid this is to automatically add to the allow-list the address being sent to, but supposing this address is actually an alias and the response comes back from a different address, the endless loop or lack of challenge receipt may still occur.
Also, and even worse, automated notices such as online bills, newsletters, and other messages that you may wish to receive often come from varying unknown-ahead-of-time addresses; as replies to these addresses are rarely looked at, the challenge response will unanswered and the message will never be received by you.
Perhaps the most alarming feature of challenge/response is that its very nature creates an enormous amount of automatic (and annoying) replies, which are tantamount to backscatter.
In a semi-perfect world (for us, not the spammers), all domains and servers would be configured to support SPF records and DKIM, and all mail servers would deny in real-time. But, since that’s not going to happen any time soon, this begs the question, what can each of us do to both minimize how it affects us and to stop the problem all together?
Use an email service that supports SPF and/or domain keys. Add SPF and DKIM records to your domain. It can’t hurt, and it can only help.
2) Catch-all aliases — Turn them off!
3) Use explicit email alias addresses.
Using one or more alias addresses that point to your real (and ideally, less obvious/guessable) email address gives you an extra layer of protection from spam – you can swap out the alias addresses as you see fit (i.e. if they are being abused).
4) Filter just messages from “mailer-daemons”.
Bounce and backscatter email messages are often from addresses like “postmaster” and “mailerdaemon”. Some email filters (such as the one that LuxSci provides) will allow you to filter messages specifically from mailer daemons, either deleting them outright, or saving them temporarily to a separate email folder, allowing you to review and delete them without having to pick through your INBOX and weed them out. The downside of this method is that you may not be immediately notified of bounces from messages that you actually sent.
5) Filter backscatter email explicitly.
LuxSci has a special custom email filter designed to filter messages from “mailer-daemons” that are not from LuxSci’s servers. This allows you to get most of the real bounce backs from messages sent by you, while still blocking the backscatter messages.
6) Lock down your allow lists.
When just a handful of senders need to mail you from a specific domain (i.e. yahoo.com), it’s sometimes worth the extra time to specifically white-list just those senders, rather than the entire domain. Additionally, rather than white-listing your own domain to avoid any inter-office issues, it’s better to white-list the IP address of server you’re using to send. This will prevent spammers from getting a free ride when sending messages to you forged to be from you.
Backscatter spam is not an issue that can be solved in one fell swoop. It requires a combined effort by everyone involved. LuxSci is happy to do its part in waging the war on spam, by providing the services that we do, and keeping firm on our zero-tolerance policies regarding email abuse. LuxSci does support SPF and DKIM on inbound and outbound email and is happy to assist with issues regarding email aliases, catch-all aliases, and filtering mailer daemon and other problem inbound messages.
Please feel free to contact us at firstname.lastname@example.org to learn what we can do for you.