Section 4.2 Sendmail

---

4.2 Sendmail

Almost every Linux shop runs Sendmail and allows any system in the world to connect to it. It needs root access to open its privileged port (TCP port 25) and to enable all its features. Next to the kernel, and possibly X, Sendmail may be the most complex component of Linux and you could spend a lifetime learning about it. It will be assumed that your systems have been upgraded to Sendmail 8.10 or higher and that you have applied the suggestions that were discussed in "Upgrade sendmail" on page 107 and "Fortify sendmail to Resist DoS Attacks" on page 109. We will proceed from there.

Although Sendmail 8.9.3 and above are considered secure at present, between that version and 8.10, the configuration file format changed dramatically. Rather than requiring SysAdmins to be an expert on the challenging sendmail.cf format, this change allows editing the less challenging sendmail.mc file for routine configuration changes. There are other improvements too.

If your version of Sendmail is older than 8.9.3, there are known buffer overflow exploits and spam relay exploits that you are vulnerable to, so you will want to upgrade immediately. See "Upgrade sendmail" on page 107 for the details on upgrading Sendmail. A variety of problems and solutions related to Sendmail will be discussed here. There are other freeware alternatives to Sendmail, such as postfix and qmail. Many people consider these to be easier to use and more secure than Sendmail. Now that Eric Allman, Sendmail's creator, has founded the well-capitalized Sendmail, Inc., there have been good support and new features for Sendmail. The postfix program is recommended by many security experts as a more secure mailer than Sendmail. It was developed by Wietse Venema, one of the most regarded Linux developers, at IBM's TJ Watson Research Laboratory, one of the world's best research labs.

I have fond memories of the Watson Lab, because this was where I first learned to program, in APL on the mighty IBM 360/90. I also got to play with high voltage, high vacuum, and low temperatures there.

The postfix program was designed from the ground up with security in mind and using the "Rings of Security" model to minimize single points of security failure. One of the techniques employed is the use of separate cooperating processes to interact with the Internet, to receive locally originated mail, and to deliver mail locally. The processes interacting with the Internet do not have the authority to do anything harmful.

Only one of the processes that comprise postfix, the master, operates as root and it does not interact with the Internet; all the postfix programs may be chrooted. By having separate processes in this way, in order to break into a system, a cracker has to break several processes rather than just one, which is much harder.

This is different from Sendmail, which operates a single root process so that if any one line of code that can be executed has a security hole, the program is compromised. (In Appendix A, a URL is supplied where it is explained how to configure Sendmail to not run as root.) The postfix program may be downloaded from one of the mirrors linked from

www.postfix.org/

4.2.1 Separate or Multiple Mail Servers for Additional Security

It is hoped that recent versions of Sendmail are secure. I am not aware of any reports of vulnerabilities in Sendmail 8.10, assuming that it has been configured properly. It offers some automatic checks for certain common errors in configuration that can compromise security. Because of past security problems, many sites choose to dedicate a separate system in the DMZ to handle only mail. Thus, if a vulnerability is found, there is much less that can be damaged. This damage is limited because the only thing of value on this system is e-mail in the spool directory. This would be e-mail that is awaiting download via POP or IMAP. If it is confidential, it should be encrypted with PGP anyway.

Some sites will go a step further, and have two mail servers one externally visible in the DMZ (the external mail server or Xmail), and one inside the main firewall (the internal mail server or Imail). Mail coming in from the Internet goes to Xmail which then sends it to Imail. Imail then makes it available to users, possibly via POP or IMAP. The Xmail server could intensely filter out spam, as discussed in "Blocking Spam" on page 185. E-mail generated internally that is destined for the Internet goes to Imail, which then sends it to Xmail. Xmail sends it on its way.

The firewall rules between the DMZ and internal network would block all port 25 traffic and all traffic from or to Xmail, except that it allows traffic to port 25 of Imail from Xmail and to port 25 of Xmail from Imail. This configuration prevents external sites from directly attacking any systems inside the firewall. Internal e-mail does not leave the firewall-protected internal environment. Two systems (Xmail and Imail) must be compromised, one through a firewall, before a cracker can even start an attack on a nonexpendable internal system.

