Using Postfix for Secure SMTP Gateways

Improve your site's e-mail hygiene and make life difficult for spammers and hackers.
Postfix Architecture: How Does Postfix Work?

To understand how postfix works, it's useful to consider its background. The main purpose for postfix's existence is sendmail's complexity. Postfix is a full-featured MTA, and therefore its core functions are the same as any other's. But postfix was written with unusual attention to:

  • Security. Postfix was designed with security as a fundamental requirement rather than as an afterthought. It's obvious that Mr. Venema has taken the lessons of history (as chronicled by CERT, bugtraq, et al.) very much to heart. For example, the system doesn't trust any data, regardless of its source. And with least privilege in a chrooted jail (see below), risks are reduced. Furthermore, protective measures against buffer overflows and other user-input attacks have been implemented. If something still fails, postfix's protection mechanism tries to prevent any of the processes under its control from gaining rights they shouldn't have. Since postfix is comprised of many different programs that function without a direct relationship to each other, if something goes wrong, the chance that such a problem can be exploited by an attacker is minimized. Of course, we all know that no system is 100% secure; the goal must be to minimize and manage risks. Postfix is definitely engineered to minimize security risks.

  • Simplicity and compatibility. Postfix has been written in such a way that setting it up “from scratch” can take as little as five minutes. When you want to replace sendmail or other MTAs, it's even better: postfix by default can use the old configuration files!

  • Robustness and stability. Postfix was written with the expectation that certain components of the mail network (the Local Area Network, the Internet uplink, the local interfaces, etc.) will occasionally fail. By anticipating things that can go wrong at either end of any given transaction, postfix is capable of keeping the server up and running in many (if not most) circumstances. If, for instance, a message cannot be delivered, it is scheduled to be delivered later, without immediately initiating a continuous retry.

A key contributor to the stability and the speed of postfix is the intelligent way in which it queues mail. Postfix uses four different queues, each one of which is handled differently (see Figure 1):

Figure 1. Postfix Queues

  • Maildrop queue. Mail that is delivered locally on the system is accepted in the Maildrop queue. Here, the mail is checked for proper formatting (and fixed if necessary) before being handed to the Incoming queue.

  • Incoming queue. The Incoming queue receives mail from other hosts, clients or the Maildrop queue. As long as e-mail is still arriving and as long as postfix hasn't really handled the e-mail, this queue is the place where the e-mails are kept.

  • Active queue. The Active queue is the queue that is used to actually deliver messages and therefore has the greatest potential risk of something going wrong. This queue has a limited size, and messages will be accepted only if there is space for them. That means e-mail in the Incoming and Deferred queues have to wait until the Active queue can accept them.

  • Deferred queue. E-mail that cannot be delivered is placed in the Deferred queue. This prevents the system from continuously trying to deliver e-mail and keeps the Active queue as short as possible in order to give newer messages priority. This also enhances stability. If the MTA cannot reach a domain, all the e-mail for that domain is placed in the Deferred queue, so that those messages will not needlessly monopolize system resources. Retry is scheduled with an increasing waiting time. When the waiting time expires, the e-mail is again placed in the Active queue for delivery; the system keeps track of retry history.

Postfix for the Lazy: A Quick and Dirty Startup Procedure

And now the part you've been waiting for (or have skipped directly to): postfix setup. Like sendmail, postfix uses a “.cf” text file as its primary configuration file called However, “.cf” files in postfix use a simple “parameter=$value” syntax. What's more, these files are extremely well commented and use highly descriptive variable names.

In fact, if your e-mail needs are simple enough, it's probably possible for you to figure out much of what you need to know by editing and reading its comments as you go.

For many users, this is all one needs to do to configure postfix on an SMTP gateway:

  1. Install postfix from a binary package via your local package tool (rpm, etc.) or by compiling from source and running postfix's script.

  2. Open /etc/postfix/ with the text editor of your choice.

  3. Uncomment and set the parameter myhostname to equal your server's fully qualified domain name (FQDN), e.g., “myhostname =”.

  4. Uncomment and set the parameter mydestination as follows, assuming this is the e-mail gateway for one's entire domain:

mydestination = $myhostname, localhost.$mydomain, $mydomain

NOTE: Enter the above line verbatim.

  1. Save and close

  2. If desired, add a line to /etc/aliases diverting root's mail to a less-privileged account, e.g., root: mick. This is also the place to map aliases for users who are served by internal mail servers (for example, mick.bauer: When you are done editing and/or adding aliases, save the file and enter the command newaliases to convert it into a hash database.

  3. Execute the command postfix start.

What did we just achieve? In only four steps, we installed, configured and started SMTP services for our machine and its local name-domain. If this machine is a firewall or an SMTP gateway on a firewall's DMZ network, it can now be used by local users to route outbound e-mail, and can be pointed to by our domain's “MX” DNS record (i.e., it can be advertised to the outside world as a mail server for e-mail addressed to our domain). We've also told it to directly process (rather than forward) mail addressed to local hosts. Pretty good return on the investment of about five minutes' worth of typing, no?

(NOTE: While this may be enough to get postfix working, it is not enough to secure it. Don't stop reading yet!)



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

how to local smtp

Anonymous's picture

Hello and thank you for the guide.

I changed inet_interfaces = localhost but it didnt worked.
I can receive but i can not send eimail
I quote the cf in order to have a look.

# See /usr/share/postfix/ for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain, $mydomain
relayhost =
mynetworks = [::ffff:]/104 [::1]/128,

mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = localhost
default_transport = error
relay_transport = error
inet_protocols = ipv4

Did i missed something?

Sending from localhost only

Robsteranium's picture

Apparently setting the following in will ensure that only localhost can send emails:

inet_interfaces = localhost