Differences between Sun sendmail and Berkeley sendmail

This document describes the differences between recent versions of sendmail: Berkeley 8.X vs. 8.X+Sun, which ships with Solaris 7 and later.

• Section 0 lists which versions of sendmail are shipped with Solaris.
• Section 1 actually starts out by noting differences, not between Sun and Berkeley, but between Sun's previous version of sendmail and this new one, using the same old V1/Sun configuration file.
• Section 2 compares how Berkeley's and Sun's binaries differ when using the same new V*/Berkeley configuration file.
• Section 3 explains the semantics differences between a V*/Berkeley config file and a V*/Sun config file which are otherwise identical.
• Section 4 details V1/Sun backwards compatibility mode.
• Section 5 goes into the differences between the default config files shipped for Solaris with Berkeley sendmail vs. Solaris' main.cf and subsidiary.cf.

0. Which versions of sendmail are shipped with Solaris

Solaris	initially	latest patch	in progress	planned
2.5.1	SMI-8.6	8.8.8+Sun	nothing further	nothing further
2.6	SMI-8.6	8.8.8+Sun	nothing further	security fixes only
7	8.9.1b+Sun	8.11.7+Sun	nothing further	security fixes only
8	8.9.3+Sun	8.11.7+Sun	nothing further	security fixes only
9	8.12.2+Sun	8.13.7+Sun	nothing	TBD
10	8.13.3+Sun	8.13.7+Sun	nothing	TBD
Nevada	8.13.8+Sun	N/A	8.14.0+Sun	TBD

1. Behavioral differences between SMI-8.6 and 8.X+Sun using the same V1/Sun configuration file

First, note that this section was originally written shortly after the migration from SMI-8.6 to 8.8.8+Sun which was introduced via patches for Solaris 2.5.1 and 2.6, and in Solaris 2.7 Beta (just before FCS, what had been Solaris 2.7 got renamed to Solaris 7); this was in early 1998. Seamless migration was a major goal. After several years had passed, this had more or less been accomplished, and old V1/Sun configuration files had become a problem, as they had several bugs which could only be fixed by upgrading to a new configuration file format. So for Solaris 9 and later, support for these by then (mid-2002) ancient configuration files was dropped.

---

One of the functional goals of this new version is that the new binary, running with the same V1/Sun configuration file as an old binary, will behave identically, except for bug fixes and security enhancements.

1.1 NoRecipientAction (option to emulate old behavior exists)

When a message arrived with no To: or Cc: header, older versions of sendmail would add an Apparently-To: header, whose value was the recipient as specified in the SMTP transaction. This behavior was in violation of RFC 1123, so an option was added to make it configurable.

The new default behavior is not to add any header in such circumstances; this is what will occur when running a new binary with an old V1/Sun config file. Since all properly formatted messages contain a To: header, this is a corner case. Note also that this will not break any MUAs.

1.2 Directory Permissions (security)

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.

2. Behavioral differences between 8.X and 8.X+Sun using the same V*/Berkeley configuration file

Because of the differences in timing between releases of Berkeley sendmail and releases of Solaris, at any given time there may be some minor bugs fixed in one but not yet fixed in the other. Modulo that, however, there should be no behavioral differences between Berkeley version foo and the version foo+Sun shipped with Solaris. (As noted, at this writing, foo=8.13.8, though this is also known to hold for foo=8.8.8 and later, as well as V7/Berkeley, V8/Berkeley, V9/Berkeley and V10/Berkeley.)

3. Behavioral differences between a V*/Sun config file and a V*/Berkeley config file when run by the same 8.X+Sun binary

There is no specific goal regarding the functional difference between V*/Sun and V*/Berkeley, though there is a general goal to keep such differences to a minimum. Fortunately, few have been required.

3.1 Content-Length

Messages to files and programs will include a Content-Length: header in V*/Sun mode but no such header in V*/Berkeley mode. Note that these are not the same as messages to mailboxes; for such messages, both modes will result in this header being present, as mail.local(1M) adds it. Note also for messages to files in V*/Sun mode that mail.local adds this header as well: sendmail calls mail.local using a new option, telling it to append to the specified file rather than the specified mailbox. For this reason, a new version of mail.local is provided with the 8.8.8+Sun version of sendmail, as well as with subsequent versions.

Note: the above paragraph holds for 8.8.X and 8.9.X; however, as of 8.10.X, V*/Sun mode has moved even closer to V*/Berkeley mode: messages which are piped to programs will not have a Content-Length: header in either mode.

