Building a Bulletproof Postfix Mail Server on CentOS 5

There is nothing—absolutely nothing—more soul-crushing in a sysadmin's life than waking up at 3:00 AM to find your mail server IP listed on Spamhaus. Your CEO can't email clients, the marketing newsletter is bouncing, and you are stuck in a queue waiting for a delist request while your users scream about "lost emails."

I've been there. Last year, I audited a setup for a client in Oslo who decided to run a default Postfix config on a cheap, oversold VPS. Within 48 hours, they were an open relay, pumping out Viagra spam to the entire northern hemisphere. Their IP reputation was incinerated.

Running a mail server in 2010 is not about "installing software." It is about warfare. You are fighting spammers, script kiddies, and aggressive RBLs (Real-time Blackhole Lists). If you are deploying this in Norway, you also have Datatilsynet (The Data Inspectorate) breathing down your neck regarding data retention and privacy. Here is how to configure Postfix properly on CentOS 5.5, so you can actually sleep at night.

The Foundation: Clean IPs and True Virtualization

Before you even type yum install, look at your infrastructure. Email delivery relies 90% on reputation. If your hosting provider packs 500 customers onto a single IP block using OpenVZ, one neighbor sending spam gets the whole subnet blocked. This is the "noisy neighbor" effect.

You need a clean IP and proper isolation. This is why we default to Xen HVM virtualization at CoolVDS. Unlike container-based hosting, Xen gives you a dedicated kernel and dedicated resources. More importantly, we enforce strict outbound monitoring on our network in Oslo, keeping our IP ranges pristine. If your provider doesn't offer automated Reverse DNS (rDNS) setup, leave them. You cannot run a mail server without a valid PTR record.

Step 1: Installation and Basic Hygiene

On a fresh CentOS 5.5 install, strip out Sendmail before bringing in the big guns.

yum remove sendmail
yum install postfix system-switch-mail
system-switch-mail
# Select Postfix

Now, let's open /etc/postfix/main.cf. The defaults are too permissive. We need to lock this down.

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

Step 2: The Fortress (Restrictions)

This is where the magic happens. We need to tell Postfix exactly who is allowed to talk to us. We place the rejection rules early in the handshake to save CPU cycles and bandwidth.

# /etc/postfix/main.cf

# Require HELO handshake
smtpd_helo_required = yes

# The heavy lifting: Recipient Restrictions
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

Pro Tip: Be careful with RBLs. zen.spamhaus.org is the gold standard, but if you add too many obscure lists, you will start rejecting legitimate traffic (false positives). Stick to the majors.

Step 3: Fighting Back with SPF

Sender Policy Framework (SPF) is becoming mandatory. It's a DNS TXT record that tells the world which IPs are allowed to send mail for your domain. Without this, Hotmail and Gmail will likely junk your messages.

Add this TXT record to your DNS zone:

This strictly states: "Only the IP 123.123.123.123 can send mail for us. Reject everything else."

Step 4: Performance Tuning for High Load

If you are serving a large Norwegian e-commerce site, the default process limits in Postfix will choke. Disk I/O is usually the bottleneck. While many providers are still spinning 7.2k SATA drives, mail queues demand high IOPS (Input/Output Operations Per Second).

At CoolVDS, we utilize high-performance SAS 15k RPM RAID-10 arrays. This provides the low latency required for rapid spooling. If you are on standard SATA storage, you might need to move your spool directory to a separate partition or tweak the default_process_limit.

# /etc/postfix/main.cf
# Increase for high-volume servers (Default is 100)
default_process_limit = 200

Step 5: Logging and Monitoring

You cannot manage what you do not measure. In Norway, strict adherence to the Personopplysningsloven means you need to know exactly what data passes through your servers. Ensure your logging is verbose enough for troubleshooting but respects privacy.

Monitor your logs in real-time:

Look for "NOQUEUE: reject". That is the sound of your configuration working, blocking spammers before they even get in the door.

Conclusion

Running a mail server is a responsibility, not a feature. It requires a clean network reputation, strict configuration, and hardware that can handle the random I/O patterns of a mail queue.

If you are tired of fighting with blacklists on shared hosting or dealing with sluggish I/O on oversold nodes, it might be time to move your infrastructure. A CoolVDS Xen instance with our pristine IP reputation gives you the baseline you need to ensure your emails actually hit the Inbox.