Network Working Group Julian Onions INTERNET 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 and its extensions, 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 religious. 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] INTERNET 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 occurrence 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] INTERNET 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] INTERNET 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 field 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. What is really required is a submission protocol tailored to this sort of behaviour. Onions Expires March 30, 1993 [Page 4] INTERNET 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. In particular there are a number of points taken from the work done in the smtp extensions working group. This document is a summary of some of the discussions, and other experiences. Some of this text is taken from an earlier draft of the SMTP working group 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]