Mobile Users with Postfix
Server Training - Mail Server

SMTP authentication is important because you may use it to verify mail clients independent of their IP Addresses.  Without SMTP Authentication only those IP ranges indicated in the mynetworks parameter will be allowed to connect.

There are basically 4 methods of allowing access to mobile users.
1.SMTP-after-POP and SMTP-after-IMAP
2.SMTP authentication
3.Certificate-based relaying


The SMTP-after-POP and SMTP-after-IMAP refers the issue of authentication to the POP or IMAP server.  In this process once the mail client has authenticated the POP or IMAP server will record the IP Address and save it in a database.  These IP Addresses remain in the database so they may be accessed again when th email client attempts to relay mail.  The SMTP server then looks up the address in the database and allows the transfer if the address exists.  These addresses are only saved for a short time.  Unfortunately, the configuration issues are complex to make this happen and the IP Addresses can easily be spoofed.  

Certificate-based relaying is based on the certificate that a client sends to the server to authenticate.   Once verified the mail client is allowed to relay.  The unfortunate issue here is that many email clients do not support TLS authentication.

VPNs work fine however this is a lot of setup and training for employees just for mail.
The easiest method is to use SMTP authentication.  This SMTP authentication is accomplished using the Cyrus SASL or Simple Authentication and Security Layer.  SASL has three layers that must be configured; the authentication interface, the mechanism and the method.  

SASL Authentication Interface
The Authentication Interface is a way for the server to communicate with the client to verify the service is available and to tell them which mechanism can be used.  The SASL itself does not have a specific mechanism for authentication but rather depends on the service and protocol to alert the client to the authentication.  During an email connection, the client and server authentication is done during the SMTP dialog.
Install saslauthd

8 Week Course for $499.95  ORDER NOW

 Don't Outsource Your Mail Server, Learn how to run it yourself!
Postfix Training

We specialize in helping companies become independent of outsourcing Linux services.
8 Week Course for $499.95  ORDER NOW



CentOS Install

yum install saslauthd

Here are the SASL  programs that you will use to set up the connections.  They are all found in the /usr/sbin directory.

Change the permissions on the database for saslauthd.

chown root:postfix /etc/sasldb2
chown -R root:postfix /etc/sasl2

Checking Postfix for SMTP AUTH Support

If you want to do SMTP Authentication, which allows authorized mail clients that use dynamic IP Addresses to send messages through the mail server, you first need to verify that you have the necessary support.  Use this command and look for the highlighted line to indicate support is available.

 ldd `postconf -h daemon_directory`/smtpd => /usr/lib/ (0x0026f000) => /usr/lib/ (0x00154000) => /lib/ (0x00414000) => /usr/lib/ (0x006d4000) => /lib/ (0x00e19000) => /lib/ (0x00d08000) => /usr/lib/ (0x00111000)
You can see that is the Cyrus SASL version.  This shows you the version and that SASL support has been compiled into the Postfix program.  

Server-Side Authentication
You must configure the mail server so that it can provide SMTP AUTH  to mail clients.   This will allow users who have changing IP Addresses to connect to the server without creating an open relay.  Postfix by default will not allow connections unless the IP Addresses are defined in the mynetworks parameter.  However, this does not work well with remote users who connect from different locations which use DHCP to provide the addresses.
The smtpd_sasl_auth_enable must be set in the file to enable SASL.

smtpd_sasl_auth_enable = yes

Now you need to set the SASL mechanism that will be used to authenticate users.  There are a number of options available.  These options are controlled by the smtpd_sasl_security_options parameter.

noanonymous – will not allow anonymous users
noplaintext – eliminates all plain text mechanisms like PLAIN and LOGIN
noactive – will not allow mechanisms subject to dictionary attacks
nodictionary – excludes mechanisms that can be broken by dictionary attack
mutual_auth – permits mechanisms that provide mutual authentication only

Here the postconf command lists the default settings.  You should always have noanonymous listed at least!

# postconf -d smtpd_sasl_security_options
smtpd_sasl_security_options = noanonymous

SMTP AUTH and Microsoft Outlook Express

There are a number of issues with Microsoft mail products, one of which is that they cannot perform SMTP AUTH without some modifications.  One modification is to tell Postfix you will be using this kind of client.  Add this line to the

broken_sasl_auth_clients = yes

When you add the support for broken clients you will see a new line added to the AUTH line during a SMTP dialog.

