changes.me

早期freebsd实现

.\" 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.1 (Berkeley) 4/13/94
.\"
.\"	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