• Choose a category
• All
• Classic-Fiction

sendmail detects loops that would cause mail to be forwarded back and forth forever by counting the number of Received lines in a message’s header and returning it to the sender when the count reaches a preset limit (usually 25).7

Each visit to a new machine is called a “hop” in sendmail jargon; returning a message to the sender is known as “bouncing” it. The previous sentence, properly jargonized, would be, “Mail bounces after 25 hops.”8

In addition to lists of users, aliases can refer to:

• A file containing a list of addresses

• A file to which messages should be appended

• A command to which messages should be given as input

Since the sender of a message totally determines its content, these delivery targets were often abused by hackers. sendmail has gotten very fussy about the ownership and permissions on such files and commands. To override sendmail’s paranoia, you must set one of the DontBlameSendmail options, so named to discourage you from doing it. Unfortunately, the error messages that sendmail produces when it encounters unsafe permissions or ownerships are not always clear.

Getting mailing lists from files

The :include: directive is a great way to let users manage their own mailing lists. It allows the members of an alias to be taken from an external file rather than listed directly in the aliases file. The file can also be changed locally without requiring intervention by the system administrator who is responsible for the global aliases file.

When setting up the list, the sysadmin must enter the alias into the global aliases file, create the included file, and chown the included file to the user maintaining the mailing list. For example, the aliases file might contain

sabook: :include:/usr/local/mail/usah.readers

The file usah.readers should be on a local filesystem, not an NFS-mounted filesystem,9

and should be writable only by its owner. To be really complete, we should also include aliases for the mailing list’s owner so that errors (bounces) are sent to the owner of the list and not to the sender of a message addressed to the list:

owner-sabook: evi

See page 557 for more about mailing lists and their interaction with the aliases file.

Mailing to files

If the target of an alias is an absolute pathname (double-quoted if it includes special characters), messages are appended to the specified file. The file must already exist. For example:

complaints: /dev/null

It’s useful to be able to send mail to files and programs, but this feature introduces security concerns and is therefore restricted. This syntax is only valid in the aliases file and in a user’s .forward file (or in a file that’s interpolated into one of these files with :include:). A filename is not understood as a normal address, so mail addressed to /etc/passwd@host.domain will bounce.

LDAP databases cannot refer to a file as an email destination. Some user agents allow you to mail to a local file (such as an outbox folder), but that copy of the message is simply saved by the user agent and is never really sent through the mail system.

If the destination file is referenced from the aliases file, it must be world-writable, setuid but not executable, or owned by sendmail’s default user. The identity of the default user is set with the DefaultUser option. It is normally mailnull, daemon, or UID 1, GID 1.

If the file is referenced in a .forward file, it must be owned and writable by the original message recipient, who must be a valid user with an entry in the /etc/passwd file and a valid shell that’s listed in /etc/shells. For files owned by root, use mode 4644 or 4600, setuid but not executable.

Mailing to programs

An alias can also route mail to the standard input of a program. This behavior is specified with a line such as

autoftp: "|/usr/local/bin/ftpserver"

It’s even easier to create security holes with this feature than with mailing to a file, so once again it is only permitted in aliases, .forward, or :include: