Solaris sendmail.org This document is intended as a guide for users and administrators who are concerned about the issues they may encounter when migrating from Sun's sendmail SMI-8.6 to Berkeley sendmail 8.8 or 8.9 .

owner-

If sendmail gets a message addressed to foo and an alias owner-foo exists, then sendmail will rewrite the SMTP envelope sender to be the single-level look-up value of owner-foo (i.e. the right hand side of the owner-foo alias). This should be foo-request, which should in turn point to the actual owner of the list, in this example bar: 
foo:		:include:/etc/mail/lists/foo
owner-foo:	foo-request
foo-request:	bar
This is explained in greater detail at Q3.15 of the Sendmail FAQ.

This behavior is mandated by RFC 1123 (Requirements for Internet Hosts), § 5.3.6 (Mailing Lists and Aliases). The reason for this is so that bounces will go to the list owner instead of the sender of the message.

The upshot of the change is that when such messages get delivered, the delivery agent (typically mail.local(1M)) sets the Unix From line (sometimes incorrectly referred to as the From-space 'header') or the Return-Path: header to this SMTP envelope sender value rather than the value of the From: header, which indicates who actually sent the message.

For users who are not used to this, it can be confusing. However, most users should be unaffected, as their MUA's scan listing typically uses the From: header instead of the Unix From line. Specifically, mailtool and dtmail use the From: header. The other MUA that ships with Solaris, mailx, is configurable. The default configuration uses the Unix From line, but adding set from to ~/.mailrc or /etc/mail/mailx.rc will fix this.

Note that 8.* sendmail has always behaved this way, though in the SMI-8.6 version this feature was disabled.

A Bourne-shell script, check-aliases.sh, is provided. It checks the various alias files configured in /etc/mail/sendmail.cf for owner- aliases which are misconfigured.

/etc/shells

Starting in 8.6.5, sendmail added a security check; from the RELEASE_NOTES: 
	If a user had an NFS mounted home directory on a system with a
	restricted shell listed in their /etc/passwd entry, they could
	still execute any program by putting that in their .forward file.
	This fix prevents that by insisting that their shell appear in
	/etc/shells before allowing a .forward to execute a program or
	write a file.
Though the SMI-8.6 version is based on 8.6.10, this feature was disabled. There are two easy work-arounds to this problem:
  1. Add the entry /SENDMAIL/ANY/SHELL/ on a line by itself in /etc/shells. This will allow all shells; however, this solution is not recommended.
  2. A Bourne-shell script, gen-etc-shells.sh, is available. It lists the 10 built-in shells allowed by getusershell(3C). It then uses getent(1M) to extract all passwd entries; these are piped to an awk script which extracts the shell information. Once this is cleaned up and some known bogus entries are stripped out, the resulting output is appropriate for creating a new /etc/shells file, which will allow exactly the shells that were allowed previously, but no others.

DSNs

Starting in 8.7, sendmail started using the Delivery Status Notification format defined in RFC 1894 for bounce messages by default. Previously, it had used a proprietary format, as there was no standard. A user without a MIME-capable MUA might get a bit confused by the multipart boundary, but other than that this is a very minor change. This default can be changed by setting the SendMIMEErrors option.

Note that DSNs were designed to be both human-readable and machine-parsable. The format is multipart/report and the three parts are text/plain, message/delivery-status, and message/rfc822, the latter containing the original message.

.forward.machine-name & .forward+detail enabled

Sendmail typically only recognizes $HOME/.forward files. It can be configured, however, to recognize both these and $HOME/.forward.`hostname` files. The 8.8 default is to recognize both, so if a user has such a file lying around as a saved copy they could be in for a surprise. This behavior can be changed with the ForwardPath option. Note that sendmail has always had this ability; the default is what has changed.

Starting in 8.9, the ForwardPath option is set to $z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward. As usual, $z is the user's home directory, and $w is the local host name. The new usage of $h supports the +detail syntax introduced in 8.7 .

NoRecipientAction

If no To: or Cc: header is present in a message, sendmail's old behavior was to add Apparently-To: foo, where foo was the value of the SMTP envelope recipient. The new behavior is configurable (NoRecipientAction option), with five possible values:

ValueAction
nonejust leave it as is
add-toadd To: header
add-apparently-to add Apparently-To: header
add-bcc add empty Bcc: header
add-to-undisclosed add To: undisclosed-recipient:; header

The default behavior is none.

As most users use MUAs which insert a To: and/or Cc: header, this should be extremely minor.

Tightened Security

Starting in 8.9, sendmail is much pickier about checking file modes than previous versions -- in many cases sendmail 8.9 may refuse to read files that 8.8 was happy to accept, such as files in group-writable directories. The reason for this change is that there are cases where this may represent a security problem in your system configuration. If you have cases where you want sendmail to go ahead and read some files (for example, if you have files in group writable directories and you really do control access to the groups properly), then you can use the DontBlameSendmail option to disable selected checks. See our DontBlameSendmail and Enhanced File Security page for some hints on how to use this option.

A Bourne-shell script, check-permissions.sh, is provided. It checks for :include: and .forward files which have bogus file modes.

No Content-Length: header in messages sent to programs or files

The SMI-8.6 version of sendmail kept track of the Content-Length: value needed by Solaris mail user agents for mailbox folder delimiting. Starting in Solaris 2.5, mail.local(1M) took over this function. Since mail.local typically writes to mailboxes, there is no problem for most messages. But for addresses that resolve to files or programs, no Content-Length: header will be included if using Berkeley sendmail. For files that later get used as mailbox folders, or for programs (e.g., procmail) which turn around and drop messages into mail folders, those folders may be unreadable by Solaris mail user agents.

Directory Permissions

The following changes need to be made: 
% chmod go-w / /etc /etc/mail /var /var/spool /var/spool/mqueue
% chown root / /etc /etc/mail
Depending on which release of Solaris you are running, some of these may already be set correctly.

Also, neither any .forward file nor any file that is the object of an alias redirection can be a hard link, if that file resides in a directory that is group- or world-writable. These must be hunted down manually. Fortunately, such configurations are rare.

MaxAliasRecursion

Sendmail has an internal limit to how many levels of indirection an alias can have. Berkeley sendmail has always set this to 10. At some point in the past, Sun bumped this value up to 50. Starting in 8.10, there will be a new option, MaxAliasRecursion, which can be used to increase this value. To get this option in 8.8 or 8.9, you need to compile with the -D_FFR_MAXALIASRECURSION_OPTION flag.

Fully-qualified host names

At start-up, sendmail tries to determine its fully qualified host name. On a properly configured system this is not a problem, but many Solaris systems are configured with the /etc/nsswitch.conf entry: 
hosts: files nis dns
and an unqualified /etc/hosts entry such as: 
192.9.9.100   www
instead of the properly qualified: 
192.9.9.100   www.sun.com www
If sendmail can't find a name for itself that has a dot in it, it will sleep for 60 seconds in the hopes that there was a temporary name-service failure. Correcting misconfigured systems will avoid this unnecessary delay. A Bourne-shell script, check-hostname.sh, is provided. It goes thru the same steps sendmail does, stopping and reporting success if it determines the fully qualified host name; otherwise it suggests how to configure the system correctly.
Solaris is a trademark of Sun Microsystems, Inc. in the United States and other countries.

home