		   SMTP Extensions for Smail 3.1.28
			      Version 9
		by Simon Leinen <simon@lia.di.epfl.ch>

			     DESCRIPTION
			     -----------
This file contains a patch to the Smail 3.1.28 sources that implements
RFCs 1425, 1426 and 1427 as well as the Internet Draft
`draft-ietf-smtpext-pipeline-02.txt'.  The following features are
implemented:

* The new EHLO command is recognized as mandated by [RFC1425].  The
  list of supported extensions in the reply includes HELP, EXPN and
  optionally 8BITMIME and SIZE.  If a message is received from a
  remote mailer that said EHLO, the Received: line that is added to
  the message will contain a sender protocol of "esmtp" rather than
  "stmp" (or "ebsmtp" rather than "bsmtp").

* NEW (June 15, 1994): The PIPELINING extension is provided by the
  server (this did not necessiatate any modifications of how the
  server works) and used by the client.  The PIPELINING extension
  reduces the number of turn-arounds in SMTP conversations between two
  mailers that both support it.  This can be a big win over slow IP
  networks.  The implementation is based on the Internet Draft
  `draft-ietf-smtpext-pipeline-02.txt' which is available from many
  archive sites that have IETF documents.

* BODY [RFC1426] and SIZE [RFC1427] clauses are recognized in MAIL
  FROM: SMTP commands on the receiver side.  Currently it doesn't
  matter whether the BODY type is 7BIT or 8BITMIME - Smail is always
  8-bit transparent.  If the value passed in a SIZE clause exceeds
  max_message_size, a "552 message too large" error reply is
  generated.

* The sender side tries to greet the receiving SMTP with an EHLO
  command.  If this fails, we send the standard HELO greeting.  If
  this also fails, we try RSET to clear up the remote mailer and then
  HELO.  If the EHLO is accepted, Smail parses the response to find
  out whether the receiver understands SIZE and BODY.  A maximum
  message size that is provided by the receiving SMTP is currently
  ignored, but the MAIL FROM: command is decorated with a SIZE
  declaration based on a guess of the spooled message's size.  The
  BODY clause is never issued.

			     INSTALLATION
			     ------------
Apply the enclosed patch to the top-level directory of the Smail
distribution (the one that contains the src/ subdirectory).  You will
need a fairly recent version of the "patch" program because the patch
is in the newer, more compact and more readable Unidiff format.

The server side of the extensions cannot be disabled in this version.
This means that EHLO is always accepted as an SMTP greeting, and the
SIZE parameter is accepted.

In order to enable the extensions, the following symbols have to be
added to the HAVE variable in the EDITME file:

	EHLO	to enable client-side support for EHLO, SIZE and
		PIPELINING
	ESMTP_8BITMIME
		to enable minimal server-side RFC 1426 support.
		Basically the BODY clause is accepted and ignored.

			       CAVEATS
			       -------
Here is a possible problem with ESMTP support: Apparently there are
some non-RFC821-conformant gateways running on legacy systems that
react to the EHLO query by closing down the connection rather than
giving a "500 command unrecognized" error.  Smail handles this
situation like a normal link failure, so a message sent via SMTP to
such a mailer will presumably get bounced after the retry period is
over.  If you care about interoperatibility with such weird systems,
you probably don't want to use the SMTP extensions, or write some code
for Smail to handle this situation more cleverly (see the TODO section
below).  Personally I think that this is such an extreme case of
protocol incompatibility that I haven't taken the time to support
these mailer daemons.

When an ESMTP-capable client Smail talks to a non-ESMTP-capable SMTP
server, there are two additional query/reply pairs for each SMTP
connection.  This is because Smail issues EHLO to find out whether the
recipient mailer handles ESMTP, gets an error message and then sends
an RSET before retrying with HELO.  If you have extremely slow or
unreliable SMTP connections, or if your network connections are
charged by the packet this may matter to you.

				 TODO
				 ----
Right now the SMTP extensions don't really give any new functionality,
except that max_message_size is *somewhat* enforced, but only for
cooperating (RFC 1427-savvy) client mailers.  The following
improvements to the code might be useful:

* a SIZE clause should be used to dynamically determine whether the
  incoming message will fit where it will be put next (one of the
  spool directories).  If this is the case, a temporary failure
  message should be sent to the client SMTP to avoid sending a lot of
  data in vain.

* Smail should be extended to handle 8-bit text messages in a more
  standard way.  Currently it is simply 8-bit transparent, which is
  seen as a feature by most users.  However, sending non-7-bit-ASCII
  characters to remote mailer daemons is a violation of RFC 821 and
  can lead to interoperability problems.  Even when communicating over
  8-bit clean SMTP networks, the "Just-Send-8" approach has the
  problem that it is not clear which character set has been used by
  the author [RFC1428].

  In principle, all these problems are solved by the MIME standard
  [RFC1341, RFC1342], which is rapidly gaining acceptance.  In a world
  where everybody uses MIME-capable mailers, there wouldn't be any
  eighth bits to be transported.  But as long as people still send
  8-bit messages, Smail could convert such messages to 7bit-MIME when
  they are transported over an SMTP network.  RFC1428 describes how
  this could be done.

* If the "link broken by EHLO" problem really does occur in the real
  world, it has to be handled by Smail's SMTP client side.  For
  instance, once an EHLO command causes a link to be broken, the
  receiving host should be noted in a "black list" by a mechanism
  similar to the retry file mechanism.  Hosts should be removed from
  the black list periodically, so that when they are upgraded to
  SMTP-conforming software, the new functionality will be used.  It
  would also be nice if the "retry" file could be extended by
  something like "ehlo/noehlo" keyword that would allow specific
  hosts/domains to be excluded from ESMTP trials.

* Some SMTP-based transports may want to use EHLO while others don't.
  In batch SMTP, for example, the EHLO command probably doesn't make
  much sense since the whole idea of "option negociation" doesn't fit
  into the "batch" model.  I don't know whether this should be
  hardwired in the SMTP transport or made a configurable parameter of
  transport entries.

			      ReFerenCes

1344  N. Borenstein, "Implications of MIME for Internet Mail Gateways",
      06/11/1992. (Pages=9) (Format=.txt, .ps)

1425  J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
      Service Extensions", 02/10/1993. (Pages=10) (Format=.txt)

1426  J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
      Service Extension for 8bit-MIMEtransport", 02/10/1993. (Pages=6)
      (Format=.txt)
      
1427  K. Moore, N. Freed, J. Klensin, "SMTP Service Extension for
      Message Size Declaration", 02/10/1993. (Pages=8) (Format=.txt)
      
1428  G. Vaudreuil, "Transition of Internet Mail from Just-Send-8 to
      8Bit-SMTP/MIME", 02/10/1993. (Pages=6) (Format=.txt)
      
1521  N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
      Extensions) Part One: Mechanisms for Specifying and Describing
      the Format of Internet Message Bodies", 09/23/1993. (Pages=81)
      (Format=.txt) (Obsoletes RFC1341)

1522  K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Two:
      Message Header Extensions for Non-ASCII Text",
      09/23/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1342)
