1000 lines
33 KiB
Plaintext
1000 lines
33 KiB
Plaintext
.\" $NetBSD: changes.me,v 1.2 1998/01/09 08:10:24 perry Exp $
|
|
.\"
|
|
.\" 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.
|