410

Backscatter Protection in MDaemon 9.6

Backscatter Protection in MDaemon 9.6

Overview

Backscatter Protection (BP) is a feature of MDaemon Pro 9.6+ which protects your users from unwanted email 'backscatter.' Backscatter occurs when spam or viruses send mail using a forged address as the return path. This can lead to thousands of bogus delivery status notices, vacation and out-of-office messages, auto-responders, etc., ending up in the inbox.

For example, it is extremely common for spam and viruses to masquerade as you or one of your users when sending mail. Often, these spam and virus emails attempt delivery to an unknown recipient. When this occurs, you get a DSN (Delivery Status Notification) or 'bounce' email sent to your inbox. It's not uncommon for a very large percentage of such notifications to be bogus - informing you on the status of emails you never sent in the first place.

Occasionally the goal of the spam or virus is to reach your inbox indirectly through the use of such tactics or to perform a Denial of Service (DoS) attack against your mail server by causing a flood of invalid email to arrive from servers all over the world.

Solution

To combat this problem a method was devised to distinguish between legitimate and unauthorized use of your email address in the MAIL FROM: return path. By protecting the return path, MDaemon can determine whether a certain class of messages, such as DSNs, vacation notices, and auto-responders are valid or not. This method is called Backscatter Protection.

Technology

BP is based on the BATV (bounce address tag validation) mechanism and it works like this: Any time MDaemon sends an email it incorporates a special bit of secret data into the existing return path value. This secret data is computed using an algorithm in conjunction with a secret key. The result is about 10 bytes of information that only your MDaemon knows how to generate and verify. The message is then sent using this new return path. When receiving mail, if the sender identifies itself as 'mailer-daemon' or uses a NULL return path indicating that this message is a DSN or other automated response, the intended recipient of the message can be checked by MDaemon. If that recipient value contains the secret bit, it's valid. If not, it isn't. Appropriate action can then be taken in accord with local policy.

Example

Instead of sending a message out as:

MAIL FROM: user01@example.com

It would be sent out as (for example):

MAIL FROM: <prvs=[encrypted-part]=user01@example.com>

So, when someone generates a bogus message using:

MAIL FROM: user01@example.com

..and this results in a bounce back to MDaemon we will know that it's bogus because:

MAIL FROM: <>
plus:
RCPT TO: user01@example.com

should never happen. The RCPT TO: can always be expected to contain the encrypted part. If it's missing, we know this bounce was a joe-job.

For further information on BATV, please see: http://mipassoc.org/batv/index.html

For further information on joe-jobs, please see: http://en.wikipedia.org/wiki/Joe_job