[ Team LiB ] |
Recipe 8.18 Using an SMTP Server from Arbitrary Clients8.18.1 ProblemYou want your SMTP server to relay mail from arbitrary places, without creating an open relay. 8.18.2 SolutionUse SMTP authentication. To set up the server:
Your mail server should now be ready to do SMTP authentication. To set up the email client:
8.18.3 DiscussionAn SMTP server accepts Internet email. There are two kinds of email messages it may receive:
A mail server that forwards non-local mail is called a relay. Normally, you'll want your SMTP server to accept local mail from anywhere, but restrict who may use your server as a relay for non-local mail. If you don't restrict it, your SMTP server is called an open relay. Open relays invite trouble: spammers seek them out as convenient drop-off points; your machine could be co-opted to send unwanted email to thousands of people. Say goodbye to your good Internet karma... and you will shortly find your mail server blacklisted by spam-control services, and hence useless. In fact, you might come home one day to find your ISP has shut down your Net access, due to complaints of mail abuse! You really don't want an open relay. ISP mail servers normally accept relay mail only from addresses on their network, restricting them to use by their customers. This makes good business sense, but is inconvenient for mobile users who connect to various ISPs for Net access at different times. It's a pain to keep switching email program settings to use the different required relays (or even to find out what they are). Our recipe demonstrates how to set up your SMTP server to get around this inconvenience, by requiring authentication before relaying mail. Thus, a single SMTP server can accept non-local mail no matter where the client is connected, while still avoiding an open relay. One caveat: the email clients must support SMTP authentication, as do Evolution, Pine, the Mail program of Macintosh OS X, and others. Our recipe depends on two lines in /etc/mail/sendmail.mc. The first, once you disable it, allows sendmail to accept mail from other hosts; by default, it only listens on the network loopback interface and accepts mail only from local processes. The second line, once enabled, tells sendmail which authentication mechanisms to accept as trusted: that is, if a client authenticates using one of these methods, it will be allowed to relay mail. When you send your test message, if your mail client claims the server does not support SMTP authentication, try this on the server: # sendmail -O LogLevel=14 -bs -Am EHLO foo QUIT # tail /var/log/maillog and look for any enlightening error messages. This configuration by itself does not secure the entire SMTP session, which is still a plaintext TCP connection. So don't use simple password authentication, as your passwords can then be stolen by network eavesdropping. By default, sendmail accepts only the DIGEST-MD5 and CRAM-MD5 authentication methods, which do not send the password in plaintext. It is also possible to configure sendmail to use SSL to protect the entire SMTP session. If you understand the security properties and limitations of the authentication mechanisms mentioned above, and consider them inadequate for your application, this might be a necessary step to take. However, don't do it out of some notion to "protect" the content of your email. Unless you have a closed system, your email will be further relayed across other networks on the way to its destination, so securing this one hop is of little value. For more security, use an end-to-end approach, encrypting messages with GnuPG, PGP, or S/MIME (see [Recipe 8.1] through [Recipe 8.8]). 8.18.4 See AlsoLearn more about SMTP authentication at ftp://ftp.isi.edu/in-notes/rfc2554.txt, and sendmail's particular implementation at http://www.sendmail.org/~ca/email/auth.html. The SASL RFC is at ftp://ftp.isi.edu/in-notes/rfc2222.txt. |
[ Team LiB ] |