Stop Letting Your Emails Rot in the Junk Folder

If you have ever tried to debug a sendmail.cf file at 3 AM while a client screams about lost invoices, you know the specific flavor of hell that is email administration. Most sysadmins today are soft. They rely on shared hosting relays or expensive appliances, then wonder why their critical alerts get blocked by Spamhaus.

Here is the hard truth: Ownership is the only path to reliability.

In the Norwegian market, where businesses rely on swift communication with local ISPs like Telenor and NextGenTel, latency and reputation are everything. If your mail server sits on a dirty IP range in a bargain-bin datacenter, you are dead before you even send the EHLO packet. Today, we are building a Postfix server on CentOS 5.5 that is fast, secure, and compliant with the Personal Data Act (Personopplysningsloven).

The Prerequisites: Don't Skimp on the Metal

Before touching a config file, look at your infrastructure. Email is I/O intensive—not for bandwidth, but for log writing, queue processing, and spam filtering.

• Clean IP Address: You need a Static IP with a neutral reputation. Shared hosting IPs are often blacklisted because your "neighbor" decided to spam Viagra ads.
• Reverse DNS (PTR): This is non-negotiable. If your IP doesn't resolve back to your hostname, major providers like Hotmail and Gmail will drop your packets. CoolVDS offers full control over PTR records in our panel, which is why I use them for mail nodes.
• Disk Speed: Queue files can pile up. While standard SATA is fine for storage, I recommend looking for providers offering SAS 15k RAID-10 or the emerging Enterprise SSDs for the mail spool /var/spool/postfix.

Step 1: Installation and The Death of Sendmail

First, purge Sendmail. It is a relic. We are replacing it with Postfix—modular, faster, and actually readable by humans.

[root@server ~]# yum remove sendmail
[root@server ~]# yum install postfix cyrus-sasl cyrus-sasl-plain

Once installed, we configure the alternatives system to ensure the OS knows who is boss:

[root@server ~]# alternatives --set mta /usr/sbin/sendmail.postfix

Step 2: Configuring main.cf for the Real World

Open /etc/postfix/main.cf. Do not just copy-paste; understand what you are typing. A misconfigured relay is an open door for spammers to hijack your bandwidth.

# /etc/postfix/main.cf
myhostname = mail.yourdomain.no
mydomain = yourdomain.no
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# The most important lines for security
ynw_directory = no
message_size_limit = 20480000

# Prevent open relay
mynetworks = 127.0.0.0/8
relay_domains = $mydestination

Pro Tip: Set your myhostname to match your Reverse DNS exactly. If CoolVDS assigns you vps-123.coolvds.com, change your PTR record to mail.yourdomain.no first. Consistency builds trust with spam filters.

Step 3: SASL Authentication (Locking the Door)

You want your mobile users to send mail via this server, but you don't want the rest of the internet doing it. We use Cyrus-SASL for this.

Edit /etc/postfix/main.cf again to add:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Ensure the saslauthd service is running and set to start on boot. In 2010, we don't have fancy process managers, so we use good old chkconfig.

[root@server ~]# service saslauthd start
[root@server ~]# chkconfig saslauthd on
[root@server ~]# service postfix restart

Step 4: The Deliverability Trinity (SPF, Reverse DNS, Logs)

Configuring the daemon is only half the battle. The rest is DNS.

SPF Records

Sender Policy Framework (SPF) tells the world which IPs are allowed to send email for your domain. Add this TXT record to your DNS zone:

This says: "Only my MX records and this specific IP can send mail. Fail everything else." This is crucial for protecting your domain's reputation.

Norwegian Compliance & Datatilsynet

Operating in Norway means respecting the Personal Data Act. You are processing personal data (email addresses). Ensure your logs are rotated and secured. Do not store logs indefinitely.

Check your log rotation in /etc/logrotate.d/syslog. I usually keep 4 weeks of mail logs for debugging, which satisfies most audit requirements without hoarding data.

Why Infrastructure Matters

I recently migrated a client from a shared host in the US to a CoolVDS Xen instance here in Norway. Their email delivery time to Statoil and DNB dropped from 4 seconds to roughly 200ms. Why? Peering.

CoolVDS peers directly at NIX (Norwegian Internet Exchange). When your server talks to another Norwegian mail server, the traffic stays local. It doesn't bounce across the Atlantic. Furthermore, using KVM or Xen virtualization (which CoolVDS uses) provides true kernel isolation, unlike OpenVZ where a neighbor's high load can stall your mail queue processing.

Building a mail server is a rite of passage. It forces you to understand DNS, TCP/IP, and security boundaries. Get a clean VPS, set your PTR records, and take back control of your communications.

Ready to deploy? Spin up a CentOS 5 instance on CoolVDS. The network stability alone is worth the migration.