Stop Your Emails From Dying in the Spam Folder

There is a specific kind of silence that haunts a sysadmin. It’s not the silence of a well-oiled machine; it’s the silence of a mail queue that isn't delivering. I learned this the hard way back in '08 when a client's newsletter triggered a Spamhaus listing because of a misconfigured open relay. It took me 72 hours of begging ISP postmasters to get that IP clean again.

Email delivery in 2010 is a war zone. You are fighting against aggressive spam filters, botnets scanning for open SMTP ports, and the constant threat of having your server IP reputation destroyed by a single compromised PHP script. If you think setting up `sendmail` and walking away is enough, you are already blacklisted.

This guide is for the professionals who need a Postfix setup that actually works. We are going to build a secure, authenticated MTA (Mail Transfer Agent) on CentOS 5.5. We will focus on the details that matter: Reverse DNS, HELO restrictions, and why underlying disk I/O on your VPS is the bottleneck you aren't watching.

The Prerequisite: A Clean Reputation

Before you even touch /etc/postfix/main.cf, you need to verify your infrastructure. Postfix cannot fix a bad network neighborhood. If your VPS provider puts you on a subnet filled with IRC bots and warez sites, your email delivery rate will be zero.

This is where infrastructure choice becomes architectural, not just financial. In Norway, latency to the NIX (Norwegian Internet Exchange) is crucial, but IP hygiene is paramount. We deploy our mail gateways on CoolVDS instances specifically because they enforce strict outbound policies, meaning the IP block you get hasn't been burned by a previous tenant. Plus, their control panel allows instant Reverse DNS (PTR) record updates—a mandatory requirement for major ISPs like Hotmail and Gmail.

Step 1: Installation and Basic Hygiene

Forget Sendmail. It’s monolithic and a nightmare to audit. Postfix is modular, faster, and easier to secure. On a standard CentOS 5.5 build:

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

Once installed, we need to configure the identity. The biggest mistake I see? Hostname mismatches. Your hostname, your PTR record, and your Postfix banner must align. If your server is mail.example.no, your PTR must resolve to that IP.

Check your current setup with dig:

dig +short -x 123.123.123.123
# Output MUST be mail.example.no

Step 2: The `main.cf` Gauntlet

Open /etc/postfix/main.cf. We aren't using default settings here. We are locking this down.

# /etc/postfix/main.cf configuration

# NETWORK SETTINGS
myhostname = mail.example.no
mydomain = example.no
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4

# RELAY CONTROL (CRITICAL)
# Only allow the server itself to send mail without auth
mynetworks = 127.0.0.0/8

# BANNER
smtpd_banner = $myhostname ESMTP $mail_name

The "War Zone" Restrictions

This is where you stop 90% of botnets. Most spam bots are dumb; they don't follow the RFC specs properly. We use that against them. Add these restriction blocks to your config:

# 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_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

Pro Tip: Be careful with RBLs (Real-time Blackhole Lists). Start with Spamhaus (zen). It is the industry standard. If you use too many aggressive lists, you will start blocking legitimate business traffic from poorly configured Exchange servers.

Step 3: Storage Performance and The Mail Queue

When you send a blast of 10,000 newsletters, Postfix writes to the active queue, the incoming queue, and the deferred queue. It’s a lot of small file I/O operations. On a traditional shared hosting setup with over-provisioned SATA drives, your iowait will skyrocket, and Postfix will stall.

You need high IOPS. This is why for mail servers, we avoid standard rotational disks if possible. CoolVDS utilizes high-performance Enterprise SAS RAID arrays with massive caching controllers. While SSDs are still expensive for mass storage in 2010, a proper SAS RAID 10 setup ensures that your mail queue doesn't choke the CPU when you are processing logs or flushing the queue.

Step 4: Authentication with Dovecot

Never leave port 25 open without authentication restrictions. We need SASL to allow legitimate users to relay mail. We will use Dovecot for this backend.

In /etc/dovecot.conf, ensure the auth socket is exposed:

auth default {
  mechanisms = plain login
  passdb pam {
  }
  userdb passwd {
  }
  socket listen {
    client {
      path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix
    }
  }
}

Then tell Postfix to use it in main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

Restart both services:

service dovecot restart
service postfix restart
tail -f /var/log/maillog

Legal Compliance: The Norwegian Context

Operating a mail server in Norway means adhering to the Personopplysningsloven (Personal Data Act). Email logs contain metadata—IP addresses, sender info, timestamps—which are considered personal data.

Datatilsynet is strict about where this data lives. By hosting on a CoolVDS instance physically located in Oslo, you satisfy data residency requirements automatically. You aren't routing internal company emails through a server in Kansas. It keeps your latency low (often sub-10ms within Norway) and your legal team happy.

Testing Your Fortification

Don't assume it works. Test it. Use telnet to simulate a connection. If you can send mail from an outside IP without authenticating, you have failed.

telnet mail.example.no 25
EHLO test.com
MAIL FROM: <spammer@test.com>
RCPT TO: <victim@example.no>
DATA
This is a test.
.

If you see 250 OK without authentication (and you aren't on a trusted network), verify your mynetworks setting immediately.

Building a mail server in 2010 is about defense in depth. It requires a clean network foundation, rigorous configuration, and hardware that can handle the I/O punishment of log writing and queue management. Don't let your infrastructure be the reason your emails bounce. Spin up a CoolVDS instance, configure your PTR records in the panel, and take control of your delivery reputation.