6 - Anti-Spam Measures

This chapter ties together references to all the MTA's spam-related config settings, and other defensive measures.
Mailismus employs network-based policies (eg. DNS-based validation, blacklisting, greylisting) which can trap the vast majority of spam emails without the overhead of scanning the message content, or running an external tool to scan them.
However, it also provides a filtering API to enable you to integrate a 3rd-party message scanner or develop your own.

In the case of our SMTP-Server component, we want to minimise incoming spam.
In the case of our SMTP-Client component, we want to minimise the chances of outgoing emails triggering defensive measures in other servers, or causing our server to be flagged as a source of spam.
In many cases, it's a straightforward trade-off against throughput, as an overly aggressive sender can resemble a spammer or other forms of attackers.

Note that Mailismus provides mechanism, not policy. As a mailserver sysadmin, you have to decide the parameters of your service, and for its part, Mailismus aims to provide sufficient control points to give you the desired flexibility.

6.1 - The Submit Path

One of the most important points to be aware of, is that in addition to the floods of fake offers that appear in your inbox, spammers also generate vast amounts of traffic to invalid addresses.
A server can always opt to accept all incoming messages, and then find out whether the recipients are valid (or if their domains even exist) when it goes to deliver them onwards. If we take this approach however, we then become responsible for generating and returning the NDRs when they bounce, and in addition to the extra processing burden this imposes on us, it can also make us party to a back-scatter attack, ie. bombarding a faked sender address with thousands of NDRs for messages it never sent. You could find your own server on a blacklist as a result of being drawn into such an attack!
For these reasons, it's best to reject invalid messages at the point of entry, so that they never become our problem in the first place. That means tightening up the SMTP Server.

Note that the SMTP Server's remotenets config block (see §4.4.4) can be used to apply different settings to different sets of clients depending on their IP addresses. For example, local machines could be marked for minimal validation and maximal throughput.

The relevant server-side config settings are as follows:

6.2 - The Delivery Path

There are fewer anti-spam levers in the SMTP Client, as it has to deal with messages that have already been accepted into the mailserver, and relay them onwards.

Note that the Client's remotenets config block (see §4.5.3) can be used to apply different settings to different sets of remote servers depending on their IP addresses. For example, local destinations and smarthosts could be marked for maximum throughput.

The relevant client-side config settings are as follows: