11. Basic Postfix configuration and preparation for SMTP AUTH

Before we proceed to our part of the configuration we must disable a feature that was set when Tuomos Postfix RPM was installed. Remember it comes built with support for the Cyrus-IMAP Server? We're not going to use the Cyrus-IMAP Server in this HOWTO. So let's disable this setting, as we don't want it to interfere with our setup at the moment.

Postfix main configuration is done in the /etc/postfix/main.cf. Use your favorite editor to edit the file. We are going to use vi throughout this HOWTO.

[root@example.com]# vi /etc/postfix/main.cf

11.1. Disable Cyrus-IMAP setting

We will not need mailbox_transport = lmtp:unix:/var/imap/socket/lmtp because this is a setting that applies not only but especially for Cyrus-IMAP server which we will not be using. Find the line that reads mailbox_transport = lmtp:unix:/var/imap/socket/lmtp and disable it. When you are done it should read as follows:

#mailbox_transport = lmtp:unix:/file/name
#mailbox_transport = cyrus
#mailbox_transport = lmtp:unix:/var/imap/socket/lmtp

11.2. Parameters specific to your environment

Now it's time to grab some good old paper and a pencil. You will need these infos that are specific to your domain and network later. But then you should be able to focus on incorporating these.


These are the parameters that will be used in the HOWTO. You will have to provide your own.

  1. example.com

  2. mail.example.com



11.2.1. What is the primary domain (or machine) that Postfix will be authoritative for?

The $mydomain parameter specifies the local internet domain name.. If you don't run a DNS server or don't have access to one provide a domain name.


We will use example.com throughout this HOWTO as this domain is reserved for use in documentation.

When we set this value we will add it to the parameter $mydomain in main.cf.

11.2.2. What is the hostname of the machine that Postfix runs on?

The $myhostname parameter specifies the internet hostname of this mail system. Postfix needs to know its fully qualified domainname (FQDN). It will append this to all local users unless specified different by us.


When we set this value we will add it to the parameter $myhostname in main.cf.

11.2.3. What is the IP-Range of the Net that your (remote) machine stands in?

We need this to tell Postfix that the IP that your Mail client (for testing purposes) comes from is allowed to use Postfix as a relay.


When we set this parameter, we'll set $mynetworks in main.cf.

11.2.4. What is the IP address of the server that Postfix will run on?

Just note this down for the testing that will come up.

11.3. Enable your parameters

Now that you have put your parameters down, we'll edit main.cf and put them into place.

[root@example.com]# vi /etc/postfix/main.cf

11.3.1. mydomain

Search for mydomain = and you'll find #mydomain = domain.name

We uncomment the line and set the value we defined in Q1. The $mydomain parameter of this HOWTO now reads as follows:

[HOWTO SETTING] mydomain = example.com

11.3.2. myhostname

Search for myhostname = and you'll find #myhostname = host.domain.name

We uncomment the line and set the value we defined in Q2. The $myhostname parameter of this HOWTO now reads as follows:

[HOWTO SETTING] myhostname = mail.example.com

11.3.3. mynetworks

Search for mynetworks = and you'll find #mynetworks =, and two more entries for $mynetworks. We'll be using the style of the first one.

We uncomment the line and add the value we defined in Q2 and remove The $mynetworks parameter of this HOWTO now reads as follows:

[HOWTO SETTING] mynetworks =,

11.4. Enable common parameters

Remember that we disabled a few lines that came with the RPM? We will now set these in their context. It's not that Postfix needs the parameters in a certain order. It just makes it easier for us humans to find them where they belong ;-)


Tuomo fixed that in his recent SRPMS. Still you will have to enable these.

11.4.1. alias_maps

Search for alias_maps = and you'll find #alias_maps = dbm:/etc/aliases and three more lines that offer different values.

We uncomment the second line and set the value to hash:/etc/postfix/aliases. Our alias_maps parameter now reads as follows:

alias_maps = hash:/etc/postfix/aliases

11.4.2. alias_database

Search for alias_database = and you'll find #alias_database = dbm:/etc/aliases and three more lines that offer different values.

We uncomment the third line and set the value to hash:/etc/postfix/aliases. Our alias_database parameter now reads as follows:

alias_database = hash:/etc/postfix/aliases

That's it for a start. We're still away from having a sophisticated SMTP server that saves us a lot of work and is a real pain to spammers, but we're very close to fire up Postfix and send our first message.

11.5. Enable verbose logging

Postfix doesn't want to bother us with information into detailed depth unless we ask it to. Since we are still setting Postfix up and testing functions we might run into problems while doing that. So we'll have Postfix being more detailed about what's going on when it gets its work done. This will save us lot of time when we look for errors!

In order to enable verbose logging we have to append a string that is passed to the smtpd when it is started. This is done in /etc/postfix/master.cf.

[root@example.com]# vi /etc/postfix/master.cf

search for smtpd and append -v.

When your done it should look like this:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (50)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd -v

That's it for our first basic setup. Postfix should now be configured to accept messages from the local machine and from any machine who's IP matches the IP Range you specified when you answered Q3.

11.6. Add user for testmails

We'll be sending quite some mail in this HOWTO. But to whom? We need a valid user on the local machine!

[root@example.com]# adduser test
[root@example.com]# passwd test

This HOWTO sends mail to the user test. It's password is testpass.


Feel free to add your own user, but remind that you'll have to replace our values with yours throughout this HOWTO.

11.7. Start Postfix

Now it's time to start Postfix for the first time:

[root@example.com]# /etc/init.d/postfix start

You can tell it's up from the feedback the init script provides; but will the Postfix-Server die after a few seconds because something is wrong?

Let's check the process list and pipe it's output to grep which will grab for the string postfix in the output.

[root@example.com]# ps axf | grep postfix
7547 ? S 0:00 /usr/libexec/postfix/master

Still there. OK, time to send our first mail. If it's gone check /var/log/maillog for error messages.

11.8. Send testmail from local machine

First we will verify that we are able to send mail on localhost to user test. This is the simpliest testcase that we have. If we succeed we will move on sending mails to test from a Mail client that does not run on our Postfix server.

[root@example.com]# mail test
Subject: Test from localhost
Test #1

In case you are not familiar with the program mail:

Procedure 6. Send mail from CLI using mail

  1. Enter the name of the account that you want to mail to after you've entered mail

  2. Then you're prompted to enter the Subject.

  3. After this you may add the Body of your mail.

  4. You end your mail and send it away after entering a single dot '.' on a blank line

  5. and hit enter to send the mail

11.9. Check for delivery of testmail on local machine

Did Postfix deliver our mail? We'll check by simply letting less open the file in /var/spool/mail for the user test.

[root@example.com]# less /var/spool/mail/test
From root@mail.example.com Fri Mar 15 21:09:54 2002
Return-Path: <root@mail.example.com>
Delivered-To: test@mail.example.com
Received: by mail.example.com (Postfix, from userid 0)
id 029E640789; Fri, 15 Mar 2002 21:09:53 +0100 (CET)
To: test@mail.example.com
Subject: Test from localhost
Message-Id: <20020315200953.029E640789@mail.example.com>
Date: Fri, 15 Mar 2002 21:09:53 +0100 (CET)
From: root@mail.example.com (root)

Test #1

So it got delivered. Good. Let's go on to send some mail from another host.

11.10. Sending testmail from a remote host to a local user

The simpliest Mail client we can think of is a telnet client that connects to the SMTP port 25. We'll be doing it the hard way, because we want to exclude side effects that might be introduced by other, more comfortable Mail clients.

Look at the paper where you answered a few questions. It's time for Q4. We use for our Postfix server. You'll have to replace this IP with yours in the following statement.

First we will see if we can deliver mail to a local user.

Procedure 7. Telnet session: Deliver mail to a local user

  1. On your remote machine we telnet 25

  2. Postfix comes up and greets us with it's smtpd banner:

    220 mail.example.com ESMTP Postfix
  3. We say hello and introduce ourselves:

    EHLO domain.com
  4. Postfix offers it's services:

    250-SIZE 10240000
    250 8BITMIME
  5. We tell where this testmail is coming from:

    MAIL FROM:<howto@domain.com>
  6. Postfix responds:

    250 Ok
  7. We tell Postfix where this mail is going to:

    RCPT TO:<test@example.com>
  8. Postfix responds:

    250 Ok
  9. We tell Postfix that we'll be sending data

  10. Postfix responds:

    354 End data with <CR><LF>.<CR><LF>
  11. We write our message

    Test from remote host
    Test #2
  12. Postfix responds:

    250 Ok: queued as 9BB3F40789
  13. Good. The mail got delivered. Time to end this session.

  14. Postfix responds:

    221 Bye

