This Howto is meant to help demystify sendmail and get it to do some really cool stuff, in particular SMTP AUTH. Although this is meant to be Slackware specific, 95% of the stuff will work on any distro. This howto has been broken up into 4 main parts for ease of reading, they are Introduction, Compilation & Installation, Client-side SMTP AUTH and Server-side SMTP AUTH.

Introduction

In case you have no idea what SMTP AUTH is good for, basically it allows you to provide relaying to people outside your trusted network by authenticating them in a secure manner. This is in contrast to an "open relay" which will allow anybody, anywhere to use your server to email whomever they want. As you can imagine, an open relay is a spammers dream as they are using YOUR precious resources to spam ten million people with your IP as the source....a very very bad thing!

As with most internet services we must break them down into two categories: client and server. Client-side SMTP AUTH is useful when your ISP's mail server requires you to authenticate yourself in order to relay through it using SMART_HOST; if you are on DSL you probably know what I’m talking about. Now this begs the question "why bother using the ISP's mail server when I’m setting up my own?" Good question, here is the answer. If you are like me and you run your own sendmail server using a residential (usually dynamic) IP, chances are 80% of your mail is going to be either bounced or plain out dropped due to SPAM filters running on most enterprise SMTP servers. Fortunately there is a way around this and that is by telling sendmail to relay all its outgoing mail to your ISP's SMTP server and have them send the mail on your behalf via SMART_HOST.

Server-side SMTP AUTH is exactly what the ISP's mail server is doing in the client-side example. It allows you to give relay access to only those that you specify, usually users listed in your /etc/passwd file. Unfortunately many email clients, Outlook and Outlook Express are especially notorious, will send the SMTP AUTH password in plain text format which is a bad thing. This is where the STARTTLS command comes into play. It will encrypt the password end to end by use of SSL so that if anybody were to sniff packets on our network they would only see garbage.


Compilation & Installation

Cyrus SASLv2


UPDATE!
As of Slackware 11, an official Cyrus SASL package as well as sendmail 8.13.4 comipled with SASL support is included. So if you are on Slackware 11 or newer, you can skip down to the Client-Side SMTP AUTH + SMART_HOST section

Unfortunately the version of sendmail that comes with Slackware 10 does not have SASL support compiled into it, nor does Slackware 10 come with the SASL libraries which is required to get SMTP AUTH to work. Thus the first step to getting client or server side SMTP AUTH to work is to compile a few things. Don’t worry, its a lot easier than you think and I will step you through the whole process.

The first thing we need to do is get Cyrus SASL, the latest version at this time of writing is 2.1.19 and the tarball can be found here ftp://ftp.andrew.cmu.edu/pub/cyrus-m...-2.1.19.tar.gz

Now we need to unpack this tarball, I usually build my programs in /usr/src, but feel free to build it where ever you'd like.
Once unpacked you should now have a directory called cyrus-sasl-2.1.19, go ahead and 'cd' into it.

Now before compiling this program we must pass it a few configure arguments, and this is probably where it will start to become Slackware specific. Copy and paste the following command
After that is complete, go ahead and run make to start the build process. Once it's completely built, you have two options on what to do next. You could run make install which will put the necessary files where they need to be, or you can use the command checkinstall -S instead, which will create a slackware tgz file and install it for you. I prefer to use the checkinstall command because if you ever want to remove Cyrus SASL for whatever reason, all you have to do is use the removepkg command and it will be cleanly removed. Otherwise you have to go hunting for all the files yourself. If you don’t have checkinstall already, I strongly urge you to download it at http://asic-linux.com.mx/~izto/checkinstall

Finally all that is left to do is quickly configure SASLv2 to work with Sendmail. To do this we must first create the file /usr/lib/sasl2/Sendmail.conf and then open it up in your editor of choice, please take careful note of the capital 'S' in 'Sendmail.conf'

Once the file is open, copy and paste the following and save it
Sendmail

Now that the SASL libraries are fully installed, our next task is to recompile Sendmail and tell it to include SASL support. Building sendmail is usually a daunting task, but luckily for us this process only takes a few minutes to do because we can just reuse the slackware build scripts and slightly alter them to our liking.

