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 more recent 8.*+Sun versions.
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. Similarly, 8.*+Sun running with an
old V1/Sun config file will disable this feature.
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. Likewise, 8.*+Sun running with an old
V1/Sun
config file will disable this feature. There are two easy work-arounds
to this problem:
- 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.
- 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:
| Value | Action |
|---|
none | just leave it as is |
add-to | add 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.
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.
This is dealt with by 8.*+Sun via the config file version level: if a
V*/Berkeley config file is used, 8.*+Sun behaves just like
Berkeley 8.* and no Content-Length: header will be included.
But if a V*/Sun config file is used, sendmail will calculate
the Content-Length: value just prior to calling the appropriate
program, or mail.local will calculate it for messages passed
to files. See section 3.1 of the web page
titled Differences between Sun and Berkeley versions
of sendmail for more details.
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. Note that 8.*+Sun
has this
MaxAliasRecursion option already compiled in.
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
or the alternative which some Solaris sites prefer:
192.9.9.100 www www.sun.com
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.