Bulletproof Postfix: Building a Hardened Mail Server on CentOS 5

There is nothing—and I mean nothing—more soul-crushing than waking up at 3:00 AM to a vibrating BlackBerry because your marketing director can't send emails to Hotmail. Your IP is blacklisted. Again. You check the logs, and sure enough, some PHP script on a forgotten vhost got compromised and turned your pristine server into a spam cannon.

If you are running a mail server in 2010 without understanding the intricacies of smtpd_recipient_restrictions or Reverse DNS, you are not an admin; you are a victim waiting to happen. Building a mail server isn't just about yum install postfix. It's about reputation management, latency control, and strict adherence to RFCs.

I've spent the last week scrubbing a client's IP reputation after they tried to host a mail server on a budget provider with dirty subnets. It was a disaster. Today, we are going to do it right. We are building a Postfix stack on CentOS 5.5 that delivers messages reliably, stays off the Spamhaus lists, and complies with Norwegian data retention norms.

The Prerequisites: It Starts with the Network

Before you even touch a config file, you need to look at your infrastructure. Email relies heavily on trust. If your server says "Hello, I am mail.example.com," but your IP address resolves to "vps-1234-generic-provider.net," you look suspicious. Google, Yahoo, and Telenor will drop your packets without a second thought.

You absolutely need a provider that supports:

• Clean IP Ranges: If your neighbor is spamming, you get collateral damage.
• Configurable Reverse DNS (PTR): This is non-negotiable.
• Low Latency to NIX: If you are serving Norwegian businesses, routing through a data center in Texas adds unnecessary hops.

Pro Tip: This is why I deploy mail gateways on CoolVDS. Their control panel lets me set the PTR record instantly to match my hostname, and their IP blocks are aggressively monitored for abuse, keeping the neighborhood clean. Plus, ping times to Oslo are practically non-existent.

Step 1: The Base Configuration

Let's assume you have a fresh install of CentOS 5.5. First, remove Sendmail if it's lingering around. We want Postfix 2.7.

Open /etc/postfix/main.cf. This is where the magic happens. Do not simply copy-paste generic configs you found on a forum. Understand what you are typing.

Here is a baseline config for a server handling a single domain:

# /etc/postfix/main.cf

# Identity
myhostname = mail.yourdomain.no
mydomain = yourdomain.no
myorigin = $mydomain

# Network
inet_interfaces = all
mynetworks = 127.0.0.0/8

# Delivery
home_mailbox = Maildir/

# The most critical part: Restrictions
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_hostname,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_rbl_client zen.spamhaus.org

Breaking Down the Restrictions

The smtpd_recipient_restrictions block is your firewall against the dark arts of the internet.

• permit_mynetworks: Allows localhost to send without auth.
• reject_unauth_destination: CRITICAL. Without this, you are an Open Relay. Spammers will find you in minutes.
• reject_rbl_client zen.spamhaus.org: This queries the Spamhaus Real-time Blackhole List. If the connecting IP is a known spammer, Postfix drops the connection before data is even transferred. This saves CPU and bandwidth.

Step 2: Authentication with SASL

You need to send emails from your laptop, but you are likely on a dynamic IP from an ISP like NextGenTel or Canal Digital. You cannot rely on IP whitelisting. You need SMTP Authentication.

Edit /etc/sysconfig/saslauthd to use the shadow mechanism (local system users):

Start the service:

Now, tell Postfix to use it. Add this to main.cf:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes

The broken_sasl_auth_clients = yes directive is an ugly hack for older Outlook clients, but unfortunately, in the corporate world, we still have to support Outlook Express users.

Step 3: TLS Encryption

Sending passwords in plain text over port 25 is reckless. While we don't have ubiquitous free certificates yet, you should generate a self-signed cert for internal testing, or buy a cheap RapidSSL cert for production.

Generate the key and cert:

Add to main.cf:

smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_loglevel = 1

Using may allows opportunistic encryption. If the other server supports TLS, great. If not, it falls back to cleartext. We aren't quite ready to enforce mandatory TLS globally in 2010.

Testing and Verification

Restart Postfix:

Don't just assume it works. Telnet into your server. If you are a Linux admin, you should dream in Telnet.

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.yourdomain.no ESMTP Postfix
EHLO localhost
250-mail.yourdomain.no
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

If you see 250-AUTH and 250-STARTTLS, you are in business.

Performance and Storage Considerations

Mail servers are I/O intensive. When you have thousands of messages in a Maildir format, listing a directory or searching via IMAP puts significant strain on your disk subsystem. Standard SATA drives often choke under the random read/write patterns of a busy mail server.

This is where hardware choice matters. You want RAID 10. While SSDs are starting to appear in enterprise storage, high-performance SAS 15k RPM drives in a RAID 10 array are still the gold standard for reliability and speed in most datacenters.

At CoolVDS, we configure our storage backend specifically to handle these high-IOPS workloads. We don't oversell our spindles. When your CEO searches for that one PDF from 2008, the grep shouldn't bring the whole server to its knees.

A Note on Norwegian Regulations

Operating in Norway means adhering to the Personopplysningsloven (Personal Data Act). While we don't have the complexities of some proposed future EU regulations yet, the Datatilsynet (Data Inspectorate) is strict about where data lives. Hosting your mail server on Norwegian soil—or at least within the EEA—is the safest bet for legal compliance.

Don't risk hosting sensitive client emails on a budget US server just to save 50 kroner a month. The latency penalty and legal ambiguity aren't worth it.

Final Thoughts

Configuring Postfix is a rite of passage. It forces you to understand DNS, TCP/IP, and authentication protocols deeply. But a config file is only as good as the infrastructure it runs on. You need clean IPs, solid I/O performance, and a host that understands the technical requirements of running a mail transfer agent.

Don't let your legitimate emails rot in a spam folder. Provision a rock-solid CentOS instance on CoolVDS today, set your PTR record in our panel, and take full control of your email delivery.