# telnet localhost 25
Connected to localhost.localdomain (
Escape character is '^]'.
220 ESMTP Postfix
250-SIZE 10240000
250 DSN

SASL Realm
Some documentation may tell you to setup a realm for SASL.  However, with the newer versions such as you see below for CentOS you do not need to set up a realm.

# saslauthd -v
saslauthd 2.1.22
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap

Verbose Logging
It may help to turn on  verbose logging when you are working with the SASL setup as it is often a difficult process.  Just add the “-v” option after smtpd in the file and save.
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ========================================================
smtp      inet  n       -       n       -       -       smtpd -v

Authenticate a Test User
The purpose of this authentication is to try to duplicate the way a Microsoft Outlook or Outlook Express will authenticate to the server.  This exercise is not designed to create the passwords for the users but to emulate what Outlook does.  If you want to authenticate a test user you will need to take several steps.  First create a user, in this example tom.  Give tom a password, in the example “mypass”.  Next, in order to authenticate it must be converted into base64 so you can use this command, note the user and password are included in the command.
# perl -MMIME::Base64 -e 'print encode_base64("tom\0tom\0mypass");'

Now use telnet to test .the user you created.  The line that begins with AUTH PLAIN will contain the base64 password.

# telnet localhost 25
Connected to localhost.localdomain (
Escape character is '^]'.
220 ESMTP Postfix
250-SIZE 10240000
250 DSN
235 2.0.0 Authentication successful

Test to verify that relaying is allowed.

# telnet localhost 25
Connected to localhost.localdomain (
Escape character is '^]'.
220 ESMTP Postfix
250-SIZE 10240000
250 DSN
235 2.0.0 Authentication successful
MAIL FROM: < This e-mail address is being protected from spambots. You need JavaScript enabled to view it >
250 2.1.0 Ok
RCPT TO: < This e-mail address is being protected from spambots. You need JavaScript enabled to view it >
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
testing SMTP AUTH
250 2.0.0 Ok: queued as 7CAB212F778
221 2.0.0 Bye

You should receive an email at the address that you place as the RCPT TO:.

Relay Permissions
Now you must allow the relay permissions for the users who will use SASL authentication.

Edit /etc/sysconfig/saslauthd

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled to use.

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.

Verify sasauthd is started with this command:

service saslauthd status

If the status is off it will need to be started with the command below.

Start saslauthd

# service saslauthd start
Starting saslauthd:

In order to use SASL authentication you must modify the file.  These lines must be added at the end of the file.

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

smtpd_recipient_restrictions =

Edit /usr/lib/sasl2/smtpd.conf
Verify this line exists in the file and then restart saslauthd.
pwcheck_method: saslauthd

/etc/init.d/saslauthd restart
Starting saslauthd:                                  [ OK ]

Check Supported Authentication Backends
saslauthd as a stand-alone daemon needs to communicate with specific backends.  It is important to know which backends are supported by the saslauthd daemon before making a choice.  By using the following command you will see a list of supported backends.

saslauthd -v
saslauthd 2.1.19
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap

Note: These authentication mechanisms are not the same as the SMTP AUTH mechanisms.

Verify the State Directory

A state directory is required by saslauthd and is usually located in the /var/run/saslauthd which will contain these files:
mux  mux.accept

You can check for the working aspect of this state directory with this command:
saslauthd -a shadow -d
saslauthd[15952] :main            : num_procs  : 5
saslauthd[15952] :main            : mech_option: NULL
saslauthd[15952] :main            : run_path   : /var/run/saslauthd
saslauthd[15952] :main            : auth_mech  : shadow
saslauthd[15952] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[15952] :detach_tty      : master pid is: 0
saslauthd[15952] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[15952] :main            : using process model
saslauthd[15952] :have_baby       : forked child: 15953
saslauthd[15952] :have_baby       : forked child: 15954
saslauthd[15952] :have_baby       : forked child: 15955
saslauthd[15952] :have_baby       : forked child: 15956

This verifies that the state directory exists and is functioning properly.

Creating SASL Passwords
In order to use SASL you must create passwords with the program.  Notice that the text postconf -h myhostname is enclosed with a tick `.

saslpasswd2 -c -u `postconf -h myhostname` mike
Again (for verification):

Verify All Services Are Running
It is important to verify that all services are running before you start troubleshooting.
Here is an example of starting the three services that are needed.

# service postfix start
Starting postfix:                                          [  OK  ]
# service dovecot start
Starting Dovecot Imap:                                     [  OK  ]
# service saslauthd start
Starting saslauthd:                                        [  OK  ]

Run These Services at Startup
chkconfig - -level 35 postfix on
chkconfig - -level 35 dovecot on
chkconfig - -level 35 saslauthd on

Dovecot is an IMAP and POP3 server that is written in C to be used with Linux.  Dovecot was written with a focus on security.  It will work with the standard mailbox formats like mbox and Maildir and is compatible with most implementations of IMAP including any standards for UW-IMAP or Courier IMAP.

One of the features that draws many people to Dovecot is that it is easy to setup.  If you are going to use /etc/passwd for user passwords, there is very little to do.  

Dovecot maintains index files that help it find the information that it needs.  These indexes provide it with quick access to mailbox information and as a result provide a scalable messaging system that has been tested to over 367,000 messages.  

Another useful feature of Dovecot is that it has small memory needs as most of the required memory goes to the mmap()ed index files.  Connections are handled as separate processes which each incur about 100kB of swappable memory.

Dovecot has been designed as a fail safe program, in other words, Dovecot does sanity checks of all data before it uses it to avoid problems.