4.2.2 Basic Sendmail Security

Keep in mind that normally sendmail runs as root, and accesses a great many different files. Those that are configuration files (and all directories leading to them) must have the correct permissions and ownership for proper security. For example, if /etc/sendmail.cf is writable by all, there is no security.

In Red Hat 7.3, sendmail.cf is in /etc, sendmail is in /usr/sbin, and the mqueue directory is in /var/spool. These may be different in other distributions. The sendmail program, sendmail.cf, and /var/spool/mqueue should all be owned by root and only the owner should have write permission. There is no reason for any of them to be readable by other than the owner, root, though this should not make much of a security difference. The sendmail program must be set-UID to root in a normal installation, where it runs as a daemon.

See "Sendmail Without Root" on page 746 for the URL to a site that explains how Sendmail may be configured to not need to run as root, and also where it may be invoked from inetd to enjoy the benefits of TCP Wrappers.

The other configuration files that Sendmail uses (and their directories) must not be world writable. This is particularly true for

 aliases aliases.db mailertable mailertable.db 

The alias capability allows the SysAdmin to arrange for e-mail sent to certain addresses to be sent to any program as standard input. This is a wonderful and powerful feature that has many uses. It can be used to cause almost any event to happen, such as generating mailing list digests, operating X10 devices,^[1] and updating the /etc/hosts files of neighboring systems when a system with dynamically changing IP address suffers a change.

^[1] X10 is a set of inexpensive remote control devices for controlling almost any electrical device for home and business use that are quite popular. They may be controlled by any computer with a serial connection and there is software available for Linux. Use of X10 devices is discussed in "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559.

Because the invoked program runs as root, using this feature creates security holes unless the program is written very carefully. The problems are very similar to those of CGI programs, except that CGI programs normally do not run as root.

Verify that your Sendmail version does not support the debug, wiz, or kill commands. This may be tested by connecting to your Sendmail and issuing these commands thusly.

 telnet mail.pentacorp.com smtp 220-mail.pentacorp.com Sendmail 8.9.3/8.8.7 ready at 6 Sep 2000 22:20 220 ESMTP spoken here wiz 500 Command unrecognized debug 500 Command unrecognized kill 500 Command unrecognized quit 221 mail.pentacorp.com closing connection Connection closed by foreign host. 

In this example, the Sendmail tested does not support these insecure commands, so it is safe from these threats. If you get any response other than 500 Command unrecognized, you need to upgrade your version of Sendmail.

For older Sendmail installations, search the /etc/sendmail.cf file for a line starting

 OW 

The "O" command is enabling the "W" option. If the "W" option is enabled, the wizard's password will be accepted; many crackers know what it is. The following command will do this:

 grep '^OW' /etc/sendmail.cf 

This would be the wizard's password. If it does not look like the following line, then it should be changed to look like it. This will disable the wizard's password. Failure to do so will offer a shell to anyone who knows the wizard's password.

 OW* 

Inspect the /etc/aliases file and analyze any alias that outputs to a program or file instead of a mailbox. Remove the decode alias, if present, because it opens up a vulnerability; it will look like

 decode: "|/usr/bin/uudecode" 

Even better than removing the decode alias, send its e-mail to root to alert yourself to possible attacks with the entry

 decode: root 

E-mail can accumulate in the mailbox of any account in /etc/passwd. Some of these accounts are not for human use. E-mail sent to these accounts should be rerouted to accounts whose mailboxes are read by a SysAdmin (or thrown away) to avoid megabytes being accumulated over time. Be sure to offer abuse, Postmaster, and MAILER-DAEMON mailboxes since all these are expected by net etiquette. Many sites also offer sales and support. The following would be typical.

 root:           sysadm sales:          jtfasttalker support:        nopatience sysadm:         spock abuse:          root Postmaster:     root MAILER-DAEMON:  Postmaster bin:            root daemon:         root adm:            root lp:             root sync:           root shutdown:       root halt:           root mail:           root news:           root uucp:           root operator:       root games:          root gopher:         root ftp:            root nobody:         root xfs:            root gdm:            root 

