Speedy Closure

[Julian Onions <[e-mail]>]

To help speed up closure (and to push my preferred solution -
multiple-documents) I have drafted up a brief note below which covers
the folklore aspects - some of which were covered in (and copied from)
RFC-ZZZZ and some of which I've tossed in because I've come across
them in practice (additions are welcome BTW).

I propose we go forward with the 3 basic documents, for the following
reasons:

smtp-extensions - this is a good base document, gives a good general
 way to extend the protocol. There is nothing very contencious in it.

smtp-size-extension - there seems general agreement on this document.
 I expect some tinkering will occur later as experience is gained, but
 this is a good reason to have it as a separate document.

smtp-8bit-extension - this is a good start - I think more work will be
 required on this but it needs some implementation and deployment
 before anything much better can be done. Again a good reason for an
 obsoletable document.

smtp-folklore can be inclued if it is thought worthwhile.

Does that cover all aspects?
Julian.

----------------------------------------------------------------------






Network Working Group                                      Julian Onions
Request for Comments: DRAFT                           X-Tel Services Ltd
                                                                  Oct 92


                       SMTP Accumulated knowledge



1. Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are valid for a maximum of six months and may be
   updated, replaced, or obsoleted by other documents at any time.  (The
   file 1id-abstracts.txt on nic.ddn.mil describes the current status of
   each Internet Draft.) It is not appropriate to use Internet Drafts as
   reference material or to cite them other than as a "work in
   progress".

2. Abstract

   This memo describes a number of folklore issues associated with the
   SMTP protocol and attempts to tie down some loose ends. This document
   is an extension to RFC-821 not a replacement. This document is for
   information and does not set any standard. It indicates what is
   correct, what is pragmatic, and what is religous.

3. Introduction

   RFC-821 defines a protocol, SMTP, to transfer mail reliably and
   efficiently. It is largely independent of the transmission subsystem
   used.  It requires only a reliable ordered data stream, of at least
   7-bit units, that consists of "lines" and "characters".  It also
   makes some implied assumptions about end-to-end virtual circuit
   connections as the primary model for transporting and delivering
   mail.

   Since its initial publication many implementations of SMTP have been
   written and a number of ambiguities have arisen. Some of the
   associated folklore and some of the pragmatic decisions taken are
   recounted in this document.






Onions                   Expires March 30, 1993                 [Page 1]





RFC DRAFT              SMTP Accumulated Knowledge                 Oct 92


4. Issues concerning RSET

   RFC-821 is not specific about exactly what the RSET verb resets.
   This has apparently not been a problem in the past because of the
   simplicity of the protocol.  With the publication of extensions to
   the SMTP protocol with additional commands and state information,
   making a more precise definition desirable.  The definition provided
   should not constrain any existing RFC-821 implementation since it is
   consistent with both the current practice and the only two plausible
   interpretations.

   RSET is to be interpreted by SMTP servers as clearing state
   information present in a session.  In particular, it eliminates the
   effect of any prior FROM commands, any DATA, and any delivery
   addresses.  It resets the server's state to "not a mail transaction".
   This implies it is in the state after the HELO and before the MAIL
   verb.

   RSET has been interpreted by some SMTP servers as requiring that a
   new HELO command be sent after RSET is acknowledged.  Other servers
   assume that the previous HELO is not reset.  Servers SHOULD accept a
   HELO command subsequent to RSET without special comment, overriding a
   previous one if necessary.  Servers MUST NOT require a HELO command
   after a RSET.


   <>   Discussion: The description above summarizes the current
        situation with SMTP implementations based on a series of
        experiments.  No implementations have been identified that
        reject a second HELO, but it would not be surprising to find
        one.

5. Duplication of single state verbs.

   Whilst some of the SMTP state-inducing verbs may be repeated and
   arbitrary number of times (such as RCPT for multi-destination) other
   verbs (such as MAIL) may only be issued once per transaction. If a
   second occurrance of state-inducing verb is detected, a server MAY
   either accept it, overriding earlier information, or may reject it as
   an out-of-sequence command with a "503 bad sequence of commands"
   code.  A client sending multiple of these commands within a mail
   transaction MUST be prepared to send a RSET and start over, or to
   send QUIT and abandon the session, if 503 is received in this case.
   Clients SHOULD, if possible, behave in a way that avoids this
   situation.

   <>   Discussion: The issues above do not arise in the normal case of
        multiple successful message transmissions in the same session,



Onions                   Expires March 30, 1993                 [Page 2]





