UNIX System Administration Handbook - Evi Nemeth [361]
Mailers can also be run in a chrooted directory. This option must be specified in the mailer definition at the moment, but it should soon be configurable via m4.
Privacy options
sendmail also has privacy options that control
• What external folks can determine about your site from SMTP
• What you require of the host on the other end of an SMTP connection
• Whether your users can see or run the mail queue
Table 19.17 lists the possible values for the privacy options as of this writing; see the file sendmail/conf.c in the distribution for current information.
Table 19.17 Values of the PrivacyOption variable
a. Verbose mode follows .forward files when an EXPN command is given and provides more information about a user’s mail-whereabouts. Use noverb or, better yet, noexpn on any machine exposed to the outside world.
b. ETRN is an ESMTP command designed for use by dial-up hosts. It requests that the queue be run just for messages to that host.
We recommend conservatism; use
define('confPRIVACY_OPTIONS', ''goaway, authwarnings, restrictmailq,
restrictqrun'')
in your .mc file. The default value for the privacy options is authwarnings; the line above would reset that value. Notice the double sets of quotes; some versions of m4 require them to protect the commas in the list of privacy option values.
Running a chrooted sendmail (for the truly paranoid)
If you are worried about the access that sendmail has to your filesystem, you can start it in a chrooted jail. Make a minimal filesystem in your jail, including things like /dev/null, /etc essentials (passwd, group, resolv.conf, sendmail.cf, any map files, mail/*), the shared libraries that sendmail needs, the sendmail binary, the mail queue directory, and any log files. You will probably have to fiddle with the list to get it just right. Use the chroot command to start a jailed sendmail. For example:
# chroot /jail /usr/sbin/sendmail -bd -q30m
Denial of service attacks
Denial of service attacks are impossible to prevent because there is no a priori way to determine that a message is an attack rather than a valid piece of email. Attackers can try various nasty things, including flooding the SMTP port with bogus connections, filling disk partitions with giant messages, clogging outgoing connections, and mail bombing. sendmail has some configuration parameters that can help slow down or limit the impact of a denial of service attack, but these parameters can also interfere with legitimate mail.
The MaxDaemonChildren option limits the number of sendmail processes. It prevents the system from being overwhelmed with sendmail work, but it also allows an attacker to shut down SMTP service very easily. The MaxMessageSize option can help prevent the mail queue directory from filling, but if you set it too low, legitimate mail will bounce. (You might mention your limit to users so that they aren’t surprised when their mail bounces. We recommend a fairly high limit anyway, as some legitimate mail is huge.) The ConnectionRateThrottle option, which limits the number of connections per second that are permitted, can slow things down a bit. And finally, setting MaxRcptsPerMessage, which controls the maximum number of recipients allowed on a single message, might help.
In spite of all these knobs to turn to protect your mail system, someone mail bombing you will still interfere with legitimate mail. Mail bombing can be quite nasty.
The University of Colorado provides an email account for each student (25,000), with pine as the default mail reader. A student with a new job at a local computer store was convinced to give a copy of the password file to his employer. The company then sent an advertisement to everyone in the password file, in batches of about 1,000 recipients at a time (which made for a very long To line).
pine had been compiled with the default reply mode set to reply to all recipients as well as the sender. Many students replied with questions such as, “Why did you