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.
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:
- Validate Client Machine:
The remote client's professed hostname can be vetted with the
validate_helo
setting (see §4.4.4).
- Validate Sender Address:
The sender address can be verified with the
validate_sender
settings, which are documented in §4.4.4 and include the option of DNS lookup.
- Validate Recipient Address:
The recipient addresses can be verified with the
validate_recip
settings, which are documented in §4.4.4 and include the option of DNS lookup:
Since a large number of invalid recipients are one of the hallmarks of a spam message (or a sender whose address lists are so inaccurate, that they might as well be a spammer), the spammer can be effectively slowed down by the
delay_badrecip
setting, also described in §4.4.4.
- Blacklisting:
You can bar emails from specific IPs, using the blacklist facility (see §4.4.5).
- Greylisting:
You can block a significant number of spammers using the greylist facility (see §4.4.6).
- Filtering:
You can develop your own filter based on the Mailismus filtering API, and load it into Mailismus to examine incoming messages (see §4.4.10).
- Directional Sender Filtering:
You can use IP-based rules to detect some forged sender addresses with these settings, which are documented in §4.4.4:
• sender_deny
• sender_permit
- Protocol Compliance:
Lots of spammers use mass mailing software which tends not to be fully SMTP compliant.
They haven't got time to wait around for the Server's responses, and don't generally care what the responses are anyway since they're hardly going to resend any failed messages.
They just blast out a canned script as soon as they connect and move on to the next target on their hit list.
Because of this, the simple measure of pausing before issuing our greeting may catch many of them out.
See the
delay_greet
setting in §4.4.4.
Note that although this does have the effect of delaying all senders, that is a side-effect rather than the main purpose.
This setting is aimed at rejecting spammers outright, not simply slowing them down.
- Politeness:
Legitimate senders are normally wary of overloading other mailservers with a torrent of traffic, not least for the fear that they will themselves be tagged as spammers.
This manifests itself as a general politeness and conservatism in their sending rates.
Mailismus is quite prepared to accept unlimited connections from anybody to maximise throughput,
but a legitimate sender is unlikely to take up the offer and will probably limit itself to no more than 20 simultaneous connections
(if even that).
For this reason if you specify a limit with the
maxpeerconnections
setting in §4.4.4, you are unlikely to slow down legitimate senders, and only spammers would be affected.
You can use the
remotenets
config block to assign much higher limits to local clients.
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:
- Simultaneous Connections:
Mailismus is a highly scalable I/O engine which is probably capable of overwhelming many mailservers, but it would be inadvisable to approach those limits,
as there is a limit to how many simultaneous connections most mailservers will accept from any one IP.
If this limit is regularly and grossly exceeded, then as well as the excess connections being refused, you're likely to find yourself being tagged as a spammer.
See the
maxserverconnections
setting in §4.5.2, for how to throttle the outgoing connection rate to any one domain.
- Message Volume:
In addition to limiting the number of connections to any one server, there is the greyer area of how many recipients and messages can be pumped into any one connection while it's open.
The SMTP protocol places no limits on the number of recipients per message or messages per connection, nor does it provide any means for servers to signal their own limits, but invariably these unadvertised limits do exist internally, and there is the potential for problems when they're hit.
Eg. a server should respond with a temporary error so that the client resumes in a new connection, but some may respond with a permanent error, thus bouncing dozens of valid messages that would otherwise have been accepted.
In addition, there's the possibility that excessive recipients will be viewed negatively by spam profilers.
The relevant settings for throttling recipients and messages are:
• maxrecips - see §4.5.2
• maxmessages - see §4.5.2
- DNS Correctness:
This is probably the most important thing a client must ensure, since it's unlikely to get past the HELO stage if hostnames and IP addresses don't match up.
The relevant setting is
announcehost,
which is documented in §4.5.3.
Make sure that the announced hostname matches the IP address you're calling out on, and if you have multiple IP interfaces, use the
remotenets
block to tailor the announced name.
Finally (and this is completely external to Mailismus) make sure that your DNS settings provide a reverse mapping from the IP back to the hostname, as well as the straightforward name-to-IP mapping.
Many mailservers will insist on this.
If you cannot meet this requirement because you have no control over your
in-addr.arpa
DNS domain, then you should consider relaying your outgoing email via your ISP.