So, we have just send our first mail from a remote host to a local user on the Postfix server. But what if we wanted Postfix not do deliver to a local user, but to relay the message for us to another user on a remote host?

11.11. Delivering mail to a remote user (Relaying)

Again we telnet 25. We'll do as before with the only difference that this time we send to a remote (aka non-local) user. Since you've just seen the procedure, we'll just summarize this session (S: = server, C: = client):

S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-XVERP
C: mail from:<user@domain.com>
S: 250 Ok
C: rcpt to:<howto@domain.com>
S: 250 Ok
C: data
S: 354 End data with <CR><LF>.<CR><LF>
C: Testmail relaying mail from user@domain.com to howto@domain.com
C: Test #3
C: .
S: 250 Ok: queued as 84BA64078A
C: quit
S: 221 Bye

Now it's up to you to send mail to a remote user through the Postfix server. But behold, don't close your telnet program after the session. You'll need some of the information that was specific to your session in a few paragraphs from now.


Why did relaying work for us?

We were able to relay a message using Postfix, because Postfix knows the remote machine is part of the network (see: mynetworks) that it permits relaying.

Before we will configure SMTP AUTH there's something that we have to take care of...

11.12. Deleting mail that can't get delivered

Remember that we've just sent a mail to howto@domain.com. Since the Postfix server in our HOWTO is not connected to the real world it hardly will be able to deliver the message. So what is Postfix doing with the mail at the moment? It's still trying, holding the mail in the queue...

Time to learn something about a helper application that comes with Postfix which is used to remove mails from Postfix' mqueue: postsuper

When you delete a mail it goes like this: postsuper -d MESSAGEID

Every message has it's unique ID provided by Postfix when it accepts a message. This MESSAGEID was given to us, when we did our telnet session. Have a look at the second last message that Postfix gave us in the HOWTO before we quit the session.

250 Ok: queued as 84BA64078A

84BA64078A is our HOWTOS' MESSAGEID.

Look at your telnet program. What is your MESSAGEID?

At the command prompt enter:

[root@example.com]# postsuper -d MESSAGEID
postsuper: MESSAGEID: removed
postsuper: Deleted: 1 message

We removed the undeliverable mail. Postfix should feel better now... ;-)

11.13. Preparing relay permissions for SMTP AUTH testing

Let's do it the XP way and define and test a test before we do the configuration. Huh? Read on...

Since our remote machine is part of the network defined in mynetworks it will be allowed to relay no matter if we configured SMTP AUTH correctly or not. This will not help us to prove, our configuration for SMTP AUTH works.

In order to gain valid results whether relaying with SMTP AUTH works the way we want it, we'll have to ensure that we are not part of $mynetworks. We do this by simply removing our subnet from the $mynetworks parameter and only let the IP range for localhost remain.

[root@example.com]# vi /etc/postfix/main.cf

We reduce mynetworks =, to mynetworks =

It should look like this:

mynetworks =

In order to let the changes be known to Postfix we must restart it.

[root@example.com]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system

Let's prove that our test setup will not allow us to relay messages. We telnet from our remote machine. Keep in mind that relaying means: Sending a message through Postfix to a remote user. The value we provide with RCPT TO: must not be a local user.

This is the transcript from our session:

S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-XVERP
C: MAIL FROM:<test@example.com>
S: 250 Ok
C: RCPT TO:<howto@domain.com>
S: 554 <howto@domain.com>: Recipient address rejected: Relay access denied1
S: 221 Bye

Relay access denied. Just the way we want it at the moment.

Postfix will not allow us to relay mails to remote users. Now that we've configured this we can go on and add SASL which will provide us with the functionality to relay even if we are not part of Postfix' network.

11.14. Summary

  • We gathered informations to use for configuration.

  • We configured Postfix to give us basic functionality.

  • We added a user for testing purposes.

  • Then we sent testmessages from localhost to a local user,

  • from a remote machine to a local user and

  • from the remote machine to a remote user.

  • We did this the hard way in order to exclude failures that could be introduced by more complex Mail clients

  • We successfully deleted a non-deliverable message from Postfix without stopping it or manually deleting files from it's mail queue.

  • We prepared Postfix to reject relaying for our network in order to prove SASL to work correctly later on.