Hardening Postfix: The 2011 Guide to Deliverability and Performance

I recently watched a client's mail server melt down. Not figuratively. The load average hit 40.0, the disk wait (I/O) was hovering at 90%, and the queue was backed up with 50,000 legitimate transactional emails stuck behind a wave of backscatter spam. Why? Because they treated their MTA (Mail Transfer Agent) like an afterthought, hosted on a cheap, oversold OpenVZ container.

If you are running a business in Norway, you cannot afford to have your IP blacklisted by Spamhaus or your latency to the NIX (Norwegian Internet Exchange) drift into the triple digits. Email is still the plumbing of the internet. When it breaks, everything breaks.

This guide isn't about setting up a hobby server. This is about configuring Postfix 2.7+ for high-volume, secure delivery on Debian 6 (Squeeze) or CentOS 5.6. We are going to look at the configurations that actually matter: aggressive restriction classes, SPF implementation, and the hardware reality of mail processing.

The Hardware Reality: It's All About I/O

Before we touch a single config file, let's talk about the metal. Postfix is incredibly efficient, but it is I/O hungry. Every email received triggers multiple disk writes: receiving the message, writing to the queue, updating logs, processing through Amavis/SpamAssassin, and finally writing to the Maildir.

On a traditional shared host or a budget VPS, you are fighting for IOPS (Input/Output Operations Per Second) with hundreds of other users. If your neighbor decides to compile a kernel or run a backup, your mail queue stalls.

Pro Tip: Avoid OpenVZ for serious mail servers. The lack of a true isolated kernel and shared disk I/O scheduler means you have zero guarantee of performance. At CoolVDS, we exclusively use KVM and Xen virtualization. This hardware virtualization ensures that the RAM and Disk I/O you pay for are actually yours. For mail servers, our RAID-10 SAS and emerging SSD setups prevent the "iowait" death spiral.

Step 1: The Base Configuration

Let's assume you have a fresh Debian Squeeze install. First, get the basics running. We aren't just installing Postfix; we are installing the toolchain to keep it honest.

During the ncurses prompt, select "Internet Site". Your FQDN (Fully Qualified Domain Name) is critical here. If your reverse DNS (PTR record) doesn't match your hostname, Gmail and Hotmail will drop your packets at the border. Ensure your hostname is mail.yourdomain.no and that your provider (like CoolVDS) allows you to set the custom PTR record in the control panel.

Step 2: Bulletproof main.cf Restrictions

The default Postfix config is too permissive. We need to reject bad actors *before* they waste our CPU cycles processing the body of the email. We do this with smtpd_recipient_restrictions.

Open /etc/postfix/main.cf and locate the restrictions section. If it's not there, add this block. Order matters immensely here.

# /etc/postfix/main.cf

# Delay the rejection until RCPT TO to get more log info
smtpd_delay_reject = yes

smtpd_helo_required = yes
smtpd_helo_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname

smtpd_sender_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

smtpd_recipient_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_non_fqdn_recipient,
    # The big hammer: check live RBLs
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    permit

The reject_rbl_client lines are your first line of defense. By querying Spamhaus immediately, you drop 80% of botnet traffic before it even touches your disk. This saves massive I/O resources.

Step 3: Implementing SPF (Sender Policy Framework)

In 2011, you cannot send email without SPF. It is a simple TXT record in your DNS that tells the world which IPs are allowed to send mail for your domain. Without it, phishing attacks using your domain are trivial.

For your domain hosted in Norway, you need to add this DNS record:

On the server side, we need Postfix to *check* incoming SPF records to protect your users from spoofing. We use the postfix-policyd-spf-python package.

Then add this to the bottom of /etc/postfix/master.cf:

policy-spf  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/policyd-spf

And update your main.cf restrictions to use it:

Step 4: Compliance and Data Sovereignty (Personopplysningsloven)

Operating out of Norway adds a layer of responsibility. Under the Personal Data Act (Personopplysningsloven), you are responsible for the security of personal data, which includes email contents. The Data Inspectorate (Datatilsynet) is clear: you must secure transmission.

You must enable TLS. Sending unencrypted passwords over port 25 is negligent.

# TLS Parameters
smtpd_tls_cert_file=/etc/ssl/certs/mail_yourdomain_no.pem
smtpd_tls_key_file=/etc/ssl/private/mail_yourdomain_no.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes

By setting smtpd_tls_auth_only = yes, you force users to encrypt the connection before they can even attempt to authenticate. This prevents plain-text password sniffing on public Wi-Fi.

Performance Tuning for High Load

If you are pushing thousands of emails an hour, default process limits will kill you. The default_process_limit in Postfix is usually 100. If you have plenty of RAM (which is affordable on CoolVDS plans), bump this up.

Edit /etc/postfix/main.cf:

Comparison: Shared Hosting vs. Dedicated Virtualization

The Verdict

Configuring Postfix is a balance between paranoia and performance. You want to reject spam aggressively, but you cannot afford to drop a legitimate contract negotiation email from a client in Bergen.

The configuration above gives you a solid foundation. However, software configuration can only go so far if the underlying platform is unstable. Email is write-heavy. It demands low latency and high disk throughput.

At CoolVDS, we have built our infrastructure specifically to handle this kind of workload. Our data centers in the Nordic region ensure that your ping to major Norwegian ISPs is minimal, and our strict KVM/Xen isolation policy means your mail server performance won't fluctuate just because another customer is running a heavy database query.

Don't let slow I/O kill your reputation. Deploy a test instance on CoolVDS today and watch your mail queue flow like it should.