Normal POP mail sessions, by their very nature, are insecure. The password goes across the network in cleartext for everyone to see. Now, this may be perfectly acceptable in a trusted or firewalled environment. But on a public network, such as a university or your run-of-the-mill ISP, anyone armed with a simple network sniffer can grab your password right off the wire. This is compounded by the fact that many people set their computers to check for mail at regular intervals, so the password is sent out quite frequently, which makes it easy to sniff.
With this password, an attacker can now access your email account, which may have sensitive or private information. It is also quite common that this password is the same as the user's shell account, so there is the possibility for more damage.
By doing all POP traffic using an encrypted channel, nothing goes in cleartext over the network. We can use ssh's diverse methods of authentication, instead of a simple plaintext password. That is the real point of using this method: not because we get encrypted content (which is futile at this point, since it's probably gone unencrypted over several networks already before reaching your mailbox; securing those communications is the job of GNU Privacy Guard or PGP, not ssh), but the secure authentication.
There are other methods of achieving secure authentication already, such as APOP, KPOP, and IMAP. However, using ssh has the advantage that it works with normal POP configurations, without requiring special client (not all mail clients support advanced protocols) or server support (except for sshd running on the server). You mail provider may be unable or unwilling to use a more secure protocol. Besides, by using ssh you can compress the traffic too, which is a nice little extra for people with slow connections.
Have the following installed: openldap libtool automake gdbm hesiod m4 cyrus-sasl Check to see where sendmail is finding sendmail.cf file by running the following: sendmail -d0.20 -bv | grep sendmail.cf Your output should be similar to: Conf file: /etc/mail/sendmail.cf (default for MTA) Conf file: /etc/mail/sendmail.cf (selected) Def Conf file: /etc/sendmail.cf 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 Verify sendmail: 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 ======================================================== In the "compiled with" block, look for "SASL" and "STARTTLS". If either one is missing, there is a problem... :( 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 Explanation Dear goober.com users, You're getting this because you have an account on goober.com, or you have another domain whose email is handled by the same server which hosts goober.com. If you do not use this server for your email, or if you use it but only to have email forwarded to another account, then you can ignore this message. For those of you who use goober.com as a primary mail server (for incoming and outgoing messages), our IT administrators have upgraded Sendmail to enable authentication and SSL for your outbound mail. Your incoming (IMAP) mail is unaffected. Reason: Up to now, the administrators have been maintaining a file with a list of your IP addresses (or ranges, if you have dynamic IPs) and allowing all IPs in that list to send ("relay") mail through goober.com. However, this is awkward for those of you who move around on different networks (school vs. office vs. home vs. traveling etc.) and it is also awkward for us to have to modify that file and restart the server every time someone's source IP changes. In addition, every added range of IPs increases the risk of goober.com being used as a spam relay; e.g., if a spammer also has an IP within the range configured for you, then the spammer can send untraceable and potentially malicious email through the goober mailserver. Being such an "open relay" is bad netiquette and puts us at risk of having goober.com added to RTBLs (Real-Time Black Lists) maintained by other ISPs and system administrators who block all traffic from domains known to be open relays. In short, doing things this way is a Bad Idea. So, the way it works now is, you will need to modify your email program's SMTP (or "Sending," or "Outbound") mail server settings in order to _send_ mail through goober. (You will still be able to _receive_ goober mail regardless of whether you make this change or not.) The port number is still 25. Look for a checkbox in the SMTP settings dialog that says something like "Use password authentication" and select it. If there are multiple authentication options available (may say things like "Kerberos" or "MD5"), then select "password" or "plain/login" or similar. There ought to be fields nearby for your username and password (same as the ones you use now for logging in to check incoming mail), as well as an option to save/remember login and pass, so you don't have to retype them every time you send email. After you have made and applied/saved these changes, send yourself an email. If you get an error message, try re-entering your password, make sure the case is correct in your username, make sure the program didn't change the port to something other than 25, check the authentication options, and re-do the test. If you still have problems, revert to the old settings (no authentication) and then send our support staff (support@goober.com) a note about the error you got. We will maintain the old IP list until all users have tested their configuration with these new settings. If support doesn't hear from you within a week or so, we will assume you tried it and it works, and your IPs will be removed from the relay list. At that point, you _must_ use authentication to send emails through goober.com. This server configuration creates an advantage for you, as you can now use goober.com for your outbound emails from anywhere on the Internet as long as you authenticate first. We hope that you will enjoy the convenience afforded by this as you travel, use multiple ISPs, etc. Most mail programs also have an option for SMTP SSL (encryption), which goober.com's sendmail server now supports as well. If your mail program has it, you should use it -- it encrypts your SMTP login information as well as the content of the emails you write, between your computer and goober.com, such that local users on your network cannot run a traffic sniffer and read your outgoing emails. (Your incoming email is still plain-text, but we plan to enable SSL on that "half" of the email server as well, just not yet.) The first time you send email after enabling SSL, you may get a message about the SSL certificate being untrusted (or "self-signed") -- this is normal and it's okay. Choose to accept it anyway. If your mail program refuses the certificate completely, please email support and tell us what it said and what version of the email software you're using, and turn off SSL in the meantime. You don't need encryption in order to make email work, it's just nice to have whenever possible. Please let support know if you have any problems or questions. Thank you, -- Goober Admin 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/~jheiss/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.