+----------------------------------------------------------------------+
|                                                                      |
|                  D I S C L A I M E R   N O T I C E                   |
|                                                                      |
|  This document and/or  portions of the material and  data furnished  |
|  herewith,  was developed under sponsorship of the U.S. Government.  |
|  Neither the U.S.  nor  the U.S.D.O.E.,  nor  the  Leland  Stanford  |
|  Junior University, nor their employees,  nor their respective con-  |
|  tractors, subcontractors, or their employees, makes  any warranty,  |
|  express or implied, or assumes any liability or responsibility for  |
|  accuracy,  completeness or  usefulness of any information, appara-  |
|  tus, product or process disclosed, or represents that its use will  |
|  not infringe privately-owned rights.  Mention of any product,  its  |
|  manufacturer, or suppliers shall not, nor is it intended to, imply  |
|  approval, disapproval, or fitness for any particular use. The U.S.  |
|  and  the University at all times  retain the right to use and dis-  |
|  seminate same for any purpose whatsoever.                           |
|                                                                      |
+----------------------------------------------------------------------+


                      SendMail 1.1/smtpd 1.4
                      ======================

                  Copyright (C) 1991, 1992, 1993

                                by

                          W.G.J. Langeveld

                 Stanford Linear Accelerrator Center

                        All Rights Reserved


        This is a very bare-bones mailer and server based on SMTP.
Basically, there are two programs, smtpd and sendmail. Neither are
ports of anything, they were written from scratch based on the RFC 821
and 822.

8 November 1991:
================

	Changed the read and write routines to strip off the 8th bit in
order to try to fix Mike Sinz's problem.

	Willy Langeveld.

14 November 1991:
=================

	Changed the handling of cr/lf pairs to check for cases where there
isn't a cr. Maybe *this* will fix Mike Sinz's problem...

	Willy Langeveld.

17 November 1991:
=================

	Changed the entire way lines are read from the socket. This hopefully
fixes the last detail of Mike Sinz's problem. D*mn Ultrix anyway... 8^)

	Willy Langeveld.

21 November 1991:
=================

	Mike Sinz's problem is really fixed now, smtpd now accepts stuff
from Ultrix (which doesn't use cr/lf at the end of their lines, and doesn't
end messages by "dot cr lf" but only "dot". Talk about standard... Anyway,
it now sends an ARexx message of the form   MAIL nnnnn  where nnnnn is the
five-digit number of the message it just posted.
	Another change is that smtpd is now really reentrant (uses no stdio
anywhere, now has a reentrant sprintf based on RawDoFmt). It also became
smaller for that reason. Both executables now have version strings.
	Sendmail now checks for an env variable called "smtp_router". If
it exists, it will use that router for all mail. This can still be overridden
using the -h switch.

	Willy Langeveld.

29 June 1992:
=============

	Added comments and rearranged the code here and there. Found a
small bug in smtpd. Took out some unneeded code. Consolidated the various
common functions between lpr and sendmail/smtpd somewhat.

	Willy Langeveld.

1 December 1992:
================

	Modified sendmail and smtpd to use ReadArgs(). Reworked smtpd so that
it is now started by inetd. Reduced the size of smtpd considerably by
eliminating startup code and using some 2.0 calls where old calls used to
be used. Added a doc file "sendmail.doc", removed docs from this file.

9 February 1993:
================

	Fixed a bug: if the destination directory ended in either a :
or a /, another / would still be added. The code did check for this, but
did it wrong. Guess I should use AddPart sometime.

11 May 1993:
============

	Fixed a bug: if there were two or more incoming messages during the
same transaction, the message number would not be updated inbetween and 
only the last message would be kept. This must have been in there forever.

	Willy Langeveld.