First lets download all the old slackware build scripts and files for Sendmail. Since I do all my building in /usr/src, I first created the directory /usr/src/sendmail Here is a link to a mirror I use, feel free to use whatever mirror is closer to you, the path should remain the same. http://slackware.osuosl.org/slackwar...ce/n/sendmail/. Copy over the entire directory contents to /usr/src/sendmail

Since we are recompiling sendmail, we might as well recompile the latest version as it doesn’t cost us any extra time. As of this writing the latest version is 8.13.1. We need to download both the tarball and its signature file which can be found here ftp://ftp.sendmail.org/pub/sendmail/....8.13.1.tar.gz and here ftp://ftp.sendmail.org/pub/sendmail/...3.1.tar.gz.sig. Once both files are downloaded, go ahead and delete their respective 8.12.11 older versions.

In order to get the new version to compile, we need to alter both the SlackBuild-sendmail and SlackBuild-sendmail-cf build scripts to point to the right version. Go ahead and open up each one in your favorite editor and alter the following code:
Make sure you make the changes above to both build scripts and dont mess with the ARCH variable in either script.

Our next step is to tell sendmail that we would like to have SASL support built into it. In order to do this we need to edit the site.config.m4 file. Lets make the following changes marked in red:
Well, now its finally time to rebuild sendmail. But before we do let us make sure that the necessary files are actually executable. Run the command chmod u+x on the files SlackBuild, SlackBuild-sendmail and SlackBuild-sendmail-cf.

Once that is done, simply run the following command and cross your fingers that it builds with no errors:
If everything worked, you should get two tgz files located in your /tmp directory called sendmail-8.13.1-i486-1.tgz and sendmail-cf-8.13.1-noarch-1.tgz.

Before we do any uninstalling of the existing older sendmail, I suggest you make a backup of your current /etc/mail and /usr/share/sendmail/ directories by running the following commands and storing the tarballs in a safe place:
Now lets make sure our sendmail server isn’t running before we uninstall it by running this command (I usually run it twice just to make sure its really stopped) :
Now we are in good shape to uninstall the default sendmail packages.
After running this command, look for any "Warnings", most likely you will get one for /etc/mail and /usr/share/sendmail/cf/cf if you have edited any files in those directories. If after you remove the original sendmail and you still have the /etc/mail and/or /usr/share/sendmail directories, go ahead and run:
Don't worry, we made those backups remember!

Now that we have cleanly removed the old sendmail from our system, its now time to install the new sendmail with SASL support. Run the following commands from the directory in which you saved these slackpacks.
Remember that backup we made of the /etc/mail directory way in the beginning, well now its time to use it. First lets extract our original files by running this command in the directory which contains the mail.tar.bz2 file.
Now if you had sendmail working before this Howto, you definitely made changes to some of the files in /etc/mail and if this is your first time getting sendmail to work, you'll want to at least make changes to access, local-host-names and probably aliases. So now is the time to copy your original files over, or make the necessary changes if this is your first time.

You'll also want to make sure that all the necessary files have their corresponding .db file so that sendmail will take your changes. Below I listed the commands needed to make the .db files. I recommend running all these commands even if the non-db file is empty.
Note that I highlighted the newaliases command in red because unlike all the other files, the aliases file uses this command to create its db file.

Now lets test sendmail to make sure everything we wanted was really compiled in:
In the Compiled With line make sure you see STARTTLS and SASLv2. If you do, go ahead and CTRL+C out, if you don't see both
please re-read this howto more carefully and recompile Sendmail and/or Cyrus SASLv2.

Client-Side SMTP AUTH + SMART_HOST

As mentioned earlier, client-side SMTP AUTH allows us to authenticate in order to relay all outgoing mail to our ISP's sendmail server and have them send the mail on our behalf via SMART_HOST. Note that you can have SMART_HOST work just fine without SMTP AUTH if your ISP's SMTP server doesnt require authentication.

Now that we have a working version of sendmail which supports SMTP AUTH, open up the /usr/share/sendmail/cf/cf/sendmail-slackware.mc file with your favorite editor and lets make some changes!

Below I have copy and pasted my sendmail-slackware.mc file and I have highlighted the parts I changed in green, parts I added in red and parts that are specific to your system in blue. Please read through this carefully and make sure you make all the necessary changes and additions.

