Thirty-three years after BBN Principal Scientist Ray Tomlinson sent the first machine-to-machine email, authenticating remote salesforce staff to use corporate email servers remains a daunting configuration problem.
When Tomlinson started coding what he thought was “a neat idea”, he could not have conceived that both spammers and enterprises would make email a central part of their business operations.
That is why two problems Tomlinson never had to consider remain so vexing today: how to differentiate between mobile remote users -- sales staff -- and spammers; and how to efficiently manage back-end databases of mobile users amid the churn of staff joinings and leavings.
There are many methods of authenticating mobile users and of building the components used by each method. Faced with such choice, the best method is to get started and refine the mechanisms after gaining experience of how they work -- and how they fail.
Simple Authentication and Security Layer
Checking user ID with the Simple Authentication and Security Layer (SASL) is a common solution to the authentication part of this problem but a Web search quickly reveals many poor or incomplete descriptions of how to integrate modern SASL with enterprise mail servers. Many descriptions focus on creating a new sasldb database of mobile mail server users, which doubles the user management load.
As an easy alternative, try implementing Postfix for the mail server, and a combination of SASL2 and saslauthd to broker authentication requests to the Pluggable Authentication Module (PAM) system installed by default on major Linux distributions. This saves time in the long-run because saslauthd avoids the waste associated with the traditional SASL method of creating a separate sasldb database of mobile users.
Installing postfix
The cookbook recipe described here works with Fedora Core 1 using the Fedora-supplied postfix and saslauthd RPM packages, which were compiled against SASL2. It also works well on Red Hat 9 if you replace Red Hat’s default postfix and saslauthd packages with those supplied with the Fedora Core 1 distribution. That will involve replacing the default postfix 1.1.11-11 package with Fedora Core 1's postfix 2.0.11-5 rpm. That replacement is necessary in order to create a postfix installation that has been compiled to work with sasl2. I make the replacement clean by uninstalling Red Hat 9's default postfix installation and installing Fedora's postfix rpm from new, rather than upgrading.
You should also upgrade Red Hat 9's saslauthd – contained in cyrus-sasl RPMs - by upgrading or installing Fedora's cyrus-sasl 2.1.15-6 RPMs or later. They install with no problems on Red Hat 9.

Configuring Postfix
Once postfix is installed, configure it to a testable working state -- one where it successfully processes email from clients on its local LAN that are sent to non-local destination domains. That configuration is well-documented on the postfix Web site, but here is a summary of the key configuration settings that you can enable in postfix's /etc/postfix/main.cf configuration file to get a working system up quickly:

Set the following variables:

myhostname = mail.atyourdomain.yourtld
mydomain = yourdomain.yourtld
myorigin = $mydomain
alias_database = hash:/etc/postfix/aliases
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, $mydomain
mynetworks_style = subnet
mynetworks = , 127.0.0.1/8
relay_domains = $mydestination


Save main.cf and open /etc/postfix/aliases for editing. Look for a line that says:
root: postfix
change the “postfix” part to the account of a user on the system. You did log in as a user and then su to root, right?

Save and exit. From the command line, run the following command:

postalias /etc/postfix/aliases

Reload the postfix configuration by issuing the following command:

service postfix restart

Use “restart” rather than “reload” because because we also changed the inet_interfaces setting in /etc/postfix/main.cf. That change is not picked up by the “postfix reload” command.
Use Red Hat’s “alternatives” tool to change the smtp transport from sendmail to postfix. Do that by issuing the command:

alternatives --set mta /usr/sbin/sendmail.postfix
Assuming that postfix started without problems, we can now test that it will accept and send mail from the local subnet. To do that, log into the mail server from another machine on the subnet using telnet. Eg,
telnet 25
You should see a response like:
Trying 192.168.1.6...
Connected to 192.168.1.6 (192.168.1.6).
Escape character is '^]'.
220 mail.yourdomain.yourtld ESMTP Postfix

Type:

