.\" Copyright (c) 1994 Eric P. Allman
.\" Copyright (c) 1988, 1994
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)changes.me	8.2 (Berkeley) 5/3/95
.\"
.\"	ditroff -me -Pxx changes.me
.eh '%''Changes in Sendmail Version 8'
.oh 'Changes in Sendmail Version 8''%'
.nr si 3n
.if n .ls 2
.+c
.(l C
.sz 14
Changes in Sendmail Version 8*
.sz
.sp
Eric Allman
.sp 0.5
.i
University of California, Berkeley
Mammoth Project
.)l
.(f
*An earlier version of this paper was printed in the
Proceedings of the 1994 AUUG Queensland Summer Technical Conference,
Gateway Hotel, Brisbane, March 1994.
.)f
.sp
.(l F
.ce
ABSTRACT
.sp \n(psu
Version 8 of
.i sendmail
includes a number of major changes from previous versions.
This paper gives a very short history of
.i sendmail ,
a summary of the major differences between version 5
(the last publically available version)
and version 8,
and some discussion of future directions.
.)l
.sp 2
.pp
In 1987, the author stopped major work on
.i sendmail
due to other time committments,
only to return to active work in 1991.
This paper explores why work resumed
and what changes have been made.
.pp
Section 1 gives a short history of
.i sendmail
through version 5 and the motivation behind working on version 8.
Section 2 has
a rather detailed description of what has changed
between version 5 and version 8.
The paper finishes off with some thoughts
about what still needs to be done.
.sh 1 "HISTORY"
.pp
As discussed elsewhere,
[Allman83a, Allman83b, Allman&Amos85]
sendmail has existed in various forms since 1980.
It was released under the name
.i delivermail
in 4BSD and 4.1BSD, and as
.i sendmail
in 4.2BSD.
.\"4.0BSD	delivermail 1.10
.\"4.1BSD	delivermail 1.10
.\"4.2BSD	sendmail 4.12
.\"4.3BSD	sendmail 5.52
It quickly became the dominant mail system for networked UNIX systems.
.pp
Prior the release of 4.3BSD in November 1986,
the author had left the University for private industry,
but continued to do some work on
.i sendmail
with activity slowly trailing off
until effectively stopping after February 1987.
There was minimal support done by many people for several years,
until July of 1991 when the original author,
who had returned the University,
started active work on it again.
.pp
There were several reasons for renewed work on
.i sendmail .
There was a desire at Berkeley to convert to a subdomained structure
so that individuals were identified by their subdomain
rather than by their individual workstation;
although possible in the old code, there were some problems,
and the author was the obvious person to address them.
The Computer Systems Research Group (CSRG),
the group that produced the Berkeley Software Distributions,
was working on 4.4BSD,
and wanted an update to the mail system.
Bryan Costales was working on a book on
.i sendmail
that was being reviewed by the author,
which encouraged him to make some revisions.
And the author wanted to try to unify some of the disparate versions of
.i sendmail
that had been permitted to proliferate.
.pp
During the 1987\-91 fallow period,
many vendors and outside volunteers
had produced variants of
.i sendmail .
Perhaps the best known is the IDA version
[IDA87].
Originally intended to be a new set of configuration files,
IDA expanded into a fairly large set of patches for the code.
Originally produced in Sweden,
IDA development passed to the University of Illinois,
and was widely used by the fairly large set of people
who prefer to get and compile their own source code
rather than use vendor-supplied binaries.
.pp
In about the same time frame,
attempts were made to clean up and extend the Simple Mail Transport Protocol
(SMTP)
[RFC821].
This involved clarifications of some ambiguities in the protocol,
and correction of some problem areas
[RFC1123],
as well as extensions for additional functionality
(dubbed Extended Simple Mail Transport Protocol, or ESMTP)
[RFC1425, RFC1426, RFC1427]
and a richer set of semantics in the body of messages
(the Multipurpose Internet Mail Extensions, a.k.a. MIME)
[RFC1521, RFC1344].
Neither the IDA group nor most vendors
were modifying
.i sendmail
to conform to these new standards.
It seemed clear that these were ``good things''
that should be encouraged.
However, since no one was working on a publically available version of
.i sendmail
with these updates,
they were unlikely to be widely deployed any time in the near future.
.pp
There are, of course, other mail transport agents available,
such as
.i MMDF
.\"[ref],
.i zmailer
.\"[ref],
.i smail
.\"[ref],
and
.i PP
.\"[ref].
However, none of these seemed to be gaining the prominence of
.i sendmail ;
it appeared that most companies would not convert to another
mail transport agent any time in the forseeable future.
However, they might be persuaded to convert to a newer version of
.i sendmail .
.pp
All of these convinced the author
to work on a updated version of
.i sendmail
for public distribution.
.pp
The new version of
.i sendmail
is referred to as version eight (V8).
Versions six and seven were skipped
because of an agreement
that all files in 4.4BSD would be numbered as
.q 8.1 .
Rather than have an external version number
that differed from the file version numbers,
.i sendmail
just jumped directly to V8.
.sh 1 "CHANGES IN VERSION EIGHT"
.pp
The following is a summary of the changes between the last commonly
available version of sendmail from Berkeley (5.67) and the latest
version (8.6.6).
.pp
Many of these are ideas that had been tried in IDA,
but many of them were generalized in V8.
.sh 2 "Performance Enhancements"
.pp
Instead of closing SMTP connections immediately, open connections are
cached for possible future use.  There is a limit to the number of
simultaneous open connections and the idle time of any individual
connection.
.pp
This is of best help during queue processing (since there is the
potential of many different messages going to one site), although
it can also help when processing MX records which aren't handled
by MX Piggybacking.
.pp
If two hosts with different names in a single message happen to
have the same set of MX hosts, they can be sent in the same
transaction.  Version 8 notices this and tries to batch the messages.
.pp
For example, if two sites ``foo.com'' and ``bar.com'' are both
served by UUNET, they will have the same set of MX hosts and will
be sent in one transaction.  UUNET will then split the message
and send it to the two individual hosts.
.sh 2 "RFC 1123 Changes"
.pp
A number of changes have been made to make sendmail ``conditionally
compliant'' (that is, it satisfies all of the MUST clauses and most
but not all of the SHOULD clauses in RFC 1123).
.pp
The major areas of change are (numbers are RFC 1123 section numbers):
.nr ii 0.75i
.ip \(sc5.2.7
Response to RCPT command is fast.  Previously, sendmail
expanded all aliases as far as it could \*- this could
take a very long time, particularly if there were
name server delays.  Version 8 only checks for the
existence of an alias and does the expansion later.
It does still do a DNS lookup if there is an explicit host name
in the RCPT command,
but this time is bounded.
.ip \(sc5.2.8
Numeric IP addresses are logged in Received: lines.
This helps tracing spoofed messages.
.ip \(sc5.2.17
Self domain literal is properly handled.  Previously,
if someone sent to user@[1.2.3.4], where 1.2.3.4 is
your IP address, the mail would probably be rejected
with a ``configuration error''.
Version 8 can handle these addresses.
.ip \(sc5.3.2
Better control over individual timeouts.  RFC 821 specified
no timeouts.  Older versions of sendmail had a single
timeout, typically set to two hours.  Version 8 allows
the configuration file to set timeouts for various
SMTP commands individually.
.ip \(sc5.3.3
Error messages are sent as From:<>.  This was urged by
RFC 821 and reiterated by RFC 1123, but older versions
of sendmail never really did it properly.  Version 8
does.  However, some systems cannot handle this
perfectly legal address; if necessary, you can create
a special mailer that uses the `g' flag to disable this.
.ip \(sc5.3.3
Error messages are never sent to <>.  Previously,
sendmail was happy to send responses-to-responses which
sometimes resulted in responses-to-responses-to-responses
which resulted in ....  you get the idea.
.ip \(sc5.3.3
Route-addrs (the ugly ``<@hosta,@hostb:user@hostc>''
syntax) are pruned.  RFC 821 urged the use of this
bletcherous syntax.  RFC 1123 has seen the light and
officially deprecates them, further urging that you
eliminate all but ``user@hostc'' should you receive
one of these things.  Version 8 is slightly more generous
than the standards suggest; instead of stripping off all
the route addressees, it only strips hosts off up to
the one before the last one known to DNS, thus allowing
you to have pseudo-hosts such as foo.BITNET.  The `R'
option will turn this off.
.lp
The areas in which sendmail is not ``unconditionally compliant'' are:
.ip \(sc5.2.6
Sendmail does do header munging.
.ip \(sc5.2.10
Sendmail doesn't always use the exact SMTP message
text from RFC 821.  This is a rather silly requirement.
.ip \(sc5.3.1.1
Sendmail doesn't guarantee only one connect for each
host on queue runs.  Connection caching gives you most
of this, but it does not provide a guarantee.
.ip \(sc5.3.1.1
Sendmail doesn't always provide an adequate limit
on concurrency.  That is, there can be several
independent sendmails running at once.  My feeling
is that doing an absolute limit would be a mistake
(it might result in lost mail).  However, if you use
the XLA contributed software, most of this will be
guaranteed (but I don't guarantee the guarantee).
.sh 2 "Extended SMTP Support
.pp
Version 8 includes both sending and receiving support for Extended
SMTP support as defined by RFC 1425 (basic) and RFC 1427 (SIZE);
and limited support for RFC 1426 (BODY).
The body support is minimal because the
.q 8BITMIME
body type is not currently advertised.
Although such a body type will be accepted,
it will not be correctly converted to 7 bits
if speaking to a non-8-bit-MIME aware SMTP server.
.pp
.i Sendmail
tries to speak ESMTP if you have the `a' flag set
in the flags for the mailer descriptor,
or if the other end advertises the fact that it speaks ESMTP.
This is a non-standard advertisement:
.i sendmail
announces
.q "ESMTP spoken here"
during the initial connection message,
and client sendmails search for this message.
This creates some problems for some PC-based mailers,
which do not understand two-line greeting messages
as required by RFC 821.
.sh 2 "Eight-Bit Clean
.pp
Previous versions of sendmail used the 0200 bit for quoting.  This
version avoids that use.
However, you can set option `7' to get seven bit stripping
for compatibility with RFC 821,
which is a 7-bit protocol.
This option says ``strip to 7 bits on input''.
.pp
Individual mailers can still produce seven bit out put using the
`7' mailer flag.
This flag says ``strip to 7 bits on output''.
.sh 2 "User Database"
.pp
The User Database (UDB) is an as-yet experimental attempt to provide
unified large-site name support.
We are installing it at Berkeley;
future versions may show significant modifications.
Briefly, UDB contains a database that is intended to contain
all the per-user information for your workgroup,
such as people's full names, their .plan information,
their outgoing mail name, and their mail drop.
.pp
The user database allows you to map both incoming and outgoing
addresses, much like IDA.  However, the interface is still
better with IDA;
in particular, the alias file with incoming/outgoing marks
provides better locality of information.
.sh 2 "Improved BIND Support"
.pp
The BIND support, particularly for MX records, had a number of
annoying ``features'' which have been removed in this release.  In
particular, these more tightly bind (pun intended) the name server
to sendmail, so that the name server resolution rules are incorporated
directly into sendmail.
.pp
The major change has been that the $[ ... $] operator didn't fully
qualify names that were in DNS as A or MX records.  Version 8 does
this qualification.
.pp
This has proven to be an annoyance in Sun shops,
who often still run without BIND support.
However, it is really critical that this be supported,
since MX records are mandatory.
In SunOS you can choose either MX support or NIS support,
but not both.
This is fixed in Solaris,
and some
.i sendmail
support to allow this in SunOS should be forthcoming in a future release.
.sh 2 "Keyed Files"
.pp
Generalized keyed files is an idea taken directly from IDA sendmail
(albeit with a completely different implementation).
They can be useful on large sites.
.pp
Version 8 includes the following built-in map classes:
.ip dbm
Support for the ndbm(3) library.
.ip hash
Support for the ``Hash'' type from the new Berkeley db(3) library.
this library provides substantially better database support
than ndbm(3),
including in-memory caching,
arbitrarily long keys and values,
and better disk utilization.
.ip btree
Support for the ``B-Tree'' type from the new Berkeley db(3) library.
B-Trees provide better clustering than Hashed files
if you are fetching lots of records that have similar keys,
such as searching a dictionary for words beginning with ``detr''.
.ip nis
Support for NIS (a.k.a. YP) maps.
NIS+ is not supported in this version.
.ip host
Support for DNS lookups.
.ip dequote
A ``pseudo-map'' (that is, once that does not have any external data)
that allows a configuration file to break apart a quoted string
in the address.
This is necessary primarily for DECnet addresses,
which often have quoted addresses that need to be unwrapped on gateways.
.sh 2 "Multi-Word Classes & Macros in Classes"
.pp
Classes can now be multiple words.  For example,
.(b
CShofmann.CS.Berkeley.EDU
.)b
allows you to match the entire string ``hofmann.CS.Berkeley.EDU''
using the single construct ``$=S''.
.pp
Class definitions are now allowed to include macros \*- for example:
.(b
Cw$k
.)b
is legal.
.sh 2 "IDENT Protocol Support"
.pp
The IDENT protocol as defined in RFC 1413 [RFC1413] is supported.
However, many systems have a TCP/IP bug that renders this useless,
and the feature must be turned off.
Roughly, if one of these system receives a
.q "No route to host"
message (ICMP message ICMP_UNREACH_HOST) on
.i any
connection, all connections to that host are closed.
Some firewalls return this error if you try to connect
to the IDENT port,
so you can't receive email from these hosts on these systems.
It's possible that if the firewall used a more specific message
(such as ICMP_UNREACH_PROTOCOL, ICMP_UNREACH_PORT or ICMP_UNREACH_NET_PROHIB)
it would work, but this hasn't been verified.
.pp
IDENT protocol support cannot be used on
4.3BSD,
Apollo DomainOS,
Apple A/UX,
ConvexOS,
Data General DG/UX,
HP-UX,
Sequent Dynix,
or
Ultrix 4.x, x \(<= 3.
It seems to work on
4.4BSD,
IBM AIX 3.x,
OSF/1,
SGI IRIX,
Solaris,
SunOS,
and Ultrix 4.4.
.sh 2 "Separate Envelope/Header Processing
.pp
Since the From: line is passed in separately from the envelope
sender, these have both been made visible; the $g macro is set to
the envelope sender during processing of mailer argument vectors
and the header sender during processing of headers.
.pp
It is also possible to specify separate per-mailer envelope and
header processing.  The SenderRWSet and RecipientRWset arguments
for mailers can be specified as ``envelope/header'' to give different
rewritings for envelope versus header addresses.
.sh 2 "Owner-List Propagates to Envelope
.pp
When an alias has an associated owner-list name, that alias is used
to change the envelope sender address.  This will cause downstream
errors to be returned to that owner.
.pp
Some people find this confusing
because the envelope sender is what appears in the first
``From_'' line in UNIX messages
(that is, the line beginning ``From<space>''
instead of ``From:'';
the latter is the header from, which
.i does
indicate the sender of the message).
In previous versions,
.i sendmail
has tried to avoid changing the envelope sender
for back compatibility with UNIX convention;
at this point that back compatibility is creating too many problems,
and it is necessary to move forward into the 1980s.
.sh 2 "Command Line Flags"
.pp
The
.b \-B
flag has been added to pass in body type information.
.pp
The
.b \-p
flag has been added to pass in protocol information
that was previously passed in by defining the
.b $r
and
.b $s
macros.
.pp
The
.b \-X
flag has been added to allow logging of all protocol in and
out of sendmail for debugging.
You can set
.q "\-X filename"
and a complete transcript will be logged in that file.
This gets big fast: the option is only for debugging.
.pp
The
.b \-q
flag can limit limit a queue run to specific recipients,
senders, or queue ids using \-qRsubstring, \-qSsubstring, or
\-qIsubstring respectively.
.sh 2 "New Configuration Line Types
.pp
The `T' (Trusted users) configuration line has been deleted.  It
will still be accepted but will be ignored.
.pp
The `K' line has been added to declare database maps.
.pp
The `V' line has been added to declare the configuration version
level.
.pp
The `M' (mailer) line takes a D= field to specify execution
directory.
.sh 2 "New and Extended Options"
.pp
Several new options have been added, many to support new features,
others to allow tuning that was previously available only by
recompiling.  Briefly:
.nr ii 0.5i
.ip A
The alias file specification can now be a list of alias files.
Also, the configuration can specify a class of file.
For example, to search the NIS aliases, use
.q OAnis:mail.aliases .
.ip b
Insist on a minimum number of disk blocks.
.ip C
Delivery checkpoint interval.  Checkpoint the queue (to avoid
duplicate deliveries) every C addresses.
.ip E
Default error message.  This message (or the contents of the
indicated file) are prepended to error messages.
.ip G
Enable GECOS matching.  If you can't find a local user name
and this option is enabled, do a sequential scan of the passwd
file to match against full names.  Previously a compile option.
.ip h
Maximum hop count.  Previously this was compiled in.
.ip I
This option has been extended to allow setting of resolver parameters.
.ip j
Send errors in MIME-encapsulated format.
.ip J
Forward file path.  Where to search for .forward files \*- defaults
to $HOME/.forward.
.ip k
Connection cache size.  The total number of connections that will
be kept open at any time.
.ip K
Connection cache lifetime.  The amount of time any connection
will be permitted to sit idle.
.ip l
Enable Errors-To: header.  These headers violate RFC 1123;
this option is included to provide back compatibility with
old versions of sendmail.
.ip O
Incoming daemon options (e.g., use alternate SMTP port).
.ip p
Privacy options.  These can be used to make your SMTP server
less friendly.
.ip r
This option has been extended to allow finer grained control
over timeouts.
For example, you can set the timeout for SMTP commands individually.
.ip R
Don't prune route-addrs.  Normally, if version 8 sees an address
like "<@hostA,@hostB:user@hostC>, sendmail will try to strip off
as much as it can (up to user@hostC) as suggested by RFC 1123.
This option disables that behaviour.
.ip T
The
.q "Return To Sender"
timeout has been extended
to allow specification of a warning message interval,
typically something on the order of four hours.
If a message cannot be delivered in that interval,
a warning message is sent back to the sender
but the message continues to be tried.
.ip U
User database spec.  This is still experimental.
.ip V
Fallback ``MX'' host.  This can be thought of as an MX host
that applies to all addresses that has a very high preference
value (that is, use it only if everything else fails).
.ip w
If set, assume that if you are the best MX host for a host,
you should send directly to that host.  This is intended
for compatibility with UIUC sendmail, and may have some
use on firewalls.
.ip 7
Do not run eight bit clean.  Technically, you have to assert
this option to be RFC 821 compatible.
.sh 2 "New Mailer Definitions"
.ip L=
Set the allowable line length.  In V5, the L mailer flag implied
a line length limit of 990 characters; this is now settable to
an arbitrary value.
.ip F=a
Try to use ESMTP.  It will fall back to SMTP if the initial
EHLO packet is rejected.
.ip F=b
Ensure a blank line at the end of messages.  Useful on the
*file* mailer.
.ip F=c
Strip all comments from addresses; this should only be used as
a last resort when dealing with cranky mailers.
.ip F=g
Never use the null sender as the envelope sender, even when
running SMTP.  This violates RFC 1123.
.ip F=7
Strip all output to this mailer to 7 bits.
.ip F=L
Used to set the line limit to 990 bytes for SMTP compatibility.
It now does that only if the L= keyletter is not specified.
This flag is obsolete and should not be used.
.sh 2 "New or Changed Pre-Defined Macros"
.ip $k
UUCP node name from uname(2).
.ip $m
Domain part of our full hostname.
.ip $_
RFC 1413-provided sender address.
.ip $w
Previously was sometimes the full domain name, sometimes
just the first word.  Now guaranteed to be the first word
of the domain name (i.e., the host name).
.ip $j
Previously had to be defined \*- it is now predefined to be
the full domain name, if that can be determined.  That is,
it is equivalent to $w.$m.
.sh 2 "New and Changed Classes"
.ip $=k
Initialized to contain $k.
.ip $=w
Now includes
.q [1.2.3.4]
(where 1.2.3.4 is your IP address)
to allow the configuration file to recognize your own IP address.
.sh 2 "New Rewriting Tokens"
.pp
The
.b $&
construct has been adopted from IDA to defer macro evaluation.
Normally, macros in rulesets are bound when the rule is first parsed
during startup.
Some macros change during processing and are uninteresting during startup.
However, that macro can be referenced using
.q $&x
to defer the evaulation of
$x
until the rule is processed.
.pp
The tokens
.b $(
and
.b $)
have been added to allow specification of map rewriting.
.pp
Version 8 allows
.b $@
on the Left Hand Side of an `R' line to match
zero tokens.
This is intended to be used to match the null input.
.sh 2 "Bigger Defaults
.pp
Version 8 allows up to 100 rulesets instead of 30.  It is recommended
that rulesets 0\-9 be reserved for sendmail's dedicated use in future
releases.
.pp
The total number of MX records that can be used has been raised to
20.
.pp
The number of queued messages that can be handled at one time has
been raised from 600 to 1000.
.sh 2 "Different Default Tuning Parameters
.pp
Version 8 has changed the default parameters for tuning queue costs
to make the number of recipients more important than the size of
the message (for small messages).  This is reasonable if you are
connected with reasonably fast links.
.sh 2 "Auto-Quoting in Addresses
.pp
Previously, the ``Full Name <email address>'' syntax would generate
incorrect protocol output if ``Full Name'' had special characters
such as dot.  This version puts quotes around such names.
.sh 2 "Symbolic Names On Error Mailer
.pp
Several names have been built in to the $@ portion of the $#error
mailer.  For example:
.(b
$#error $@NOHOST $: Host unknown
.)b
Prints the indicated message
and sets the exit status of
.i sendmail
to
.sm EX_NOHOST .
.sh 2 "New Built-In Mailers"
.pp
Two new mailers, *file* and *include*, are included to define options
when mailing to a file or a :include: file respectively.  Previously
these were overloaded on the local mailer.
.sh 2 "SMTP VRFY Doesn't Expand
.pp
Previous versions of sendmail treated VRFY and EXPN the same.  In
this version, VRFY doesn't expand aliases or follow .forward files.
.pp
As an optimization, if you run with your default delivery mode
being queue-only, the RCPT command will also not chase aliases and
\&.forward files.
It will chase them when it processes the queue.
This speeds up RCPT processing.
.sh 2 "[IPC] Mailers Allow Multiple Hosts
.pp
When an address resolves to a mailer that has ``[IPC]'' as its
``Path'', the $@ part (host name) can be a colon-separated list of
hosts instead of a single hostname.  This asks sendmail to search
the list for the first entry that is available exactly as though
it were an MX record.  The intent is to route internal traffic
through internal networks without publishing an MX record to the
net.  MX expansion is still done on the individual items.
.sh 2 "Aliases Extended"
.pp
The implementation has been merged with maps.  Among other things,
this supports multiple alias files and NIS-based aliases.  For
example:
.(b
OA/etc/aliases,nis:mail.aliases
.)b
will search first the local database
.q /etc/aliases
followed by the NIS map

.sh 2 "Portability and Security Enhancements
.pp
A number of internal changes have been made to enhance portability.
.pp
Several fixes have been made to increase the paranoia factor.
.pp
In particular, the permissions required for .forward and :include:
files have been tightened up considerably.  V5 would pretty much
read any file it could get to as root, which exposed some security
holes.  V8 insists that all directories leading up to the .forward
or :include: file be searchable ("x" permission) by the controlling
user" (defined below), that the file itself be readable by the
controlling user, and that .forward files be owned by the user
who is being forwarded to or root.
.pp
The "controlling user" is the user on whose behalf the mail is
being delivered.  For example, if you mail to "user1" then the
controlling user for ~user1/.forward and any mailers invoked
by that .forward file, including :include: files.
.pp
Previously, anyone who had a home directory could create a .forward
could forward to a program.  Now, sendmail checks to make sure
that they have an "approved shell", that is, a shell listed in
the /etc/shells file.
.sh 2 "Miscellaneous Fixes and Enhancements"
.pp
A number of small bugs having to do with things like backslash-escaped
quotes inside of comments have been fixed.
.pp
The fixed size limit on header lines
(such as
.q To:
and
.q Cc: )
has been eliminated;
those buffers are dynamically allocated now.
.pp
Sendmail writes a /etc/sendmail.pid file with the current process id
and the current invocation flags.
.pp
Two people using the same program (e.g., submit) are considered
"different" so that duplicate elimination doesn't delete one of
them.  For example, two people forwarding their email to
|submit will be treated as two recipients.
.pp
The mailstats program prints mailer names and gets the location of
the sendmail.st file from /etc/sendmail.cf.
.pp
Many minor bugs have been fixed, such as handling of backslashes
inside of quotes.
.pp
A hook has been added to allow rewriting of local addresses after
aliasing.
.sh 1 "FUTURE WORK"
.pp
The previous section describes
.i sendmail
as of version 8.6.6.
There is still much to be done.
Some high points are described below.
This list is by no means exhaustive.
.sh 2 "Full MIME Support"
.pp
Currently
.i sendmail
only supports seven bit MIME messages.
Although it can pass eight bit MIME messages,
it cannot advertise that fact because the standards say
that the mail agent must be able to do 8- to 7-bit conversion
to have full 8-bit support.
This requires far more extensive modification of the message body
than is currently supported.
.pp
The best way to do this would be to support the general concept
of an external
``message filter''
that could do arbitrary modifications of the message.
This would allow MIME conversion as well as such things as
automatic encryption of messages sent over external links.
This is probably an extremely non-trivial change.
.sh 2 "Service Switch Abstraction"
.pp
Most modern systems include some concept of a
.q "service switch"
\*- for example, to look up host names you can try
DNS, NIS, NIS+, text tables, NetInfo,
or other services in some arbitrary order.
This is currently very clumsy in
.i sendmail ,
with only limited control of the services provided.
.sh 2 "More Control of Local Addresses"
.pp
Currently some addresses are declared as
.q local
and are handled specially \*-
for example, they may have .forward files,
may be translated into program calls or file deliveries,
and so forth.
These should be broken out into separate flags
to allow the local system administrator
to have more fine-grained control over operations.
.sh 2 "More Run-Time Configuration Options"
.pp
There are many options that are configured at compile time,
such as the method of file locking
and the use of the IDENT protocol
[RFC1413].
These should be transfered to run time
by adding new options.
.pp
Similarly, some options are currently overloaded,
that is, a single option controls more than one thing.
These should probably be broken out into separate options.
.pp
This implies that options will change from single characters
to words.
.sh 2 "More Configuration Control Over Errors"
.pp
Currently,
the configuration file can generate an error message during parsing.
However,
it cannot tweak other operations,
such as issuing a warning message to the system postmaster.
Similarly,
some errors should not be triggered if they are in aliases
during an alias file rebuild,
but should be triggered if that alias is actually used.
.sh 2 "Long Term Host State"
.pp
Currently,
.i sendmail
only remembers host status during a single queue run.
This should be converted to long term status
stored on disk
so it can be shared between instantiations of
.i sendmail .
Entries will have to be timestamped
so they can time out.
This will allow
.i sendmail
to implement exponential backoff on queue runs
on a per-host basis.
.sh 2 "Connection Control"
.pp
Modern networks have different types of connectivity
than the past.
In particular, the rising prominence of dialup IP
has created certain challenges for automated servers.
It is not uncommon to try to make a connection to a host
and have it fail, even though if you tried again it would succeed.
The connection management could be a bit cleverer
to try to adapt to such situations.
.sh 2 "Other Caching"
.pp
When you do an MX record lookup,
the name server automatically returns the IP addresses
of the associated MX servers.
This information is currently ignored,
and another query is done to get this information.
It should be cached to avoid excess name server traffic.
.sh 1 "REFERENCES"
.ip [Allman83a]
.q "Sendmail \*- An Internetwork Mail Router."
E. Allman.
In
.ul
Unix Programmers's Manual,
4.2 Berkeley Software Distribution,
volume 2C.
August 1983.
.ip [Allman83b]
.q "Mail Systems and Addressing in 4.2BSD."
E. Allman
In
.ul
UNICOM Conference Proceedings.
San Diego, California.
January 1983.
.ip [Allman&Amos85]
``Sendmail Revisited.''
E. Allman and M. Amos.
In
.ul
Usenix Summer 1985 Conference Proceedings.
Portland, Oregon.
June 1985.
.ip [IDA87]
.ul 3
Electronic Mail Addressing in Theory and Practice
with the IDA Sendmail Enhancement Kit
(or The Postmaster's Last Will and Testament).
Lennart Lo\*:vstrand.
Department of Computer and Information Science,
University of Linko\*:ping,
Sweden,
Report no. LiTH-IDA-Ex-8715.
May 1987.
.ip [RFC821]
.ul
Simple Mail Transport Protocol.
J. Postel.
August 1982.
.ip [RFC1123]
.ul
Requirements for Internet Hosts \*- Application and Support.
Internet Engineering Task Force,
R. Braden, Editor.
October 1989.
.ip [RFC1344]
.ul
Implications of MIME for Internet Mail Gateways.
N. Borenstein.
June 1992.
.ip [RFC1413]
.ul
Identification Protocol.
M. St. Johns.
February 1993.
.ip [RFC1425]
.ul
SMTP Service Extensions.
J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
February 1993.
.ip [RFC1426]
.ul
SMTP Service Extension for 8bit-MIMEtransport.
J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
February 1993.
.ip [RFC1427]
.ul
SMTP Service Extension for Message Size Declaration.
J. Klensin, N. Freed, and K. Moore.
February 1993.
.ip [RFC1521]
.ul 3
MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies.
N. Borenstein and N. Freed.
September 1993.