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.
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.
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:
Save main.cf and open /etc/postfix/aliases for editing. Look for a line that says:
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:
Reload the postfix configuration by issuing the following command:
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:
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,
You should see a response like:
You should see a response similar to:
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:
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-184.108.40.206-6, or later, is installed.
Second, tell postfix to use SASL. Open /etc/postfix/main.cf and add the following lines:
Tell SASL to use saslauthd by ensuring that the file /usr/lib/sasl2/smtpd.conf contains the line:
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:
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
Enter the following:
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:
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.
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.
Find your next job with techworld jobs