Bounce: the mail bounce attack

When it comes to anti-spam strategy, bounces are a practical way of rejecting e-mails addressed to a non-existent user in a domain. However, this technique presents serious risks for your mail servers.

When your mail server detects an insurmountable problem in the delivery of an e-mail, it issues a bounce, an automated e-mail sent to the sender of the original message to let him know that it could not be delivered. In the case we’re interested in (anti-spam), the insurmountable problem is the non-existence of a user account in our domain to receive the e-mail. The reverse is also true: many domain name holders are seeing a significant increase in the number of e-mails they receive. After analysis, they discovered that they were receiving a very large number of bounces from other mail servers. This is a sign that a spammer has usurped their domain name to flood thousands of random addresses.

Let’s take a look at which server is responsible for sending bounces in the event of an error, according to the SMTP RFC :
– if the recipient server accepts all recipients, and then detects a problem (e.g. it has to redirect the message to another server and this second server announces that the user does not exist; or it sends the address to a box and the box is full), it is responsible for sending an NDN (Non Delivery Notification) to the sender.
– if the recipient server accepts at least one recipient and rejects all others, it is responsible for any bounces for the one it accepts, while the sender server is responsible for bouncing rejected senders.
– if the recipient server rejects all messages, the sender server must send all NDNs.

In the corporate environment, it is common practice to use several mail servers to process mail, for reasons of security, processing, load balancing, routing, etc. In this case, one server usually acts as a gateway: it accepts all mail from the Internet and then sends it either to an internal server, or to an antivirus or antispam software. This gateway is rarely configured to verify the existence of users: it’s there to accept all mail destined for the domain and route it. Internal servers are responsible for verification. All this leads us to the following problems:
– you can impersonate the bounce recipient with a fake reply-to, or even a fake sender. The recipient will then receive an NDN for a message he has never received. Since the NDN contains a copy of the original e-mail, the attacker can easily attach a virus, Trojan or compression bomb.
– if the server sends a bounce individually to each invalid recipient, it can be used to attack an e-mail address. Let’s imagine that the attacker sends a single e-mail to 100 invalid recipients with a false reply-to. The spoofed reply-to will receive around 100 bounces in return, an excellent ratio of 1 to 100 for the spammer (and the figure can go even higher).

The stage is thus set for larger-scale manoeuvres. An attacker sends a single e-mail to the domain of an organization, with the following characteristics: an attachment of a certain size, sent in Cc: to a large number of invalid recipients in the domain, and with a false reply-to. The domain gateway accepts all mails since they are all from its domain. It performs various treatments (anti-virus, anti-spam) and forwards it to an internal mail server. This internal server discovers that the recipients are invalid, and sends a bounce for each invalid recipient to the false reply-to. The reply-to mail server then finds itself processing a huge number of messages, even though it has never sent an e-mail to the domain.
This gives the attacker a significant multiplier force, even without the equivalent resource. It can either send spam anonymously and without consuming resources, or use servers with no limit on the number of recipients in Cc: to flood a third-party server to the point of generating a DoS.

Solutions?
– Isolate your mail servers from the Internet by placing a third party who has the necessary skills to handle bounces, to protect you from having your servers used to send bounce-spams (which could get you blacklisted), to prevent you from receiving false bounces resulting from the use of your domain in reply-to, and finally to save your precious resources.
– Use a relay capable of handling call-outs.

To avoid all these risks, we advise you to configure your mail server to perform recipient filtering in the SMTP protocol rather than Bounce.