RFC DRAFT              SMTP Accumulated Knowledge                 Oct 92


        since each successful message completion (i.e., server receipt
        of DATA, the message, CR LF . CR LF, and then sending a positive
        completion reply) results in terminating a mail transaction.
        Clients SHOULD NOT send RSET after receipt of a 250 response
        after DATA and the message; servers MUST reset their states
        after sending that 250 response and MUST NOT require clients to
        send RSET before the next ???? FROM command

6. Behavior with unrecognized verbs.

   While it is not quite explicit, RFC-821 appears to expect that, if a
   verb is not recognized by the receiver, it will reject the command
   with a "permanent error", 5yz, code, presumably 500 (Syntax error).
   Similarly, it appears to specify that, if the sender receives such a
   code, it must either abandon the mail message (sending QUIT or RSET,
   presumably) or do something else involving the same or a different
   verb; it may not simply ignore the 5yz error code and pretend it was
   a 2yz (or 354) code.  This specification depends on that behavioral
   model.

   Consistent with RFC-821, we expect that existing SMTP servers will
   reply with a return code of 500 (Syntax error) when any unfamiliar
   verb is received.

   <>   Discussion: The material above should probably have made it into
        RFC-1123, but some of the issues--particularly the fact that
        anyone could ever have believed that anything else (such as
        simply ignoring 5xx codes) was permitted--have emerged only in
        the process of this investigation.  Nonetheless, this
        clarification is believed to be consistent with existing usage
        and implementations of SMTP.

7. Behaviour with eight-bit data

   RFC-821 together with RFC-822 is unambiguous in this respect. Unless
   an extension to RFC-821 is in force for the mail transaction, eight-
   bit data may not be sent. Period.

   <>   Discussion: This point just needs emphasising. It is clear in
        the original documents, but not spelt out.

8. Usage of SMTP extensions.

   The usage of SMTP extensions as defined in DRAFT-ROSE-EXTENSIONS-03
   should be as defined in the defining documents. However, as a
   pragmatic point, extensions that are defined should be acceptable in
   mixed-case.  Therefore, in the spirit of RFC-821 the extension XFOO
   should be acceptable as XFOO, xfoo and even XfOo.



Onions                   Expires March 30, 1993                 [Page 3]





RFC DRAFT              SMTP Accumulated Knowledge                 Oct 92


   <>   Discussion: There is no sense in making new verbs case
        sensitive. The number of new verbs is likely to be small and
        there is an extremely large potential space to use. Therefore
        there is little sense in reserving a lower case version of a
        verb to mean something different to an upper case version of a
        verb.

9. Rejection of SMTP connections due to DNS failure.

   There are a number of SMTP implementations that either do, or can be
   configured, to reject SMTP connections if the calling host is not
   registered in the DNS. This is seen by some as a breaking of the
   spirit of RFC-1123 and by others as a useful get-out-of-jail card.
   Regardless of whether this is a good idea or a bad one, the fact
   remains this is practiced by some sites. Implementors are therefore
   encouraged to use back up MX routing in the case of a connection that
   succeeds but no data is received before the connection is dropped.

   <>   Discussion: This topic has been debated a number of times on the
        Internet with both sides sticking to their views. There is no
        sense in continuing to try and standardise this point. What a
        site will do with any internet connection from any host
        eventually comes down to what the administrator at that site
        decides. If they don't want to talk to a given set of hosts,
        that may be their loss.

10. Illegal format RFC-822 messages

   Some implementations of RFC-821 check the message for adherence to
   RFC-822 minimum requirements as the message is received. These are
   that the message contains in the header a From field, a Date field
   and a recipient filed of some type. However, some user agents use
   RFC-821 as a submission protocol and assume that messages will be
   made legal RFC-822 as part of the submission process (as some MTA's
   already do this). Implementations MAY therefore allow strictly
   illegal RFC-822 messages as data and make them legal by addition of
   new headers, or MAY reject the message as illegal data.

   <>   Discussion: Some User Agents, particularly those on PC's find it
        difficult to determine an accurate time to provide a Date field,
        and therefore leave it out. It is harmless enough to insert such
        a field when acting as a submission channel, but inserting a
        Date mid way through a multi-hop delivery path is mis-leading
        and should be discouraged. However, in practice it is difficult
        to determine the two modes RFC-821 is used in so usually a
        blanket decision concerning all transfers has to be made.





Onions                   Expires March 30, 1993                 [Page 4]





RFC DRAFT              SMTP Accumulated Knowledge                 Oct 92


11. Acknowledgements

   This document represents a collection of the experiences and hard-won
   battle scars from a large community of people. All implementors of
   SMTP mail systems will have had some influence on this document.

12. Security Considerations

   Security considerations are not discussed in this memo.

13. Editor's  Address

   Julian Onions
   X-Tel Services Ltd
   University Park,
   Nottingham, England.



































Onions                   Expires March 30, 1993                 [Page 5]