Running an Email Server

I administer an email server for a couple of domains and a few users.  Incorrectly configured email servers result in a lot of my administration work.   Due to improper configuration, far too many servers look like Spam servers.   A little effort in setting up your server can make my life easier, and increase your chance of successfully delivering email everywhere.  This article describes steps you should take.

DNS Configuration

If you have a dynamic IP address, you look like a Spambot.  Many servers will automatically block your email or flag it as Spam.  The Spamhaus Project maintains a list of IP addresses which should not be sending email including  dynamic IP addresses.  If your IP address is listed there, you shouldn’t be sending email directly to the Internet.  Configure your email server to relay email through your ISP’s server.  You will need to arrange for another server to accept email for your domain.

If you want send or receive email directly to the Internet, you need a static IP address.  Your ISP will likely charge for this.  Hosting providers should always give you a static IP address.  Your static address a valid Internet address.  Once you have your static address configure your DNS records.

You will need to configure a number of DNS records.   Never use a CNAME record for a mail server.  At a minimum you will need:

• An A (address) record for your mail server’s fully qualified address (ensure this address is RFC  compliant);
• One or more MX (mail exchange) records for each domain you wish to send or receive emails for; and
• A PTR (pointer) record from your static address to the fully qualified address of your mail server.  (This last one will need to be configured by the provider of the IP address.)

You should setup records for SPF corresponding to each domain and sub-domain.  The Sender Policy Framework Project provides documentation on how to configure them.   If your DNS supports it, setup an SPF record as well as the TXT record for the domains you send email as  (duplicate the TXT record and change TXT to SPF).

Now you are ready to configure your email server.

The Email Conversation

The SMTP protocol is a conversational protocol very similar to a polite phone call.   It works best when all parties are honest about who they are.  If not lots of things can go wrong.  The called persons part is emphasized.

Hello, Smith Residence
Hello, this is Miss Jane Doe
Yes
I have a message from Rev. James Earl Jones
OK
The message is for Mrs Brenda Evens
We don't know her.
Sorry the message is also for Mrs. Eva Smith
OK
And also her Daughter Precious
OK
Can you take the message
Yes
There is a church meeting after services Sunday. 
Could you please attend?
That is all.  Thank you.
OK
Goodbye
Goodbye

This discussion is based on trust that the caller and sender are who they say they are.  The caller is also trusting that the message will be delivered.   Email transfers involve the same trust relationships.

The SMTP dialog is designed to be understandable to both man and computer.  The following email dialog is the SMTP equivalent of the exchange above.  The called server’s parts are these where the line starts with a three digit reply code.

250 smith.example.com SMTP Server Ready.
HELO doe.example.com
250 smith.example.com Hello doe.example.com [192.0.2.41]
MAIL FROM:<earl.jones@church.example.com>
250 OK
RCPT TO:<brenda.evans@doe.example.com>
451 User unknown
RCPT TO:<eva.smith@doe.example.com>
250 Accepted
RCPT TO:<precious.smith@doe.example.com>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
There is a church meeting after services this week. Could you please attend.
.
250 OK id=104Maz-0080qr-HH
QUIT
221 smith.example.com closing connection

Modern servers accept EHLO in place of HELO.  In response server the will list their capabilities in an extended response.  This may allow the servers to complete their conversion more efficiently or securely.

Email Server Configuration

Ensure your email server knows its fully qualified address.   The following identifications are likely to cause you problems (examples, from above example where possible):

• an unqualified name (doe);
• any variation of the other server’s id or IP address (smith.example.com);
• your ip address (192.0.2.41), there is a legal format but its use is discouraged (and may not be accepted); or
• an unrelated address (example.gmail.com).

Ensure the envelope addresses belong to one of the domains you are sending from.   This may require rewriting addresses.   NEVER use an address to which you can’t send from the Internet.   Any domain you send email from should have a working mail server (with an MX DNS record) to which email can be sent.

A sure way to get your email blocked is to run an open email relay.  An open relay accepts email from anyone and then attempts to forward it to its final destination.  Instructions for enabling mobile users to relay email are covered later in this document.  Two simple rules will prevent your server from being an open relay:

• Accept email from the Internet for your domains only; and
• Only send email to the Internet if it originated on your network (including authenticated mobile users).

Setup appropriate email retry rules.  Always retry messages which were neither delivered or refused.  You should wait at least five minutes before retrying.  Retry with decreasing frequency for a few days.  Bounce messages which remain undeliverable for several days.

If  a message is not immediately deliverable, you may notify the sender that the message is delayed.   This message should clearly indicate that the message will be retried.  Delay messages are typically sent when message fails the initial try.  Systems sending time sensitive data may want to send another message if the message remains on the queue for a long time (at least 12 hours).

Don’t generate backscatter by bouncing emails after accepting it.   This results in you sending Spam to users whose email addresses have been forged.  It is best practice to only accept email, if you know you could deliver it.  This rule can be slightly relaxed for email from your network.   For email originating from the Internet defer or reject any email that could not be immediately delivered.   Backup mail servers can relax this rule, and accept email for known users for which delivery will be deferred.

Make sure you have the required email addresses for any domain which send mail.  At a minimum you should have abuse and postmaster addresses.   These are usually aliases which deliver to someone’s (your) mailbox.  Don’t worry about being inundated by email to these addresses, they are low volume.   These addresses usually map to a user who can blacklist the sender, so they don’t make good Spam targets.   Investigate issues sent to these addresses promptly.

Email Formatting

Email messages which are formatted in unique formats tend to be Spam.   Follow the formats outlined in RFC5322.  Things that look like Spam include:

• Missing headers: Subject, Date, Message-id, or To;
• Incorrect or incorrectly formatted headers;
• Invalid sender header;
• Incorrect language and/or character set;
• All uppercase in headers (especially Subject);
• Non-ASCII characters (except within 8bit Mime);
• Lines which are too long (longer than 78 characters);
• HTML only messages (valid but possibly non-accessible);
• Messages bodies without any text; and
• Messages that look a lot like Spam (using strange spellings or words and phrases commonly used in Spam)

Avoiding Blacklists

Now your email server is correctly configured, and your email is well formatted.  You won’t need to ask your users to white list your domain and email address in order to send them email.   Any email you send should be accepted without needing to be white-listed.

A number of block lists exist which identify senders with reputations for sending SPAM.  You too can get listed on one or more.  Setup a robot to search the Internet for email addresses you can send email to.  You are may find a few Spam trap addresses.  Send some email to them to ensure you get added to the related blacklist.

To avoid being added to blacklists, manage the email addresses you send to.  Use a double opt-in method to collect addresses for any mailing lists you create.   Collect bounce messages and stop using addresses which repeatedly bounce.  Don’t buy email addresses from other organizations.

Email Submission for Road Warriors

If you have Road Warriors who need to send email from your domains, configure your server to listen to the submission port.   The is a port has been designated for email submission only.  It allows you to safely extend your local email network onto the Internet.

Configure your server to require authentication before accepting email originating on the submission port.   You should also configure the server to enable startTLS conversion to an encrypted connection.   Authentication protocols which pass credentials in clear text should only be available on an encrypted connection.  Best practice is to only allow authentication on encrypted connections.

Provide each Road Warriors with their own credentials for connecting to the submission port.  You should also to provide instructions for configuring their email client to connect to the submission port.

An alternative or additional option is to provide a secured Webmail interface on the Internet.