Before we move on, I want to bring special attention to the following line
If you look closely, you will notice that the name of my ISP's SMTP server is surrounded in brackets [ ]. If you are using Yahoo DSL!, then these brackets must be included. Reason being is that Yahoo has decided to spoof their MX record to point to a relay that drops all mail, most likely in attempts to foil zombified spammers. Well, we want to ignore this bogus MX record and that's exactly what the brackets do for us.

Now that our config is properly setup, its time to convert it to the sendmail.cf file that we all know and love. But before we do, yup you guessed it, lets back it up first. Run this command
Ok now lets convert our new config, run this:
Now that we have our config file in place, all that is left is to tell sendmail what user and password to use when authenticating. To do this we must first create the file /etc/mail/authinfo and then open it up in your editor of choice.

Below is the contents of my authinfo file, to keep with the convention I have highlighted the parts that are specific to your system in blue.
In case its not apparent, the text after U: is the username, after P: is the password and after the M: is the mechanism which is used to login, valid types are DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN. Since I use SBC Yahoo DSL! I know for a fact that they use PLAIN, if you are not sure which one your ISP uses try PLAIN and see if it works, if not give tech support a call.

Note that the second line is almost exactly the same as the first line except its missing yahoo.com and there is a space after the colon. I’m not exactly sure why this line is needed, but that’s how it was presented to me and since it works, I’m not about to change it.

Once you have saved your changes to authinfo, we are going to set the correct file permissions on it so that only root can view it. This is a necessary security step as this file contains your password. Run the following command:
Like most of the files in /etc/mail, we must first convert them over to a .db file so sendmail will recognize our new settings, we will do this to authinfo using the following command:
Now its time to start up the sendmail server.
With any luck, the server should start up cleanly with no errors and you can now send mail through your ISP's SMTP server.

Server-side SMTP AUTH

As mentioned earlier, Server-side SMTP AUTH allows us to enable users outside our network to use our SMTP server for relaying mail without the danger of becoming an "open relay".

Now that we have a working version of sendmail which supports SMTP AUTH, open up the /usr/share/sendmail/cf/cf/sendmail-slackware.mc file with your favorite editor and lets make some changes!

Below I have copy and pasted my sendmail-slackware.mc file and I have highlighted the parts I added in red. Please read through this carefully and make sure you make all the necessary additions.

