Hardened Postfix Configuration: Building a Bulletproof Mail Server

Let’s be honest: relying on shared hosting for business-critical email is professional suicide. If you are serious about infrastructure, you know the pain. One compromised WordPress install on a neighbor's account starts spewing Viagra spam, the shared IP gets blacklisted by Spamhaus, and suddenly your CEO's emails to Telenor are bouncing.

It is time to take control. Running your own Mail Transfer Agent (MTA) isn't just about pride; it's about deliverability, privacy, and speed. In the Norwegian market, where the Datatilsynet (Data Inspectorate) keeps a close watch on data handling under the Personal Data Act, owning your data path is essential.

This guide assumes you are running CentOS 5.5 or Debian Lenny. We will be using Postfix because Sendmail’s m4 configuration syntax is a relic we should all leave in the 90s.

1. The Foundation: Postfix Installation

First, purge Sendmail if it's pre-installed. We need a clean slate. On a standard CoolVDS CentOS node, this is straightforward:

Select Postfix. Now, let’s get into the /etc/postfix/main.cf. This file controls the nervous system of your mail server.

2. Configuration: Security and Identity

The default config is too permissive. We need to lock it down to prevent becoming an open relay—which is the fastest way to get your server terminated. Open your config and adjust these parameters:

myhostname = mail.yourdomain.no
mydomain = yourdomain.no
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# CRITICAL: Prevent open relay
ynynetworks = 127.0.0.0/8, [::1]/128
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Note the smtpd_recipient_restrictions. This ensures that only you (authenticated via SASL) or your local server can send mail out. Everyone else gets a 554 Access Denied error.

3. Storage Wars: mbox vs. Maildir

This is where hardware matters. The old mbox format stores all emails in a single massive text file. It locks the file every time a message is read or written. On a high-traffic server, file locking kills performance.

We use Maildir. It stores every email as a separate file. It’s faster and safer, but it is brutal on Disk I/O because of the sheer number of inodes and small file writes.

Add this to main.cf:

Pro Tip: Maildir requires high IOPS (Input/Output Operations Per Second). Standard SATA drives on budget VPS providers will choke here. This is why we provision CoolVDS instances with Enterprise RAID-10 SAS arrays. The random write performance is necessary when you have 50 users syncing IMAP folders simultaneously. Don't cheap out on storage backend.

4. Authentication and Encryption

Cleartext authentication is unacceptable, even in 2011. We need to wrap our auth in TLS. You will need a certificate—a self-signed one works for testing, but for production, buy a cheap cert from RapidSSL or similar.

Enable SASL in Postfix so users can login:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.pem
smtpd_tls_key_file = /etc/pki/tls/private/mail.key

5. Deliverability: SPF Records

Even with a clean IP, big providers like Gmail and Hotmail are suspicious of new servers. You must implement Sender Policy Framework (SPF). This is a TXT record in your DNS zone that tells the world which IPs are allowed to send email for your domain.

Add this to your DNS zone file:

This record says: "Only my MX records, my A record IP, and this specific IP are allowed to send mail. Hard fail (-all) everything else." This prevents spammers from spoofing your domain.

6. The Hardware Reality

Configuring the software is only half the battle. The underlying architecture dictates your uptime. In Norway, latency matters. Routing traffic through a budget host in Germany adds unnecessary milliseconds that degrade the interactive feel of IMAP.

Furthermore, email servers are I/O heavy. If you are on an OpenVZ container where a neighbor is compiling kernels or running heavy MySQL queries, your mail delivery will lag. This is the "noisy neighbor" effect.

We recommend KVM or Xen virtualization (standard on CoolVDS) for mail servers. This provides dedicated RAM and stricter I/O scheduling, ensuring that your Postfix queue processes instantly, regardless of what other users are doing. Combined with our low-latency peering in Oslo, your mail headers will show delivery times that make shared hosting look like snail mail.

Next Steps

Once you have Postfix running, install Dovecot for POP3/IMAP access and Amavisd-new + ClamAV for virus scanning. But get the transport layer right first.

Ready to deploy? Spin up a CoolVDS Centos 5 instance today. We guarantee a clean IP address upon provisioning—vital for day-one deliverability.