EHLO yourdomain.yourtld

You should see a response similar to:

250-mail.yourdomain.yourtld
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XVERP
250 8BITMIME

You are now “logged on” as a local user. To test the ability to send email to a non-local domain, type the following grey highlighted text:

MAIL FROM:
250 Ok
RCPT TO:
250 Ok
DATA
354 End data with .
Test from 192.168.1.8
.
250 Ok: queued as AB06517B9D
QUIT
221 Bye
Connection closed by foreign host.

The signal that postfix successfully accepted the message was its “Ok: queued as” response. If you see anything different, you have a problem with your basic postfix set-up that you need to troubleshoot and fix before moving on to the meat of configuring SASL.
For SASL authentication to work, we need to tell postfix to use SASL to authenticate senders of outgoing mail and we need to tell saslauthd -- the SASL authentication daemon -- to use the system's PAM authentication system as its source of information about valid users.
First, ensure that cyrus-sasl-2.11.1.15-6, or later, is installed.
Second, tell postfix to use SASL. Open /etc/postfix/main.cf and add the following lines:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain =
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains

Tell SASL to use saslauthd by ensuring that the file /usr/lib/sasl2/smtpd.conf contains the line:

pwcheck_method: saslauthd
On a modern Red Hat/Fedora distribution that line will be there by default. You also need to tell sasl to allow only login or plain credentials by adding:
mech_list: login plain
directive to the smtpd.conf file above.

Check also that there is no file called smtp.conf in /usr/lib/sasl/. This is the directive for old-style SASL1-style authentication – which can cause conflicts if it is able to process postfix's requests for smtp authentication when you really want SASL2 to process the reqeusts.
Then ensure that saslauthd knows that it should use the system's PAM mechanism by ensuring that the file

/etc/sysconfig/saslauthd contains the line:
MECH=pam

Check that the distribution's install created the following in /etc/pam.d/smtp:

#%PAM-1.0
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth

Set saslauthd to start on boot-up by typing :

chkconfig --level 345 saslauthd on

Turn saslauthd on by typing:

service saslauthd start

In order to test authentication manually, generate a user ID and password string with either:

perl -MMIME::Base64 -e 'print encode_base64(“username\0lusername\0userpassword”);'

or

printf 'username\0username\0password' | mmencode

Store a copy of the string that is created – you will need it in a moment for testing. We’ll label it “”. Telnet into the mail server from a remote host:

telnet 25

You should see a response like:

Trying 192.168.1.6...
Connected to 192.168.1.6 (192.168.1.6).
Escape character is '^]'.
220 mail.yourdomain.yourtld ESMTP Postfix

Type:

EHLO yourdomain.yourtld

You should see a response similar to:
250-mail.yourdomain.yourtld
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-XVERP
250 8BITMIME

Enter the following:

AUTH PLAIN

If you see a response like “535 Error: authentication failed”, either the string was incorrectly copied in or you have an error elsewhere. The best way to troubleshoot an error here is to keep a separate terminal console or window open and run the command:

tail –f /var/log/messages
Error messages recorded here should give you the clues you need to understand what has gone wrong.
If you see “235 Authentication successful”, then the system is working correctly. If so, you can test sending email along the following lines. Remember to put a tail on /var/log/messages if anything fails.
MAIL FROM:
250 Ok
RCPT TO:
250 Ok
DATA
354 End data with .
Test from 192.168.1.8

.
250 Ok: queued as AB06517B9D
QUIT
221 Bye
Connection closed by foreign host.

Summary
If you get this response, then you have an email server that is capable of authenticating remote users against the user IDs in its system user database. Spammers – who are not in the user database – will not be able to use the server to send mail. If you see errors, then hints about the problem will almost certainly be found in /var/log/messages.
There are several additions that will make the server more secure: adding Transport Layer Security (TLS), which uses SSL certificates to secure initial contact between the clients and mail server. This process is very well documented both by vendors and on the Web.