Updating Sendmail in Redhat 6.2 to allow SMTP authentication - By Bruce Garlock - 9/26/02

We currently use Verizon DSL services for our company wide Internet access. I have a "homegrown" router/firewall/gatewall which is essentially a RedHat 6.2 box, kept upd2date with all patches. Recently, an email was sent to Verizon customers regarding the sending of emails. The email stated that all outgoing emails to their SMTP server would require authentication in the near future. Since I use Sendmail on our gateway machine, to send all emails through sendmail's "smart host" feature, I figured it must be simple enough to add SMTP authentication. Boy, was I wrong. Although this function is integrated into the latest RedHat releases of Sendmail, it is not in the 6.2 releases. I still run 6.2 because I have found it to be rock solid. I have 7.3 running on some development machines, but I still don't like the way the 2.4 kernel deals with virtual memory. I have 768MB of RAM on one machine, and it still dips into SWAP after 24 hours. The machine is not doing much, so I have no idea why. 6.2 with the 2.2.19 kernel from RedHat does not dip into SWAP, unless it has too. That's a subject for another article, though.

Since I don't want to update this machine, due to time restraints in getting SMTP authentication working, I set out on how to update the existing Sendmail that RH 6.2 supports. I started searching google news, to see what I could come up with, and was inspired by this post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=d79435b05b76c67c&rnum=1

The post gets off track at the end, but the guts are there to get what I need done. The key was to first install the cyrus-sasl libraries, so I could rebuild the Sendmail source rpm with sasl included. I suppose you can do all this from the source, but I chose to grab the source RPM's from RedHat 7.3. This way, if a security bulletin was issued against RH 7.3, I would know to update the 6.2 builds of these packages. Not ideal, but I think it's a lot easier to maintain than building from source. This is where it gets tricky. Since cyrus-sasl requires an updated pam version, which provides pam-devel (which cyrus-sasl needs), I grabbed the following files from a RH 7.3 distribution. Make sure to grab the source, so we can properly link everything on the RH 6.2 machine:

pam-0.75-32.src.rpm
cyrus-sasl-1.5.24-25.src.rpm
 

Then, I simply built the pam source RPM like this:

rpm --rebuild pam-0.75-32.src.rpm
 

I did have to make sure glib-devel was installed (on my machine), since this version of pam depends on it. You can always grab glib-devel from your RH 6.2 distro CD. After the build is done, go ahead and install the resulting binaries:

[root@linux]# cd /usr/src/redhat/RPMS/i386
[root@linux]# rpm -ivh pam-0.75-32.i386.rpm pam-devel-0.75-32.i386.rpm

Preparing...                ########################################### [100%]
   1:pam                    ########################################### [ 50%]
   2:pam-devel              ########################################### [100%]
 

Now that the new pam is built, and we now have the pam-devel to satisfy cyrus-sasl, we can begin building that:

rpm --rebuild cyrus-sasl-1.5.24-25.src.rpm
 

After the build is complete, install the binaries in /usr/src/redhat/RPMS/i386:

[root@linux i386]# rpm -ivh cyrus-sasl-*.rpm
Preparing...                ########################################### [100%]
   1:cyrus-sasl             ########################################### [ 20%]
   2:cyrus-sasl-devel       ########################################### [ 40%]
   3:cyrus-sasl-gssapi      ########################################### [ 60%]
   4:cyrus-sasl-md5         ########################################### [ 80%]
   5:cyrus-sasl-plain       ########################################### [100%]
 

We now have what we need to rebuild the Sendmail RPM from source, and include SMTP authentication. To do this, you need to grab the latest updated Sendmail source RPM from RedHat's ftp site. The most current version of Sendmail for RH 6.2 (at the time of this writing) is: sendmail-8.11.6-1.6.y.src.rpm

Now we have to be a little creative. Sendmail doesn't seem to utilize a configure script, so after reading the above post on usenet, I found out that I had to hack in, and build Sendmail with sasl support. First, install the Sendmail source RPM:

[root@linux]# rpm -ivh sendmail-8.11.6-1.6.y.src.rpm
   1:sendmail               ########################################### [100%]
 

Don't worry - this does not overwrite your current Sendmail install. The source to Sendmail is now installed, and we can now pass the right options to build in sasl support. The key here is in the above usenet post. If you go to

 /usr/src/redhat/SOURCES
 

and we need to edit the file that is used to build Sendmail. Use vi or your favorite text editor, and edit: sendmail-8.11.0-redhat.patch We need to add two settings to this file to build in sasl support. First, add

-DSASL
 

to the confENVDEF section. Then, we need to add

-lsasl
 

to the confLIBS section. Your resulting file should look like this:

--- sendmail-8.11.6/devtools/OS/Linux.redhat    Thu Dec 14 17:39:39 2000
+++ sendmail-8.11.6/devtools/OS/Linux   Thu Aug 23 13:53:24 2001
@@ -9,6 +9,8 @@
 define(`confMTLDOPTS', `-lpthread')
 define(`confLDOPTS_SO', `-shared')
 define(`confSONAME',`-soname')
+define('confSBINGRP', 'mail')
+define('confSBINMODE', '6755')


 ifelse(confBLDVARIANT, `DEBUG',
--- sendmail-8.11.6/sendmail/daemon.c.redhat    Fri Jul 20 20:45:58 2001
+++ sendmail-8.11.6/sendmail/daemon.c   Thu Aug 23 13:44:00 2001
@@ -2973,7 +2973,7 @@

        /* get result */
        p = &ibuf[0];
-       nleft = sizeof ibuf - 1;
+       nleft = sizeof(ibuf) - 1;
        while ((i = read(s, p, nleft)) > 0)
        {
                p += i;
--- sendmail-8.11.6/redhat.config.m4.redhat     Thu Aug 23 13:44:00 2001
+++ sendmail-8.11.6/redhat.config.m4    Thu Aug 23 13:44:00 2001
@@ -0,0 +1,10 @@
+define(`confMAPDEF', `-DNEWDB -DNIS -DMAP_REGEX')
+define(`confENVDEF', `$(RPM_OPT_FLAGS) -Wall -DXDEBUG=0 -DSASL -DUSE_VENDOR_CF_PATH=1')
+define(`confLIBS', `-lnsl -lcrypt -lgdbm -lsasl')
+define(`confLDOPTS', `-s')
+define(`confMANOWN', `root')
+define(`confMANGRP', `root')
+define(`confMANMODE', `644')
+define(`confMAN1SRC', `1')
+define(`confMAN5SRC', `5')
+define(`confMAN8SRC', `8')
 

Save the file, and quit. Now we are ready to rebuild the Sendmail for RH 6.2, with sasl support compiled in:

[root@linux]# cd /usr/src/redhat/SPECS
[root@linux]# rpm -bb sendmail.spec
 

After the build is complete, install the resulting binaries, as discussed previously. Since you most likely already have Sendmail installed, you will need to "force" the "upgrade" to the Sendmail built with sasl support. I would make a backup copy of your /etc/sendmail.cf at this point, just in case.

[root@linux]# cd /usr/src/redhat/RPMS/i386/
[root@linux]# rpm -Uvh sendmail-8.11.6-1.6.y.i386.rpm sendmail-cf-8.11.6-1.6.y.i386.rpm 
sendmail-doc-8.11.6-1.6.y.i386.rpm --force
 

Now we have a version of Sendmail that supports authentication. The next part is to tell Sendmail about which server we are going to authenticate with, before we deliver the mail. I am by no means a Sendmail expert. I have the bat book, and fall asleep every time I start reading it. I also cheat when it comes to configuring Sendmail. While the bat book states that you should always rebuild the sendmail.cf file with m4, I always hack in my configurations right into the sendmail.cf file. I recommend you don't. Although I have not run into any trouble, it's always best that you follow the documentation. I'm also sure I'm not the only one who cheats, since I have read posts of others who have modified the sendmail.cf directly. Regardless, the options for authentication are already in the sendmail.cf file that comes with RedHat. Don't ask me why they didn't build Sendmail with sasl support, since they already have support for it in their cf file. You want to look for 3 lines:

# list of authentication mechanisms
#O AuthMechanisms=GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

# default authentication information for outgoing connections
#O DefaultAuthInfo=/etc/mail/default-auth-info

# SMTP AUTH flags
#O AuthOptions
 

You need to uncomment each of them, and make a few changes. Since verizon still uses plain text authentication, we need to tell Sendmail about that. After making the changes, my section in the sendmail.cf section looks like this (note the PLAIN as part of the AuthMechanism):

# list of authentication mechanisms
O AuthMechanisms=PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

# default authentication information for outgoing connections
O DefaultAuthInfo=/etc/mail/default-auth-info

# SMTP AUTH flags
O AuthOptions=A
 

Now we just need to setup the /etc/mail/default-auth-info file, and tell Sendmail our SMTP username/password. This file is simple enough. It's 4 lines: username,username,password,realm Mine looks like this:

username
username
password
outgoing.verizon.net
 

Restart Sendmail, and you should now be authenticating properly with the SMTP server! If something does not work, you need to troubleshoot Sendmail. That is beyond the scope of this article, but if the mail does not make it out, it is probably still in the queue. I usually run Sendmail manually with a verbose setting to see what's going on:

sendmail -v -q
 

That should give you some indication of where things are going wrong.

Well, that about sums it up. This turned out to be much easier than updating the entire machine, which was the road I started to head down, when I initially tried to rebuild the Sendmail that came with RH 7.3 on the 6.2 machine. I started running into all sorts of dependency issues. This method caused the least amount of pain, and gave me the results I needed to keep the mail moving.

In case your clients are Netscape Messenger clients, you need to make one more change to the lipref.js file, on each client. Because Netscape is a little broken when it comes to SMTP auth, Netscape thinks it must send a username after getting a response back from sending the 'EHLO' to sendmail. Since all we were trying to accomplish was SMTP authentication with the smarthost, we didn't want to have and change all the clients. Netscape 7, and the Mozilla mailer, do not seem to be affected by this little bug. I have not yet tested with other e-mail clients, but from what I have seen on usenet, only Netscape 4.x messenger is affected. In order to disable this behavior, add the following line to liprefs.js:

user_pref("mail.auth_login", false);
 

Luckily, I have roaming profiles setup, and adding these to all of our companies NS 4.x series users should be trivial.

This fix was found here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=b909b2cd43404d4f&rnum=8

Publish your articles, comments, book reviews or opinions here!

© September 2002 Bruce Garlock. All rights reserved

More Articles by Bruce Garlock

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.