Note further that as of the fix for Sun bug 4756570 (this fix is present in the latest sendmail patches for Solaris 7 and later), that even file delivery is no longer different between the two modes, and this sub-section has become obsolete.

3.2 Domain name look-up

Starting with 8.7, sendmail tries to determine its fully-qualified host name at start-up, essentially by doing a gethostbyname(`hostname`) and checking h_name and h_aliases for a name with a dot. Note that the service switch is obeyed in this look-up. If no such fully-qualified name can be found, sendmail sleeps for 60 seconds before trying again on the premise that a temporary name service failure may have occurred. After the sleep, if it still cannot determine the fully-qualified host name, it gives up trying to do so and continues, using a short name. Note that on a properly configured system this should never happen. Anyway, in V*/Sun mode, a call to getdomainname() is made prior to the sleep; if successful, the sleep is avoided, and the name provided by getdomainname() is used, minus its first label. No such call is made in V*/Berkeley mode. Unfortunately, however, this start-up code happens before the configuration file is even read, so V*/Sun mode is essentially in effect regardless.

Note: using the NIS domain name to fully qualify the host name as described above is needed in V*/Sun mode for backward compatibility; however, it is not recommended. A Bourne-shell script, check-hostname.sh, which can check for such a configuration and recommend corrective action, is provided. Note that on a Solaris 7 or later system, this script can be found at /usr/lib/mail/sh/check-hostname and is described by the check-hostname(1M) man page. Note further than in Solaris 10 this script has migrated to /usr/sbin/check-hostname though a symbolic link from the old location is still provided.

3.3 Simplified LDAP

In V*/Sun mode, if ldap is listed as a method for aliases in /etc/nsswitch.conf, then an internal method will be used for retrieving LDAP aliases; this will not occur in V*/Berkeley mode.

4. Behavioral changes in 8.*+Sun when in V1/Sun Backwards Compatibility Mode

The 8.X+Sun versions were designed to be as close as possible functionally to the corresponding 8.X Berkeley version while also trying to maximize backwards compatibility with old V1/Sun configuration files. (N.B.: see caveat below.) These V1/Sun config files are called such because of the sendmail.cf version directive V, which takes a numeric argument optionally followed by a slash and a vendor name. The older SMI-8.6 versions of sendmail used V1/Sun config files. The newer modes are V7/Sun for sendmail 8.8.8+Sun, V8/Sun for 8.9.X+Sun, V9/Sun for 8.10.X+Sun and 8.11.X+Sun and V10/Sun for 8.12.X+Sun . For a config file with no V directive, the default has been V1/Sun.

Caveat: V1/Sun config files do not have any anti-spam features, and cannot be fixed. They are also subject to at least one nasty denial of service attack. We strongly recommend that any machine connected to the Internet be running at least version 8.8.8 (binary and config file), but preferably 8.9.3 or later. Otherwise, you may very likely find your site listed by ORBS and/or MAPS. Note also that starting with Solaris 9, V1/Sun backwards compatibility support is removed.

Most new features introduced in 8.7 and later work regardless of the mode, but some behavioral differences exist between the modes. Section numbers below refer to the 2nd edition O'Reilly book sendmail.

V1/Sun Backward Compatibility

