Mail Server Setup
years ago I lived in Brookside, NJ, a community of upscale homes trying
desperately to retain a rural atmosphere while suburban sprawl spread
elsewhere like a blight. There were even a few fragrant
cattle farms left.
Computer email is designed and intended to provide automatic and nearly instantaneous delivery from sender to recipient. However, Windows users, whose machines seem unable to reliably function 24/7, and who cannot intelligently configure their systems to run mail delivery services, depend on services provided by their ISP. They seem content to use the primitive method of running frequently to a mail collection service to check if any new mail has arrived, even though there are no discernible benefits, social or otherwise. As this blight has spread, this primitive system has become the norm.
It needn't be so. Linux has always been designed to receive email directly and instantly from the sender. Linux is certainly reliable enough to run 24/7 for years on end. Having your mail delivered automatically, door to door, as it were, merely requires configuring the mail transport service properly. Unfortunately, as abusers of internet services proliferate, this task becomes more complex. Topics discussed below are:
Domain name and IP
A prerequisite to receiving mail directly to your machine is a domain name along with a DNS entry that translates that domain name to your machine's IP address. For mail addressed to firstname.lastname@example.org to be deliverable, the DNS system must translate the string datix.us to my current numerical IP address. If I had a static IP, the provider would make that DNS entry once and for all. But I, and most others, do not. My cable connection provider assigns an IP dynamically and is free to change it at his whim. This makes no sense. It may have when folks used modems and connected for brief periods. An ISP could service many customers with fewer distinct IPs. But with cable connections that are on continously, a distinct IP is needed for each customer. It's clear that dynamic IPs are just a marketing ploy to make you pay extra for the convenience of a static IP.
Fortunately, many commercial enterprises offer dynamic domain name services for a fee, or even for free. Originally, I purchased my very own domain name, datix.us, from godaddy.com, but then became annoyed with their business practices, and switched to namecheap.com. Namecheap has proven to be reliable and easy to work with. Linux provides a script, ddclient, that looks up my current IP address once an hour and, if it has changed, automatically notifies namecheap.com and updates the DNS data. Thus, datix.us will always be translated to my current IP, except for a brief period after it changes. In practice, my IP almost never changes.
Sendmail is the granddaddy of UNIX/Linux mail transport agents. Some "progressives" advocate replacing it with postfix, but I prefer sticking with the tried and true. Because mail is an obvious way to transmit mal-ware into an innocent system, sendmail has been the target of more subversive attacks than almost any other program. Each and every attack has been thwarted and blocked so that, after decades of improvement, it is safe say that sendmail is bulletproof, or as safe as any software of such complexity can ever be. Sendmail is a very complex program because it has to operate in a huge variety of situations and provide many options. The definitive O'Reilly book, Sendmail, by Bryan Costales with Eric Allman, is 2 inches thick and 1021 pages long. Many people are intimidated by this amount of complexity. The main configuration file, /etc/mail/sendmail.cf, uses a unique and arcane special language that only the author can love. However, in all recent versions, a relatively compact sendmail.mc file contains a more readable structure of commands that are processed by the m4 language interpreter to construct the more difficult sendmail.cf file. Fedora provides a standard version that serves as a basis for modification.
Sendmail implements the two-way SMTP protocol. It communicates with a similar member in another machine to send or receive messages over an internet channel. In the daemon mode, sendmail listens continuously for packets on port 25 and when a peer machine sends a message, sendmail analyzes the header and disposes of the message in various ways. Some of the possibilities are to
A second non-daemon instance of sendmail is also used to send mail. The program that creates the message pipes it to sendmail, which analyzes the headers and tries to deliver it.
If sendmail fails to connect to the destination machine, the message is stored in /var/spool/mqueue/, and transmission is queued for a later attempt. After successive failures over a four day interval, a failure notice is returned to the sender.
Configuring all this is surprisingly simple. Here are the changes, in diff format, that I've made to the standard sendmail.mc file provided by Fedora 26:
# diff sendmail.mcSTD sendmail.mc
There are some other important files in /etc/mail that are referenced in sendmail.mc and used by sendmail.
The access file lists machines and domains that are allowed to relay through this machine. All others are disallowed. This is critically important to prevent this machine from being hijacked by spammers for their nefarious purposes. All my local machines are listed here and given RELAY permission.
The local-host-names file lists all the names by which this machine is known, allowing local delivery of messages:
Whenever any file in /var/mail/ is modified, run 'make'. This will convert the text source files to the database files that sendmail actually uses.
Relaying for selected external machines
sendmail.mc above prepare the server to accept logins from external
client machines to relay email. Those client machines must be
configured in a similar way but to use this server, datix.us, as their
SMART_HOST. In addition, the client machine needs this line
added to /etc/mail/sendmail.mc:
Email name aliasing
it is desirable to use one name internally and a different name
externally. For example, my internal usrname is dad, but I
might wish to use dadegraaf as my email name. Two files in
/etc/mail make this conversion easy.
Spam and virus blocking
methods are used to minimize intrusion of obnoxious email -
greylisting, clamav and spamassassin. They are installed
nowadays with dnf:
Clamav uses a database containing descriptive data of known viruses. If a message appears to match, it is not delivered. There are mighty few known Linux viruses, so this is mainly of benefit to any Windows machine in the LAN.
Any message that makes it through is then examined by spamassassin. It uses a sophisticated statistical spam scoring system. If the rating is above a threshold (5.0) it is so labelled. When I first implemented spam testing in Feb 2005 the number of spams detected by spamassassin went from 120/day to 6/day. Recent logs show about 3.9/day. This combo is very effective.
Finally, procmail tries to deliver the message, using global rules in /etc/procmailrc and my personal rules in ~/.procmailrc. The global rules divert the message to /usr/tmp/spamtrap if it has been labeled as spam. My personal rules divert mailling list messages to their own mailboxes and deliver the rest to me.