After any changes to the /etc/aliases file, issue the command

 newaliases 

to compile the /etc/aliases file into the /etc/aliases.db database that Sendmail actually uses. The newaliases command will not be necessary if the line

 O AutoRebuildAliases 

is present in the /etc/sendmail.mc file. In this case, the line

 Oa5 

will cause the /etc/aliases file to be compiled into /etc/aliases.db within five minutes of its being changed. (Older versions of Sendmail used ODTrue instead.)

4.2.3 Sendmail Security Options

Recent versions of Sendmail have a number of security options that most sites will want to use. First, the options and their effects will be discussed. Then, how to enable them will be explained. Setting the "authwarnings" privacy option will cause sendmail to issue a warning if it detects certain insecure features in the configuration. Sendmail offers the VRFY (verify) command that any Internet site may use to ask your Sendmail if a given name is a valid e-mail address. Spammers use this to guess e-mail addresses. They will try joe, dan, sally, smith, and so on, noting those that are valid, for later spamming. A cracker can use this technique to determine account names to then start guessing passwords on, making his job much easier. Because Sendmail does not need to fork any processes, lock any mailboxes, or do anything else that is time-consuming, this is a very efficient and quick operation for the spammer. You will want to remove the efficiency so that the spammer cannot harvest as many e-mail addresses.

A user's e-mail name can be different from the account name to keep the account name secret from crackers. The sendmail /etc/alias file may be used to route incoming e-mail to the appropriate account. There are several choices for translating outgoing e-mail. Some mailers will use the $REPLYTO environment variable to specify the sender, if it is defined. Alternatively, you can place an entry in the appropriate sendmail table.

Almost all sites should disable the VRFY command. This is done with the "novrfy" privacy option.

The EXPN command is similar to the VRFY command in that EXPN will expand (reveal) the actual delivery addresses of mail aliases and mailing lists. This will allow the collection of more e-mail addresses in case you later decide to block access to the alias from the Internet. For example, to see what the all mailing list expands to, assuming it exists, issue the following request to sendmail:

 EXPN all 

This EXPN is disabled with the "noexpn" privacy option.

Similarly, the "restrictmailq" privacy option should be specified to prevent Sendmail from telling anyone who asks what is in the mail queue. It will let only those in the same group as the mail queue directory see this data.

The "needmailhelo" privacy option will require the client system to identify itself with a HELO command before mail will be accepted from it. The HELO command will cause the sending system's host name and numeric IP address to be logged via syslog. If the sending system is running ident (the auth service), the user name or UID will also be logged. Thus any shenanigans can be traced back to the perpetrator. If the perpetrator owns the sending system, he can send fake ident data, of course.

By default, Sendmail will not enforce a limit on the number of children that the daemon will fork, when listening on port 25. This allows a DoS attack by sending so many messages to your system in a short period of time that the process table or the number of open file descriptors is saturated.

Certainly, an attacker can start one TCP connection to port 25, have the initiating program sleep, start a second TCP connection to port 25 to spawn a second child, and repeat. An attacker could use multiple compromised systems.

The antidote to this DoS is to add the

 confMAX_DAEMON_CHILDREN 

define to /etc/sendmail.mc, specifying the maximum number of children you will allow at one time. This will add the

 O MaxDaemonChildren=25 

line to the generated sendmail.cf file. See Table 4.1.

The sendmail program shares a problem with several other parts of Linux, including named, ftpd, and the typical telnetd configuration file. This problem is that sendmail happily tells any computer that asks what its version number is. This makes it easier for crackers to know which vulnerabilities to apply.

Again, back around 1980 it was a good idea to help debug compatibility problems between systems. Today it is a poor idea. It allows crackers to catalog the world's active sendmail processes, and wait for new vulnerabilities to be discovered in particular versions. Then, they instantly know which systems they can break into.

The solution is another "one-liner." Change the greeting message to not include the "$v" macro that tells Sendmail's version or the "$Z" macro that reveals the sendmail.cf version. The latter is a strong hint as to what range of versions the sendmail program could be. A text editor may be used to remove the strings

 $v 

and

 $Z 

from the /etc/sendmail.mc file.

To enable all these security features, which is suggested, ensure that /etc/sendmail.mc includes all the entries in Table 4.1.

[View full width]

 define(`confPRIVACY_FLAGS',authwarnings novrfy  noexpn restrictmailq needmailhelo) define(`confMAX_DAEMON_CHILDREN',25) define(`confSMTP_LOGIN_MSG',$j Sendmail Secure/ Rabid; $b) 

After editing /etc/sendmail.mc, issue the following shell commands to have your changes take effect.

 m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart 

Note that m4 is the Linux and UNIX general macro processor. The /etc/sendmail.mc file includes the main definition file, /usr/lib/sendmail-cf/m4/proto.m4. The most commonly altered items are listed in /etc/sendmail.mc; this is to free most SysAdmins from learning the challenging details of the sendmail.cf file. It is important to note that /etc/sendmail.cf now is generated by the m4 command shown above; it no longer is edited directly. Instead, to alter items not listed in /etc/sendmail.mc, editing /usr/lib/sendmail-cf/m4/proto.m4 is necessary.

To check that your changes worked and that VRFY and EXPN have been disabled, use telnet to connect to port 25 (smtp) and issue these commands to verify that sendmail refuses to honor and obey them.

 telnet mail.pentacorp.com smtp 220-mail.pentacorp.com Sendmail Secure/Rabid; 6 Sep 2000 22:25 220 ESMTP spoken here VRFY foobar 252 Cannot VRFY user; try RCPT to attempt delivery (or try finger) EXPN foobar 502 Sorry, we do not allow this operation quit 221 mail.pentacorp.com closing connection Connection closed by foreign host. 

Sendmail documentation suggests using finger but you disabled it too, of course, as discussed in "Do Not Get the Finger" on page 94. Unfortunately, the attacker can still deprive others of being able to send e-mail to the system on a timely basis. There is not a good solution to this problem. Certainly, the ports program or netstat will indicate if this is a problem because they will show lots of connections to your port 25 from a particular system. Once such a problem is discovered, a firewall rule to block traffic from the offending system will solve the problem within seconds.

One possibility for protecting against this problem automatically, suitable only for the brave, is to modify the sendmail source code, where it keeps track of how many children still are running. In the table where it keeps track of running children, add a field to store the IP address (or host name) of the system that it is connected to. When a new connection is received, search that table and count the number of pending connections with that IP address. If it exceeds some value, perhaps half of the allowed number of connections (MaxDaemonChildren), close the port and treat it like an error.

An appropriate error would be the same one that would occur if MaxDaemonChildren would be exceeded. If it was a legitimate connection, the client system will try again later. Stateful firewalls that are sufficiently smart will handle this problem too. Online documentation to assist with configuring Sendmail may be found at

www.redhat.com/support/docs/howto/RH-sendmail-HOWTO/book1.html

www.sendmail.com

www.sendmail.net

www.sendmail.org

4.2.4 Forging Mail and News Sender's Address

The sender's address that appears on received e-mail or on a Usenet News (Network News) post is generated by the sender's system. Similarly to the security deficiencies in NFS, this method of data transmission dates back to more than 30 years ago when only trusted researchers on U.S. Department of Defense sponsored sites were on what later would become the Internet. Forging a mail message's sender name does not even require root access because the unprivileged mail program that is the front end to sendmail generates these. Heck, one does not even need sendmail. Using telnet and specifying a destination port of 25 (SMTP) instead of the default port 23 one can inject bogus mail directly into the recipient's system. Sendmail will generate a may be forged error when an untrusted user claims to be someone else. A demonstration of mail forging is presented in "Mail Spoofing" on page 253.

The solution to forged mail is to recognize that mail headers and News headers can be spoofed easily and to not trust them. Use PGP-style signed and encrypted e-mail, verifying that the recipient has the sender's nonspoofed PGP-style public key and that the sender has the recipient's. It is important to educate your users about this. See "Pretty Good Privacy (PGP)" on page 430 and "Using GPG to Encrypt Files the Easy Way" on page 431.

4.2.5 Where Is All That Spam Coming From?

It seems like every fool looking for a get-rich-quick scheme has discovered spam. Spam is to e-mail what junk mail is to paper mail. Simply, it is e-mail sent to people with no association with the sender. The vast majority of recipients have absolutely no desire to receive the mail. Their companies and ISPs certainly do not want their resources wasted on it.

The term spam comes from a Monty Python television skit in which a group of Viking warriors start chanting "spam, spam, spam" so loudly that they drown out all other conversations, similarly to the problem of unsolicited commercial e-mail (junk e-mail) seeming to drown out legitimate e-mail.

Although all manner of capitalizations of the term are seen, I will follow the example of the U.S. Congressional Record, March 25, 1999, page S 3511 in which Sen. Frank Murkowski (R-AK) introduces Senate Bill S 759, the Inbox Privacy Act of 1999.

Spammers get their lists of e-mail addresses of people to annoy in a variety of ways. The following are some of the ways:

• Scan Usenet (Network) news group postings and harvest the posters' e-mail addresses.

• Run Web 'bots that scan Web pages for e-mail addresses by recognizing text around "@" characters.

• Generate lists of domain names (via Web 'bots and other means) and proceed from there.

• Interrogate each domain's sendmail to obtain e-mail addresses. They can use the sendmail EXPN command with likely mail groups such as all and engineering.

• Use the sendmail VRFY command to guess accounts by specifying common first and last names.

• For sites that do not support EXPN or VRFY they can simply send e-mail to all the names that they otherwise would have fed to EXPN or VRFY and note the ones that do not "bounce."

  It is common for spammers to say send e-mail to remove_address to get taken off of their mailing list. In many cases that is just a ploy to get recipients to validate that the e-mail guess was correct and will have the opposite effect. In other words, by sending e-mail to the remove_address list, you actually are adding your e-mail address to the spammer's list.

• Bait FTP sites to get clients to supply their e-mail addresses as the password for an anonymous login.

• Trade names with other spammers and those selling lists of names.

Some ways to reduce spam are listed here:

• Disable the VRFY and EXPN sendmail commands, as discussed in "Sendmail Security Options" on page 179.

• Do not list more e-mail addresses on your Web site than you need to. Each additional e-mail address listed will attract spam.

• Consider having your users not supply valid e-mail addresses if they post to Usenet news. Some people will "munge" their e-mail address when posting and include textual instructions on how to "unmunge." One example might be

   [e-mail] (remove "edy" to send email) 

  or

   auser at pentacorp dot com 

  or

   [e-mail] (change "gov" to "com") 

  The latter is effective because many spammers will not send to .gov sites as they do not want the FBI after them. Some spam address collectors are smart enough to get an address despite these tricks.

• If your ISP offers anti-spam features use them.

• If your ISP enforces reasonable restrictions on outbound mail to control spam try to accept them. It is becoming common for ISPs to require their subscribers to route all e-mail through their sendmail ports where they do some validation on the specified source address. This is so that they do not harbor spammers. Some may have overly restrictive policies, however.

• Use the Realtime Blackhole List to automatically reject spam. This is discussed in "Blocking Spam" on page 185.

4.2.6 Drop-Shipping Spam (Relaying Spam)

Prior to Sendmail 8.9, any Sendmail program would happily accept e-mail from any system in the world and forward it to any other system in the world. This was great for spammers. They could send a single piece of e-mail to your system with 100 recipients on other systems and let your system use up its bandwidth and computrons sending out 100 e-mail messages. Further, because they would give a phony return address you would be blamed as the originator of the spam.

Fortunately, as of 8.9, Sendmail will only accept e-mail where either the recipient or sender is within their domain unless relaying is enabled. Additionally, as of 8.9, Sendmail normally will not accept e-mail if the From: address has a domain that is not real. Unfortunately, Sendmail is not smart enough to verify that the claimed From: address matches the numeric IP that is connecting to sendmail.

4.2.7 Blocking Spam

There is the Realtime Blackhole List that is run by the MAPS project at http://maps.vix.com/. They accept reports of spammers and add them to the list. It is hard to get off the list. Both the actual spammers and any site that spam is relayed through (due to sloppy configuration by the SysAdmin) is a good candidate for this list.

Add the line

 FEATURE('rbl') 

to the /etc/sendmail.mc file to enable the Realtime Blackhole List. Then cause this feature to take effect with the following shell commands:

 m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart 

By configuring your sendmail to query this site as to whether each piece of e-mail is spam, you will greatly reduce spam.

4.2.8 Spoofing Spam Robots

Spammers are not content just to get e-mail addresses from mailing lists and News groups. Some also search everyone's Web pages looking for addresses. Those "@" characters give it away, as does mailto: in the document. Some sites have taken to using dynamic pages to create an infinite number of generated links with bogus e-mail addresses. This wastes the spammer's cycles and bandwidth, both on getting these bogus pages and on sending e-mail to fake addresses. I do not have more details on how to do this but I am sure you can figure out basic techniques.

One such program for generating these pages with fake e-mail addresses is called wpoison. It is available from

www.novia.net/~doumakes/abuse/

This site has other anti-spam ideas including various filters.

I do hope that if anyone does this, they make the effort not to confuse "good" search engines such as altavista.com and google.com. The "good" search engines will respect your asking them to avoid certain pages (such as the spam 'bot spoofing pages). Please do refer to "Robot Exclusion of Web Pages" on page 287 for the details on how to do this.

4.2.9 llowing Controlled Relaying

There are several features to enable some relaying without opening up your mail server to spam attacks. To enable relaying from all hosts within your domain, add the following to /etc/sendmail.mc:

 FEATURE('relay_entire_domain') 

Then cause this feature to take effect with the following shell commands:

 m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart 

The /etc/mail/access file may be used to reject e-mail from specified sites and to allow mail from sites that otherwise would be rejected. After editing this file, issue the following commands to cause the changes to take effect:

 makemap hash /etc/mail/access < /etc/mail/access/ etc/rc.d/init.d/sendmail restart 

Each line of /etc/mail/access is an entry. The first field of each line is an address that you want to work with. It may be an e-mail address, a domain, a fully qualified host name, or part of an IP address. This field should be separated from the next with one or more spaces or tabs. The next field should be an instruction telling sendmail what to do with e-mail from this address. Valid values are listed in Table 4.2.

Table 4.2. /etc/mail/access Instructions

Instruction	Meaning
OK	Accept e-mail unconditionally.
RELAY	Accept e-mail and allow relaying unconditionally.
REJECT	Reject e-mail with a standard rejection message.
DISCARD	Throw message away without bouncing it back to sender. This feature only works for matching senders, not recipients.
### text	### must be a RFC 821-compliant error code.[a] text is the message to return to the sender.

^[a] RFC 821 is available at www.faqs.org/rfcs/rfc821.html.

As an example, say you want to reject e-mail from [e-mail], anyone in the cracker.com domain, or in the 10.1.*.* network. You want to say Spammer, go home to anyone at stocktips.com, but you will accept e-mail from friend.stocktips.com. Because you see spam from eternal_youth@ from a variety of hostnames, you want to reject it too. And you want to relay for pentacorp.com.

The following entries in /etc/mail/access would be needed:

 [e-mail]  REJECT cracker.com             REJECT 10.1                    REJECT friend.stocktips.com    OK stocktips.com           550 Spammer, go home eternal_youth@          550 Spammer, go home pentacorp.com           RELAY 

Note that the difference between OK and RELAY is that OK allows that site to send mail into your sites but RELAY also allows e-mail from that address to be sent back out onto the Internet (relayed).

You also can blacklist recipients by adding the following line to /etc/sendmail.mc:

 FEATURE('blacklist_recipients') 

You then will need to issue the following commands to enable this:

 m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart 

Once the blacklist_recipients feature is enabled, recipients may be blacklisted. To reject e-mail addressed to account george, demo.pentacorp.com, and [e-mail], the following lines in /etc/mail/access will work.

 george                 550 George is on safari until February demo.pentacorp.com     550 It is a demo system, get a life [e-mail]  550 We fired her 

After changing /etc/mail/access, be sure to restart Sendmail thusly:

 /etc/rc.d/init.d/sendmail restart 

4.2.10 Allowing POP and IMAP Clients to Send Mail

Dynamic relay authorization control (DRAC) interfaces with your POP or IMAP server to temporarily allow Simple Mail Transfer Protocol (SMTP) relay access from client systems that have picked up mail from your network recently, typically in the past 30 minutes. This is reasonably secure because both POP and IMAP require an account and password. The "reasonably" is because only the SSL-wrapped versions of these (SPOP and SIMAP) encrypt the password before sending over the Internet. If one of the SSL-wrapped versions of mail download clients used (SPOP or SIMAP), then this arrangement would have good security as there is but a small window of opportunity for someone else (e.g., whoever might get the dynamic IP address within 30 minutes of a client system transferring mail to inject spam).

This is an elegant solution for traveling employees as it allows their e-mail to appear to originate from your site and yet it prevents someone else from spamming you later from the same network or dynamic IP address. DRAC uses RPC to communicate between the POP/IMAP and SMTP servers. Since RPC is considered an insecure protocol, be sure to block access to RPC from other systems with IP Tables or IP Chains.

Information on DRAC and downloads are available from

http://mail.cc.umanitoba.ca/drac/index.html

4.2.11 Disallowing Open Mailing Lists

An open mailing list is defined as one where anyone can send mail to that mailing list and it will be forwarded to everyone on that list. Large open lists are discouraged because of the spam potential, especially where some of the recipients are outside the organization maintaining the list.

Large open lists can end up in the Realtime Blackhole List and that is very bad. This is because many of the list recipients' Sendmail configurations then will reject any e-mail from that list and because it is hard to get out of the Blackhole.

The Sendmail alias capability (when a name expands to more than one recipient) is an example of an open list. Majordomo can be configured so that lists are closed. A closed list only accepts e-mail from someone on a list of senders. Commonly, this list of allowed senders is the list of recipients, for unmoderated lists. GNU Mailman is another popular mailing list manager.

4.2.12 Sendmail DoS by Filling the Disk Up

An attacker can create a DoS attack by sending so much e-mail that the system's disk is filled up. One of the reasons most files that can "grow" without user input are under /var is that this allows /var to be a separate file system. By having it be a separate file system, if /var runs out of space it will not affect the operation of the rest of the system.

The other reason for /var is that /var is short for /variable. Besides /tmp and /home, it is the only part of the system that could not be mounted read-only and shared across diskless workstations. (/usr/tmp is a symbolic link to /var/tmp.)

This was popular back in the Sun days when disks were expensive and the more parts of the systems that were the same, the less maintenance burden there was. Microsoft has put some of this concept into practice in Windows 2000. With embedded Linux becoming popular, it again is becoming popular.

A better solution is to impose quotas on users under the /var file system. Thus, each user could be limited to a reasonable amount of e-mail. An even better solution is to put a quota on the mail group. Because the mail group is only used for e-mail then a mail group quota will work regardless of whether /var is a separate partition. Recall that the quota set for a user or group is a per-file system value.

The following command will list the amount of space each mailbox is using, with the largest mailboxes listed first.^[2]

^[2] The "graybeards" may not be familiar with ls's -S flag that causes the listing of files to be sorted by file size, with the largest listed first.

 ls -sS /var/spool/mail 

The following command lists the largest 20 mailboxes and mails the result to root. It is suitable for use in root's crontab.

 ls -sS /var/spool/mail | head -20 | /bin/Mail -s mailboxes root 

---

Top