Authenticated Sendmail over SSL
and IMAP over SSL
on RedHat Linux 7.x/8.0 Systems
by Marion Bates <mbates@xxxxxxxxxxx>
Last updated May 3, 2003
Those of us who run multipurpose servers are probably familiar with the conundrum of what to do about clients who want to use your machine as their primary mail server. It would be easy if everybody had a static IP address, but more likely they have dynamic IPs through a cable modem or dialup account. If you want to allow them to use your SMTP server for their outbound mail, then you have to either maintain an annoying list of their IPs in your access file to allow relaying, and you have to edit that file as needed when they change ISPs or go to their school/office network, or you can simply allow your server to relay mail for anyone; of course, this latter option is easier for you, but you are now a portal for any and all spam. Even if you don't care about being a "good netizen," this also puts you at risk for having your domain added to blacklists, thus hampering your overall email capability.
Here, I will outline an alternative, which allows all of your users to relay mail through your server from anywhere, but which still prevents you from being an open spam relay. This is achieved via the use of SMTP-AUTH, which requires users to authenticate with their username and password before they can send email through your server. This means that your valid users will be able to use your server from anywhere, regardless of whether or not their IPs are in the access list, as long as their mail clients support SMTP-AUTH (which most now do). For added security, we'll use enable SSL also, so the login/password and the session can take place over an encrypted layer if users so desire. The addendum at the end describes how to enable secure IMAP (which is far simpler!).
NOTE: If you already have RedHat 8, this is much simpler...just do Step -1, then skip to Step 6. You may need to install some packages to satisfy dependencies -- in that case, refer to the file list in Step 0, but get the current RedHat 8 versions. You shouldn't need to rebuild anything from source RPMs -- that lengthy process only applies to RH 7 users.
Intro. I did this on RedHat 7.3, from RedHat RPMs, several of which I built from RH 8.0 source RPMs in order to get the newer versions of things. An explanation of source RPMs is beyond the scope of this document, but the References section at the end has links to SRPM info. Suffice it to say here that the point was, I wanted sendmail 8.12, but I didn't want to upgrade to RH 8.0 just to get it, and the newest version in the stock RH 7.3 downloads department was 8.11. I could've gone elsewhere (like RawHide) to get a sendmail 8.12 RPM for RedHat 7.3, but I wanted to deviate as little as possible from the stock RH setup, so I elected to use RH 8 rpms but rebuild and install them on my RH 7.3 machine.
You will need to be root for most of these steps.
STEP -1: BACKUP. Before doing anything else, back up all your sendmail configuration files! Some of these may be under /etc rather than /etc/mail. To find out, type
sendmail -d0.20 -bv | grep sendmail.cf
You should get output similar to one or more of these:
Conf file: /etc/mail/sendmail.cf (default for MTA)
Conf file: /etc/mail/sendmail.cf (selected)
Def Conf file: /etc/sendmail.cf
Make copies of these files and put them in a safe place, like /root.
/etc/mail/sendmail.cf
/etc/mail/sendmail.mc if it exists
/etc/mail/access
/etc/mail/virtusertable
/etc/aliases
STEP 0: Installing everything you need. Somewhere along the way in this process, I had to stop and install about a trillion packages to satisfy dependencies. So let's start there. These are listed in no particular order, and some may have to be installed before others. Some satisfy dependencies needed for building the new sendmail rpm, whereas others are required for building and installing the new version of cyrus-sasl. Paths shown for convenience, adjust accordingly for your download mirror of choice.
Be sure to install the rpm-build package before you install source RPMs, so it creates the proper directory structure under /usr/src:
/usr/src/redhat
/usr/src/redhat/BUILD
/usr/src/redhat/RPMS
/usr/src/redhat/RPMS/athlon
/usr/src/redhat/RPMS/i386
/usr/src/redhat/RPMS/i486
/usr/src/redhat/RPMS/i586
/usr/src/redhat/RPMS/i686
/usr/src/redhat/RPMS/noarch
/usr/src/redhat/SOURCES
/usr/src/redhat/SPECS
/usr/src/redhat/SRPMS
Partial explanation of the components of this hierarchy:
/usr/src/redhat
Top of the directory hierarchy where RedHat SRPMS will place spec and source files.
/usr/src/redhat/BUILD
Where the actual source tarball will be unpacked, altered, and compiled by the RPM build process.
/usr/src/redhat/RPMS/i386
Where the finished RPMs will go. You can then install them on your system like any stock RPM from RedHat. The number may be different, e.g. i686, athlon, or noarch, depending on your architecture and build settings.
/usr/src/redhat/SOURCES
Where the source tar files, patch files, and configuration files go -- all the things that RPM does to the source before actually compiling it, to tweak it for RedHat Linux.
/usr/src/redhat/SPECS
Where spec files go -- spec files are scripts that tell rpmbuild how to unpack the tarball, apply the source files, compile the program, create the RPM with the right settings for where to install the actual binaries, etc.
/usr/src/redhat/SRPMS
Where the resulting source RPMs go after you build from source RPM. Sounds self-referential, eh? :) Any changes you make to the original SRPM's source files or specfile will be reflected within this new source RPM, and under the terms of the GPL, you can now distribute your source and binary RPMs freely.
Here are the packages I had to install to make everything happy.
From the main RedHat 7.3 area:
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/rpm-build-4.0.4-7x.18.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/m4-1.4.1-7.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/gdbm-1.8.0-14.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/gdbm-devel-1.8.0-14.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/hesiod-3.0.2-18.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/hesiod-devel-3.0.2-18.i386.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/autoconf253-2.53-3.noarch.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/automake15-1.5-2.noarch.rpm
pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/libtool-1.4.2-7.i386.rpm
From the RedHat 7.3 updates area:
pub/redhat/linux/updates/7.3/en/os/i386/openldap-2.0.27-2.7.3.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/openldap-devel-2.0.27-2.7.3.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/openssl-0.9.6b-32.7.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/openssl-perl-0.9.6b-32.7.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/openssl-devel-0.9.6b-32.7.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/krb5-libs-1.2.4-11.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/krb5-devel-1.2.4-11.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/pam-0.75-46.7.3.i386.rpm
pub/redhat/linux/updates/7.3/en/os/i386/pam-devel-0.75-46.7.3.i386.rpm
And from RedHat 8:
pub/redhat/linux/8.0/en/os/i386/RedHat/RPMS/db4-4.0.14-14.src.rpm
pub/redhat/linux/8.0/en/os/i386/RedHat/RPMS/db4-devel-4.0.14-14.i386.rpm
STEP 3 (possibly optional): Build and install cyrus-sasl. If you want to allow other authentication mechanisms (e.g. mechs based on MD5), then you will also need cyrus SASL, which like Sendmail 8.12 requires rebuilding from the RedHat 8.0 SRPM. Get the source rpm from
pub/redhat/linux/8.0/en/os/i386/SRPMS/cyrus-sasl-2.1.7-2.src.rpm
And install it by typing
rpm -i cyrus-sasl-2.1.7-2.src.rpm
Note: I am not sure, but it's possible that cyrus-sasl is required to be present on your system even if you don't care about having other auth options.
Because this is a source rpm and not a standard binary package, this does not actually put cyrus-sasl on your system; rather, it installs the spec file and sources (patches, the actual tarball, maybe some config files, etc.) under /usr/src/redhat/ in preparation for you to alter and/or rebuild the "real" binary RPMS for your system.
Assuming you've got all the dependencies satisfied, there is one last thing to do before you build cyrus-sasl. You may not need to do this, but I had to.
cd /usr/src/redhat/SPECS and edit the cyrus-sasl.spec file. Find the line that says:
BuildPrereq: autoconfxxx, automake15, libtool
and change the 3-digit version number (represented by xxx) such that the autoconf version listed there matches what you've got installed. In my case:
bash-2.05a# rpm -qa | grep autoconf
autoconf253-2.53-3
So I changed the specfile line to:
BuildPrereq: autoconf253, automake15, libtool
Save and exit. Now do the following (substitute different architecture number under RPMS if needed):
rpm -ba cyrus-sasl.spec
cd ../RPMS/i386
rpm -Uvh cyrus-sasl*.rpm
This will install:
cyrus-sasl-2.1.7-2
cyrus-sasl-gssapi-2.1.7-2
cyrus-sasl-plain-2.1.7-2
cyrus-sasl-devel-2.1.7-2
cyrus-sasl-md5-2.1.7-2
You may not need or want all of these -- but if you have them, you've got more flexibility regarding authentication mechanisms.
STEP 4 (optional): Create sasldb. To allow for other authentication mechanisms, you will need to run saslpasswd for each user and set a password (which can be different from their normal account passwords):
saslpasswd username
(enter password twice when prompted)
You can check to see which auth mechanisms are available (will depend on which cyrus-sasl packages you installed):
bash-2.05a# sasldblistusers
user: joeblow realm: goober.com mech: DIGEST-MD5
user: joeblow realm: goober.com mech: CRAM-MD5
user: joeblow realm: goober.com mech: PLAIN
STEP 5: Build and install sendmail. WHEW! Okay...NOW, we can finally attempt to build the sendmail RPM. You shouldn't need to change anything in the specfile like we did for cyrus-sasl -- you are just taking the stock RedHat 8.0 source RPM and rebuilding it to install under RedHat 7.3.
Download the sendmail source RPM from a RedHat mirror. At the time of this writing, you can get the one I used here:
/pub/mirrors/ftp.redhat.com/pub/redhat/linux/updates/8.0/en/os/SRPMS/sendmail-8.12.8-1.80.src.rpm
Install it by typing
rpm -i sendmail-8.12.8-1.80.src.rpm
Go to /usr/src/redhat/SPECS and type
rpm -ba sendmail.spec
If it succeeds without any errors, you should now have a nice new sendmail 8.12 RPM for RedHat 7.3.
Note: Alternatively, you can simply type
rpm --rebuild sendmail-8.12.8-1.80.src.rpm
This combines the two steps shown above, and the only difference is that it does not generate a new source RPM because it assumes you're not changing anything in the original source RPM, which in this case is correct. (We didn't want to do this shortcut for cyrus-sasl, because we had to edit the specfile first.)
Actually install it:
cd ../RPMS/i386
rpm -Uvh sendmail-8.12.8-1.80.i386.rpm
rpm -Uvh sendmail-cf-8.12.8-1.80.i386.rpm
STEP 6: Verify sendmail. If all goes well, you should now have sendmail 8.12.8 running on your server! (You may also want to install the sendmail-cf, sendmail-docs, and sendmail-devel packages, all under the same RPMS/i386 directory.) You can check to ensure that this version includes the options we need, by typing:
bash-2.05a# sendmail -d0.1 -bv
The output will look something like this:
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = domain
(canonical domain name) $j = domain.com
(subdomain name) $m = com
(node name) $k = domain.com
========================================================
Recipient names must be specified
In the "compiled with" block, look for "SASL" and "STARTTLS". If either one is missing, there is a problem... :(
Okay NOW we should be finished with packages for awhile. Maybe this is a good time to explain why we went to all the trouble to build RH 8 packages, rather than simply use the current sendmail RPMs for RH 7.3. The reason is that starting with sendmail 8.12, the two compile-time options we need -- SASL and STARTTLS -- are included by default in the RedHat RPM. Also, there is some change with regard to the use of crypto libraries, apparently it's better in 8.12 than in prior versions. Another reason: I originally tried to alter and rebuild the RH 7.3 sendmail 8.11 source RPM to include these options, but no matter what, it refused to compile, so I eventually gave up on that approach. But even if I were successful, the next time red-carpet/RHN ran and "upgraded" Sendmail using stock upgrade packages, it would hose my changes. Better to go to a newer version altogether, rather than hack the old version in such a way that no other human or machine knows that it's different from the stock RPM. :)
An important thing to note: What happens when red-carpet notices that your version of sendmail does not match the standard RH 7.3 subscribed channel? From William Stearns: "Red-carpet won't notice; it sees you have a sendmail, and when a new version comes out in your subscribed channel, it'll compare version numbers. Your version will always be higher than anything in rh73, which sounds good, but keep in mind that if a crucial bugfix comes out, your self compiled package will never be upgraded. In short, just like software compiled from source with no rpm packaging, the administrator needs to upgrade by hand if an upgrade comes out."
STEP 7: Edit sendmail.mc. Now, we've got a version of sendmail with the compile-time options we need to enable AUTH and SSL. But we still have to specify all that in the sendmail config file. Since sendmail.cf is unintelligible to all normal living things, we will use the sendmail-cf and m4 packages so we can edit the slightly less user-hostile sendmail.mc (macro) file and use it to generate sendmail.cf.
The sendmail RPM ought to not overwrite your old sendmail.cf (and sendmail.mc, if you already had one). It should instead create sendmail.cf.rpmnew and sendmail.mc.rpmnew respectively. If you had made a lot of changes to your old sendmail configs, then you will need to merge them into the new one created by the RPM installation, and I hope you have enough food and water to survive. :) The only change I had made was removing the 127.0.0.1 portion of the MTA line such that other machines can relay mail, not just localhost; the rest of these changes are about SSL and AUTH.
Note: I did not ADD any lines to sendmail.mc, I only uncommented lines that were already included in the mc file.
Edit sendmail.mc and uncomment (delete "dnl " as needed). You'll be happier if you use an editor with sendmail-savvy syntax highlighting, since you will know right away if a line is being interpreted as a comment or not. When finished, your file ought to look like the one shown below. The inline explanations in the conf file are pretty good; the only part where I had trouble was the "dnl define(`confAUTH_OPTIONS', `A p')dnl" line. Leave that line commented out unless you know you want to use some other login mechanism besides etc/shadow passwords; if you invoke that line, keep in mind that many clients won't work -- notably, some versions of Outlook require PLAIN to be available, and activating that conf line will prevent those users from logging in.
My modified sendmail.mc file is shown here (relevant changes are red). If you want to download a suitable-for-use (no HTML) version, click here.
divert(-1)dnl
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl # make -C /etc/mail
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Red Hat Linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
dnl define(`SMART_HOST',`smtp.your.provider')
dnl #
define(`confDEF_USER_ID',``8:12'')dnl
define(`confTRUSTED_USER', `smmsp')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl define(`confAUTH_OPTIONS', `A p')dnl
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl #
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl # make -C /usr/share/ssl/certs usage
dnl #
define(`confCACERT_PATH',`/usr/share/ssl/certs')
define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl # NOTE: binding both IPv4 and IPv6 daemon to the same port requires
dnl # a kernel patch
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS(`mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
After editing sendmail.mc, save and exit.
STEP 8: Certificates. For the SSL (STARTTLS) portion of this feature, you will need to generate SSL certificates. See the References section if you want to read more about how certificates work. I'm just going to tell you what to type to make it work. :)
cd /usr/share/ssl/certs
make sendmail.pem
Answer the prompts, your answers are not crucially important EXCEPT that you MUST specify the fully-qualified domain name for your server (e.g., mail.goober.com).
STEP 9: Activate changes in sendmail and test. Now, use your modified sendmail.mc file to generate a new sendmail.cf file:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Then, restart sendmail:
/etc/init.d/sendmail restart
Assuming sendmail starts up successfully (if not, check for syntax errors in sendmail.mc, and/or check /var/log/maillog for errors), do a check:
bash-2.05a# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 whoopis.com ESMTP Sendmail 8.12.8/8.11.6; Sat, 19 Apr 2003 13:55:43 -0400
Carefully type:
EHLO localhost
And take a look at the output:
250-whoopis.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
Look at the AUTH line. "LOGIN" and "PLAIN" are key; if you see those, along with "STARTTLS", you're good to go. "GSSAPI" refers to Kerberos 5. Basically, anything that follows the AUTH line is the name of an accepted authentication mechanism. If you installed and set up the sasl db, then that line may look like:
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Some mail clients, such as Apple's Mail, have an option for "MD5 Challenge-Response." This corresponds to the MD5 options enabled by your entry in the sasl database.
STEP 10: The acid test. Now try a real mail client. First, remove your client machine's IP range from the access file and restart sendmail -- relaying should now be denied for you (try it). Then set up your client's SMTP config to use SSL, on port 25, and to authenticate using "password." Try sending a message; you should be prompted for your password, most clients have an option to remember the login/password so you don't have to type it for every message. If you get an error like "Server does not support AUTH mechanism PLAIN" then check sendmail.mc again (make sure that one annoying line is still commented out!), regenerate the .cf file, restart sendmail, etc. and try again.
Here's tcpdump output showing what your outbound email looks like after enabling AUTH and SSL, and another sample showing just AUTH without SSL.
You will need to tell your users how to edit their email configurations to use SMTP auth with password and SSL. If your users' mail programs can't handle auth, you can fall back on the old method of keeping their IPs in the access file. Here is a sample explanation meant for non-technical users, which you can adapt and use if you wish.
Troubleshooting. Users may get an error message like this if they use Outlook and SSL:
![]()
This is because the certificate you generated is a self-signed certificate, and is therefore untrusted. It's okay for our purposes -- tell your users to hit "yes" to accept the certificate anyway.
If your users see this error:
![]()
Then try the solutions posted here: http://www.iron.net/www/troubleshoot/email/outbox.html
ADDENDUM: Enabling SSL for IMAP is quite simple. See this link or follow these steps:
1. cd /usr/share/ssl/certs/
2. run "make imapd.pem"
3. answer prompts -- just like for your sendmail.pem file. Answers do not need to be identical, but again, be sure to use the fully-qualified hostname (e.g. mail.domain.com)
4. Check that "imaps" exists under /etc/xinetd.d/ and that it is set to "disable=no" (in other words, enabled!) If imaps isn't there, duplicate and rename the "imap" file. They are functionally identical.
5. Restart imap by restarting xinetd (run "/etc/init.d/xinetd restart", but first make sure there are no important xinetd processes running, like a big ftp job)
6. Run "netstat -anp | less" and check the output:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
...
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 27562/xinetd
...
...
...
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 27562/xinetd
...
...
If you see the "0 0.0.0.0:993" line, that's secure IMAP listening on the default port of 993. Configure your mail client(s) to "use SSL" and you should be all set. :) The same potential exists for picky mail clients to whine about the untrusted certificate, but that's ok.
References:
These are listed in no particularly meaningful order...basically, in the order in which I found them. :)
- http://www.joreybump.com/code/howto/smtpauth.html. "SMTP AUTH with Sendmail -- Quick Start Guide for Redhat Linux." This howto has a lot of good information, but unfortunately some of the details are a bit out of date for current versions of RedHat and Sendmail.
- http://www.ofb.net/%7Ejheiss/sendmail/tlsandrelay.shtml. "Configuring Sendmail's STARTTLS (SSL) and Relaying." The focus of this howto is different from what I had in mind, but some of the details were more current that joreybump's so the two together were key.
- http://www.sendmail.org/~ca/email/starttls.html. "SMTP STARTTLS in sendmail/Secure Switch." Yet another similar howto, but with emphasis on server-to-server certificate exchange. Useful if you want to know more details about the nature of the SSL certificates.
- http://www.sendmail.org/~ca/email/auth.html. "SMTP AUTH in sendmail 8.10-8.12." A recent (late February 2003) howto which filled in a lot of missing pieces, especially regarding the cyrus-sasl stuff and more in-depth info regarding sendmail.mc options.
- http://www.sendmail.org/~ca/email/tlscomp.html. "Compiling STARTTLS in Sendmail." Outdated, but listed here for its explanation of libraries and for those who want to tackle rebuilding an older sendmail RPM.
- http://www.sendmail.org/~ca/email/cyrus/sysadmin.html. "Cyrus SASL for System Administrators." For if you want to use other auth mechanisms. At one point during a mad frenzy of trial-and-error, I had MD5-DIGEST and another MD5 method available, but then I lost them somehow -- possibly in upgrading to cyrus-sasl-2 in order to be able to build the new sendmail. Who knows.
- http://www.sial.org/talks/smtpauth-starttls/. "Sendmail AUTH and STARTTLS." A presentation, somewhat outdated detail-wise but explains why we're doing this at all ("Users Good, Spammers Bad" lol!)
- http://www.sendmail.org/~ca/email/tricks.html. "Tips and Tricks for sendmail Hackers." Discusses some FFR (For Future Release) sendmail options related to STARTTLS, but the document is two years old, so the future may be...the past. :)
- http://www.med.nyu.edu/it/helpdesk_support/email/smtpauth_info.html. "Using a Password with SoMIT's Authenticated SMTP Servers." This is some NYU helpdesk page which is not important except that it has a chart of which common email clients support which authentication mechanisms. Unverified and probably somewhat out of date, but it's a place to start if one of your users needs troubleshooting help.
- http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=1370. "Re: Sendmail 8.12 and SASL" (from cyrus-sasl list at CMU). Read the whole thread, about 6 messages, for full benefit. This helped explain how to set various auth options in sasl, for clients that support them.
- http://www.linuxnovice.org/main_how.php3?VIEW=VIEW&t_id=52. "HOW DO I Install source RPMs?" A good basic doc on using source RPMs.
- http://www.itc.virginia.edu/desktop/email/smtpauth/outlookold.html. "SMTP AUTH Settings for Outlook Express and Outlook 2000." Configuration information for Outlook users.
- http://www.pageplanet.com/smtpauth/win/oe5/. "Outlook Express 5 (Win) SMTP AUTH Configuration." A nice step-by-step pictorial walkthrough of how to configure Outlook Express to use SMTP-AUTH. The only thing different is that this assumes the server does NOT have SSL.
- http://www.iron.net/www/troubleshoot/email/outbox.html. A troubleshooting page with possible solutions for the second error message, shown above.
- http://www.lemoyne.edu/information_technology/lemoyne_link/SMTP_auth.htm. "Configuring IMAP and POP3 clients to authenticate to the Groupwise server for SMTP mail sending." More client setup information, for clients besides Outlook.
- http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-email-security.html. "Red Hat Linux 7.3: The Official Red Hat Linux Reference Guide. Chapter 16. Email -- Security." How to set up secure IMAP, with or without stunnel.
As always, a huge thanks to William Stearns (wstearns at pobox.com) for all the help and proofreading, and especially for the RPM/SRPM details.
Thanks to Lee Patterson (amdusias at whoopis.com) for the Outlook and Outlook Express troubleshooting assistance and screenshots.
|