I’ve spent a few days reworking the mail setup, and thought I’d share some information on the actual setup and recent changes here. This should mostly be of interest to people having one or more domains hosted on the mertner.com server.
Receiving a mail is a surprisingly complicated process – more things than you’d expect occur whenever a mail changes hands from one server to another. Sadly, the bulk of the work serves a single purpose only, namely preventing SPAM and other unpleasantries from reaching end-users. As the sender cannot be trusted (to participate in this goal), it falls upon the receiving party to ensure that everything is legit before accepting and delivering the mail to its recipient.
This involves verifying that the sender is legitimate, presents valid data about itself, complies with Internet protocols (RFCs), and in general behaves nicely. It also entails scanning the message itself for malicious content (attachments or vira), advertisements, and other junk.
White-, Black- and Greylisting
The first level of defence uses a mechanism called [greylisting](http://projects.puremagic.com/greylisting/), and relies on the fact that SPAM senders are always in a hurry to get their messages out. Whenever a new sender is encountered, the server will ask the sender to retry delivery later. If the sender is too aggressive and retries immediatedly, he will be blacklisted. If the sender is patient and retries only after 20 minutes, he will be whitelisted for the next 60 days. Note: the SMTP protocol definition (RFC2821) says that clients should wait for at least 30 minutes before retrying.
[SpamAssassin](http://spamassassin.apache.org) is used to analyze the content of the actual message based on an endless list of rules. Some rules match regular emails and give negative points, others match SPAM and give positive points. The sum of the points awarded from all matching rules yield a score that is used subsequently to decide the fate of the mail being delivered.
Once a score has been computed the server needs to figure out what action to take for the message. Every domain can define its own action(s) and minimum score(s) required for triggering the action. The currently available actions are:
reject (don’t accept the message from the sending party)
drop (silently discard the message, pretending it was delivered)
warn (deliver the message to the recipient, but add message headers to identify the mail as SPAM; if the message is virus infected, action
drop is used instead)
This is best illustrated with an example. Imagine the server receiving a mail for a recipient in the mertner.com domain, and assigning the score 5.2 to the message. The domain mertner.com has been configured to
warn when scores exceed 4.0 and to
reject when scores exceed 6.0. Thus, this particular message would have it’s subject rewritten (prefixed with \[SPAM\]) and various messages headers inserted, but eventually get delivered to the recipient. Had the score been 6.2 instead of 5.2 the mail would have been rejected.
The current defaults are set to
warn at 4.0 and
reject at 5.0. Just let me know if you’d like to use different settings for your domain(s).
If a message gets delivered to its intended recipient, chances are that it will have been decorated with a number of message headers. These are usually not immediatedly visible in email clients, but are nevertheless present and can thus be used for filtering (such as moving messages suspected of being SPAM to designated folders). The following message headers are (potentially) added:
* X-Spam-Flag (YES, if the server thinks it is a spam)
* X-Spam-Score (numeric counter, and a list of + characters representing the size of the counter)
* X-Spam-Report (the entire scorecard from SpamAssassing; this value of this can be quite lengthy as every matching rule and the points awarded will be listed here)
* X-DNSbl-Warning (sending server is listed as an open relay and likely source of SPAM)
* X-ACL-Warn (sending server is not RFC compliant, behaves badly or is otherwise suspect).
* X-HELO-Warning (sending server is misconfigured or lies about it’s identity)
Examples of actual message headers:
* X-Spam-Score: 4.8 (++++)
* X-ACL-Warn: remote host used our name in HELO/EHLO greeting.
* X-HELO-Warning: Remote host 188.8.131.52 (somebody.tele.dk) incorrectly presented itself as mikkel.org
Most of you will not want to use these headers, but at least now you know why and that they’re there.
At the end of this post I’d like to express my gratitude to the people behind the following software projects, without whose efforts none of the above would have been possible:
Please donate to these projects. Even $20 can make a difference, and they most certainly deserve your support.