What	Description
$k	The $k macro contains the value of the mail hub machine (see §D.6).
$m	The $m macro contains the name of the parent domain.
$%	The $% prefix can be used in the LHS to evaluate the $%l, $%y and $%z macros.
${	${ and $} are a synonym for $( and $) (see §33.4).
$j	The $j macro is not automatically included in $=w (see §32.5.8), nor is it required to contain a dot.
owner-	The owner- (see §25.3) of a mailing list is not set as the envelope sender when processing a :include:.
DNS	When making DNS lookups, RES_DNSRCH (search subdomains) and RES_DEFNAMES (append the local domain) are automatically disabled.
aliases	Duplicate left-hand side entries in the aliases(5) file are silently ignored.
K	The K configuration command (see §33.3) is disabled.
VRFY	The VRFY and EXPN SMTP commands (see §22.3.2) provide the same information. That is, they both act like EXPN.
F=g	The F=g delivery agent flag (see §30.8.22) cannot be turned off, even if it is omitted. That is, the special address <> is never used as the sender of bounced mail.
shells	A user with any shell is allowed to redirect mail to programs or files (see §22.8.4 for how this differs from current behavior).

Probably the four most important of these are the owner- behavioral difference, the disabling of the K command, the shells issue and the F=g delivery agent flag.

• Not using owner- prevents mailing list bounces from going to the proper address. The owner- section on the migration page discusses this in detail.
• The K command is used to define map classes, i.e., associate a symbolic name with a database file, where the symbolic name will later be used in the RHS of rules. The ability to use this feature makes virtual hosting much easier, and is required for some of the new anti-spam features.
• The shells issue is a potential hazard, as migrating without paying close attention to this can result in aliases and .forwards that redirect messages to files and/or programs to stop working. The /etc/shells section on the migration page discusses this in detail.
• The F=g delivery agent flag was added to work around a bug in very old Solaris (pre-2.3) config files in which the special reserved address <> led to an infinite loop in the address-rewriting rule-sets. Ironically, later Solaris V1/Sun config files were subject to a different infinite loop type bug caused by the F=g flag. Per section 5.3.3 of RFC 1123, the address <> is reserved to prevent bounce storms: a bounce is never sent for any message whose return path is <>. But since F=g causes an alternate return path to be used, a loop can ensue which leads to a nasty denial of service.

5. Differences between default config files

The sendmail config files shipped with older releases of Solaris have differed radically from the Berkeley config files that corresponded to the same base sendmail version. The config files for 8.8.8+Sun, however, are much more similar to the config files shipped with Berkeley 8.8.8; following are the differences.

5.1 Berkeley's generic-solaris2.cf vs. Solaris' main.cf

5.1.1 pre-Solaris 9

The first 5 items apply to both 8.8.8+Sun and 8.9.3+Sun compared to Berkeley 8.8.8 and 8.9.3 respectively:

1. V7/Berkeley vs. V7/Sun for 8.8.8+Sun (see section 3 above for details); V8/Berkeley vs. V8/Sun for 8.9.3+Sun .
2. Class file /etc/mail/sendmail.cw is optional in the Solaris version.
3. Class file /etc/mail/sendmail.ct is enabled and optional in the Solaris version; Berkeley has this disabled (i.e., commented out).
4. The AutoRebuildAliases option is turned on in the Solaris versions, for backward compatibility with older Solaris releases.
5. The Solaris versions uses mail.local(1M) as the local mail delivery agent instead of /bin/mail. In general, mail.local is preferred, but it was not introduced until Solaris 2.5; therefore, Berkeley cannot safely use it in its generic file.

In addition, the following differences apply only when comparing 8.9.3+Sun to Berkeley 8.9.3:

6. The Solaris version enables the anti-spam weakening features accept_unqualified_senders, accept_unresolvable_domains and relay_entire_domain for backwards compatibility. To get the stronger Berkeley defaults, use DOMAIN(solaris-antispam) instead of DOMAIN(solaris-generic) in your .mc file; see /usr/lib/mail/README for m4 details.
7. Berkeley sets the AliasFile to /etc/mail/aliases; the Solaris version sets it to dbm:/etc/mail/aliases . This is done for backwards compatibility in case any applications have been written which depend on the dbm(3b) API. To get the Berkeley DB API, put define(`ALIAS_FILE', /etc/mail/aliases) in your .mc file after the OSTYPE(solaris2.ml) macro.

5.1.2 Solaris 9 and later

1. V10/Berkeley vs. V10/Sun for 8.12.2+Sun (see section 3 above for details).
2. The Solaris version enables the anti-spam weakening features accept_unqualified_senders, accept_unresolvable_domains and relay_entire_domain for backwards compatibility. To get the stronger Berkeley defaults, use DOMAIN(solaris-antispam) instead of DOMAIN(solaris-generic) in your .mc file; see /usr/lib/mail/README for m4 details.

5.2 Solaris' main.cf vs. subsidiary.cf

Past versions of main.cf and subsidiary.cf have differed significantly from each other. No longer:

1. RemoteMode is enabled in subsidiary.cf but not in main.cf. (Until Solaris 9.)
2. The subsidiary.cf defines SMART_HOST to be mailhost.$m ($m is the local sub-domain); main.cf does not define a SMART_HOST.
3. In the .mc file used to build subsidiary.cf, the LOCAL_NET_CONFIG macro is used to route all messages destined for hosts within the local domain directly to that host, instead of to the SMART_HOST. This is not necessary in main.cf, as that config file is for hosts that know how to route messages properly.

Note that in Solaris 10 (specifically with the introduction of sendmail version 8.13 and its new FallbackSmartHost option), there is no longer a need for separate main.{mc,cf} and subsidiary.{mc.cf} files, so they have been combined into a single sendmail.{mc,cf} pair of files, though the old names are still available as symbolic links pointing to the new names. Solaris is a trademark of Sun Microsystems, Inc. in the United States and other countries.