UNIX System Administration Handbook - Evi Nemeth [363]
SASL: the Simple Authentication and Security Layer
sendmail 8.10 and later support the SMTP authentication defined in RFC2554. It’s based on SASL, the Simple Authentication and Security Layer.
SASL is a generic authentication mechanism that can be integrated into a variety of protocols. sendmail and Cyrus’s imapd use it (so far). The SASL framework (it’s a library) has two fundamental concepts: an authorization identifier and an authentication identifier. It can map these to permissions on files, UNIX passwords, Kerberos tickets, etc. SASL contains both an authentication part and an encryption part, but because of U.S. export laws, sendmail only used the authentication part through version 8.10. Because U.S. export regulations were relaxed in early 2000, the encryption portion that was originally slated to be in the commercial sendmail product has become available in version 8.11 to everyone.
To use SASL with sendmail, get Cyrus SASL from
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail
and install it. The configuration and installation instructions are a bit cryptic; we suggest you check out a web page created by Claus Assmann of Sendmail, Inc. on using SASL with sendmail. It’s at
http://www.sendmail.org/~ca/email/auth.html
The new encryption part of the puzzle is standardized in RFC2487 and is implemented in sendmail as an extension to SMTP called STARTTLS. TLS is the same as the Secure Socket Layer protocol used by secure web sites. Unfortunately, sendmail version 8.11 is still in beta, and we have not yet had any experience with TLS.
19.12 SENDMAIL STATISTICS, TESTING, AND DEBUGGING
sendmail can collect statistics on the number and size of messages it has handled. The data can be displayed with the mailstats command and is organized by mailer. sendmail’s confSTATUS_FILE option in the OSTYPE file specifies the name of the file in which statistics should be kept. The existence of the specified file turns on the accounting function.
See page 205 for help with rotating and restarting log files.
The default location for the statistics file is /etc/mail/statistics, but some vendors put it in /var/log/sendmail.st or /usr/lib/sendmail.st. The totals are cumulative since the creation of the statistics file. If you want periodic statistics, you can rotate and reinitialize the file from cron.
To make the following example fit the page, we omitted the first column (which numbers the mailers) and the seventh column (discards, because there were none).
Statistics from Wed Nov 17 00:56:30 1999
msgsfr bytes_from msgsto bytes_to msgsrej Mailer
0 0K 2015 5314K 0 prog
0 0K 2 4K 0 *file*
5399 37455K 20 20K 18 local
42449 383837K 72885 450631K 4207 esmtp
====================================================
47848 421292K 74922 455969K 4225
.
Six values are shown: messages and kilobytes received (msgsfr, bytes_from), messages and kilobytes sent (msgsto, bytes_to), messages rejected (msgsrej), and messages discarded (msgsdis). These values include both local and relayed mail.
Testing and debugging
m4-based configurations are to some extent pretested. You probably won’t need to do low-level debugging if you use them. One thing the debugging flags cannot test is your design. While researching this chapter, we found errors in several of the configuration files and designs that we examined. The errors ranged from invoking a feature without the prerequisite macro (e.g., using masquerade_envelope without having turned on masquerading with MASQUERADE_AS) to total conflict between the design of the sendmail configuration and the firewall that controlled whether mail was allowed in and under what conditions.
You cannot design a mail system in a vacuum. You must be synchronized with