I'd like to first bring to attention the following line define(`confAUTH_OPTIONS', `A p y')dnl

The 'p' option tells sendmail not to let the client authenticate until it has initiated the STARTTLS command first. This basically enforces a no plain-text password policy on the client. You may not want this behavior and instead give the client the option to not use SSL encryption. If this is the case go ahead and remove the 'p'.

Now that our config is properly setup, its time to convert it to the sendmail.cf file that we all know and love. But before we do, yup you guessed it, lets back it up first. Run this command
Ok now lets convert our new config, run this:
We are nearly done, but first we must create an SSL certificate so that STARTTLS will function. Run the following commands to first create a Certificate Authority (CA)
When prompted for the Common Name be sure to enter the FQDN of your webserver i.e. www.mywebserver.com
Now that we have our own CA lets go ahead and make a certificate and sign it.
Note that the CA is good for 5 years (1865 days) and the cert is good for 4 years (1460 days). Its always a good idea to make the cert invalid before
the CA that signed it.

Next, we must put the right permissions on our cert as it contains sensitive data
FYI, If you want to see the contents of the cert, go ahead and run this command
Now lets start up the saslauth daemon, run the following command:
This command tells SASLv2 to look at the /etc/shadow file for authentication. There are other ways to authenticate but are beyond the scope of this howto. I’ve also read that the saslauth daemon does not support CRAM-MD5 or DIGEST-MD5, feel free to comment on how to make sendmail support these two mechanisms if you know how.

Also, its a good idea to put the saslauthd -a shadow command in your /etc/rc.d/rc.local file so that it is sure to start up after every reboot, otherwise SMTP AUTH will not work.

Now it's finally time to restart sendmail and send a test email with SMTP AUTH.
If everything works, congratulations! If not check your /var/log/maillog file. If that still doesnt help you try adding -X /tmp/sendtmp to the end of the sendmail startup command in /etc/rc.d/rc.sendmail like so:
Now resend an email using your client while running tail -f /tmp/sendtmp. This file will log all the I/O that the mail client sends to your server.


I hope this FAQ was helpful to more than just me . All comments welcomed

You rock. Another great post.

Thanks I appreciate it, and if anybody knows how to enable CRAM-MD5 and DIGEST-MD5 please post it here.

Eh, I followed everything up to building sendmail. That's where I get this:
Did I screw up somewhere?

I guess I should have mentioned that you must make your scripts executable it order to run them by using the command chmod u+x on them. You need to do this for SlackBuild, SlackBuild-sendmail and SlackBuild-sendmail-cf.

1 members found this post helpful.

Thanks. I'm still catching on to the basics of Linux. Great howto by the way. I'll post the results soon.

Ok, update: I got the SMTP authentication working, now I just can't recieve any incoming mail. I'm behind a router, but I forwarded the ports to my linux box. I was tailing the sendmail log and everything went fine with sending and authenticating, but when I replied nothing processed. So it didn't even make it back to my box.

I registered at dyndns.org and ran host for my address. It gave me my IP, so dyndns.org is working. Maybe I missed a sendmail setting that allows it to listen for mail on my server? Or maybe the wrong port settings? I opened and forwarded 25, 143 and 110.

I don't want to post my sendmail log (has private information), but I can post the sendmail-slackware.mc if it would help. Just a -little- bit more and it'll be up!

go ahead and post your .mc file and also your IP/hostname and ill try to do some looking around myself. Also are you trying to do client-side SMTP AUTH with SMART_HOST or server side?

[Removed by author]

Problem solved, see below.

First, can you please edit your post above and take off the [ code ] tags for the 4 lines of you sending an email, and also the one long line in your -X output; it's messing up this thread.
I really wish they would fix this from doing that. Thanks

Anyway, back to your problem. It looks like the problem is a firewall or sendmail listening issue. I tried to telnet to your host and I cannot connect. Forwarding port
25 should be sufficient, and if you made sure you forwarded this port to the right internal IP than this leads me to believe its one of two things. 1) Verizon is blocking
all incomming packets to port 25 or 2) sendmail is having trouble binding to 25.

The second one is easy enough to find out, simply run the following command as root.
If you do then it is not a sendmail problem, its most likly verizon blocking you from having a mail server. But note that sendmail is also listening on
port 587 which is for "Message Submission." Im a bit unclear exactly why its needed but I have read that this port can be used to get around ISP's
that block inbound 25. So what I would do is portforward 587 to your sendmail box and see if that works.

SiegeX -- I've noticed you've got a good set of HOWTO articles. I would suggest/encourage you to submit this post (and any others you feel are appropriate) as a Linux Answer As an "LA", your article would receive greater exposure, thereby helping more people; and it would not "fade into the distance" as regular posts can do as they age. This kind of article seems to be very well suited for LinuxAnswers, and again, I would encourage you to submit it for consideration. -- J.W.

Woah, I wasnt even aware there was a Linux Answers section on LQ, it doesnt seem to be well documented on the front page if you neglect the recent
article about it. Thanks for the great suggestion, I'll submit them ASAP.

Excellent -- I look forward to the submittals and I applaud your contributions to promoting Linux. IMO it is these kinds of posts that make LQ such an excellent and valuable resource. Thanks. -- J.W.

Above post edited. I called Verizon to see if they block any ports, and they said they don't block 25, but port 80. Does that mean I wouldn't be able to run a webserver?

Anyway, I went to hotmail to check my box and saw that I received this for each email I sent to ekim@grooob:

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

ekim AT grooob.homelinux.net


I then opened up my server's box and all of the replies were in my box, finally. Only took a whole day to get there. I sent one more final test from hotmail and it arrived about a minute later.

All in all, it's working now.

Thanks a lot for all the help. I agree with J.W. This is a great HOWTO. It really gives us newbies some insight to how everything works. If you'd like I'll take down my .mc and logs for cleanliness since they weren't really involved with the problem.

Glad to hear everything is working fine now, I guess some SMTP server along the way was backed up. As for your other question about port 80, yes it looks like you will not be able to run a standard webserver, you can still run one, but it must be on some non-standard port, 8080 for example. Then you must type http://www.url.com:8080 to get to it.
Thanks, id appreciate that.