Postfix Software configured as an Anti Spam (UCE) Gateway

Created on 2007-08-28 by Rainer Gerhards.

This article has been converted from a presentation file, so parts from it might be a little bit brief in their description. Minimal Knowledge to understand & use Postfix as an Anti-UCE Gateway in a fairly secure manner on Red Hat is required to understand and follow these instructions.

Table of contents

1. Security Basics
2. Removing unnecessary Packages
3. Keeping the Machine Updated
4. Configuring Postfix
5. After Changing Config Files...
6. What is Chroot?
7. Mail Basics
8. Understanding Anti-UCE
9. Blackhole lists
10. Envelope Checks - helo, sender and recipients
11. Body Checks
12. Use a Backup MX?
13. Postfix as Relay
14. That's it?
15. Copyright

Security Basics

• Be protected by a firewall (either Linux packet filter or external one)
• NEVER logon directly as root (use su instead)
• Run only services needed
• Make sure you are periodically patching your system
• Many more principles to apply, of course...

Removing unnecessary Packages

• No text mode setup like SuSe Yast
• Use rpm to modify installed packages
• Search the web for dependencies
• Remove everything not needed or at least do not run it. If something is missing, you will notice that – you can always re-enable it.

Go to TOP

Keeping the Machine Updated

• Many patches & vulnerabilities each day
• With Red Hat, yum works well
• Download from http://linux.duke.edu/projects/yum/index.ptml
• Very mission critical systems should be kept updated by an automatic process with manual control – yum is probably not the answer in this context

Go to TOP

Configuring Postfix

• Via text files, by default in /etc/postfix
  • main.cf – main config file, references other files (named by user)
  • Order of directives in this files IS important (messing up is an easy way to get an open relay)
  • Many samples/descriptions can be found in the web
  • See http://www.postfix.org/ for more
  • Transport.cf specifies services settings, especially if run chrooted (default)

Go to TOP

After Changing Config Files...

• You need to “compile” tables (not regexp or pcre) with postmap
• You need to restart postfix with “postfix reload” (see man postfix)
• Be sure to review the logs (at least /var/log/maillog) after activating a new config – if you introduced new Anti-UCE settings, be sure to have an extended look at the maillog.
• All files in /usr/sbin (in case you have no path set ;-))

Go to TOP

What is Chroot?

• An additional safety measure
  • System root is changed to program directory
  • No necessarily needed if OS is not hardened otherwise
  • On by default in RedHat RPMs
• IMPORTANT: many OS files must be mirrored, otherwise Postfix won't work.
  • Typical trouble spot resolv.conf, which must be mirrored – otherwise name resolution does not work

Go to TOP

Mail Basics

• Envelope
  • Server to server communication
    • Server name (helo), sender, recipient
• Body
  • Seen by the mail user agent
    • To:, From: , Subject: sevral others
  • Not necessarily matching envelope informaton
    • EG BCC sender only seen in envelope (by design)

Go to TOP

Understanding Anti-UCE

• Most checks done on the envelope
• Body checks are costly
• Not all UCE can be detected by postfix
  • Detect the bulk in postfix, let the rest analyze by anti-spam tools (more costly)
  • Use eg. dspam or spamassasin
• There will be few false positives, and the recipient will NOT see them

Go to TOP

Blackhole lists

• List open
  • Smtp servers
  • Proxies
  • Eventually dial-up-links
• Block communication deliberately, forcing “misbehaving” Internet Admins to take action – some collateral damage done
• Keep updated on those you use (died services, too much blocked)

Go to TOP

Envelope Checks - helo, sender and recipients

• helo
  • FQDN
  • Not OURSELFS! (often our or other MX's IP used)
  • Enforcing a VALID domain breaks too much
• sender
  • Sender domain must exist (broken by Versign's global wildcard record – upgrade to postfix 2, latest build if Verisign re-introduces it...)
  • Email address must be syntactically correct
  • Blacklist known spam addresses (some are foolish enough to actually use their real address – but be careful with many users – better done by anti-spam tools).
• recipients
  • Either (preferred) let postfix know all valid users or those that you know to be invalid.

Go to TOP

Body Checks

• Body checks will not save you from receiving the message
• By default, Postfix only scans the first 50 KB – can be overriden in config file
• detect some specific Subjects
• good for viruses, eg SWEN
• good for blocking attachments of certain type (postfix 2 is your friend!)

Go to TOP

Use a Backup MX?

• Many postfix users recommend against it, if the backup is not under your direct control (because you can't enforce the same Anti-UCE rules, which can mess up your config and create big troubles.
• Should not really be needed – almost all SMTP servers are nowadays configured to retry 3..5 days

Go to TOP

Postfix as Relay (quick & dirty guide)

• Do not list relayed domains in mydomain
• List them in relaydomain
• Use transport_maps to set ultimate destination for inbound mail
• Outbound relay can make sense to protect eg Exchange against the Internet (prevents exploitation of Exchange as it never has contact with a remote system) – great for DMZ

Go to TOP

That's it?

• Of course not...
  ... but that's it for now. This is just a quick presentation, covering some basic for an actual case. If I find time, I will probably update it.
• In the meantime, just google for Postfix and/or follow the postfix mailing list
• Presentation was written on 2003-10-28

Go to TOP

Copyright

• This presentation is put under the GPL.
• Use it as you own risk, free of charge.
• But you must include this copyright page as well as credits to Rainer Gerhards ;-)

Go to TOP