Network Working Group J. Myers Internet Draft Carnegie Mellon Document: draft-myers-smtp-mult-00.txt October 1995 The SMTP MULT extension command 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 draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the IESG for consideration as a Limited Use Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before April 1996. Distribution of this draft is unlimited. J. Myers [Page i] Internet DRAFT MULT October 5, 1995 1. Abstract SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the receiver-SMTP to manage a mail delivery queue. In some limited circumstances, outside the area of mail exchange between independent hosts on public networks, it is desirable to implement a system where a mail receiver does not manage a queue. This document describes an extension command which modifies the SMTP protocol to accommodate this situation. This extension is one which should be used only by specific prior arrangement and configuration. Its use by a sender-SMTP should not be triggered by availability, therefore the extension is not given an ESMTP EHLO keyword. 2. Conventions Used in this Document In examples, "S:" and "R:" indicate lines sent by the sender-SMTP and receiver-SMTP respectively. 3. Introduction and Overview The design of the SMTP protocol effectively requires the receiver- SMTP to manage a mail delivery queue. This is because a single mail transaction may specify multiple recipients and the final "." of the DATA command may return only one reply code, to indicate the status of the entire transaction. If, for example, a receiver-SMTP is given a transaction for two recipients, delivery to the first succeeds, and delivery to the second encounters a temporary failure condition, there is no mechanism to inform the sender-SMTP of the situation. The receiver-SMTP must queue the message and later attempt to deliver it to the second recipient. This queuing requirement is beneficial in the situation for which SMTP was originally designed: store-and-forward relay of mail between networked hosts. In some limited situations, it is desirable to have a receiver-SMTP which does not manage a queue, instead relying on the sender-SMTP to perform queue management. As an example, consider a hypothetical host with a mail system designed as follows: J. Myers [Page 2] Internet DRAFT MULT October 5, 1995 TCP port 25 +-----------------+ ---------------------->| | ######### | Queue |<># Mail # TCP port 25 | Manager | # Queue # <----------------------| | ######### +-----------------+ Local * ^ Local * Local IPC * | IPC * IPC * | * * | * * | * V | V Non-SMTP +----------+ +----------+ Protocol | Gateway | | Local | ######### <==============>| Delivery | | Delivery |>># Mail # | Agent | | Agent | # Spool # +----------+ +----------+ ######### The host's mail system has three independent, communicating subsystems. The first is a queue manager, which acts as a traditional SMTP agent, transferring messages to and from other hosts over TCP and managing a mail queue in persistent storage. The other two are agents which handle delivery for addresses in domains for which the host takes responsibility. One agent performs gatewaying to and from some other mail system. The other agent delivers the message into a persistent mail spool. It would be desirable to use SMTP over a local inter-process communication channel to transfer messages from the queue manager to the delivery agents. It would, however, significantly increase the complexity of the delivery agents to require them to manage their own mail queues. The MULT extension permits the receiver-SMTP to return, after the final "." of the DATA command, one reply for each recipient. Therefore, if the queue manager is configured to use SMTP with the MULT extension when transferring messages to the delivery agents, then the delivery agents may attempt delivery to each recipient after the final "." and individually report the status for each recipient. Connections which should use the MULT extension are drawn in the diagram above using asterisks. Note that it is not beneficial to use the MULT extension when transferring messages to the queue manager, either from the network or from a delivery agent. The queue manager does implement a mail queue, so it may store the message and take responsibility for later delivering it. J. Myers [Page 3] Internet DRAFT MULT October 5, 1995 4. The MULT command As the MULT extension changes the behavior of existing SMTP commands, it is first necessary for the sender-SMTP to enable its use. To do this, the sender-SMTP issues the MULT command, with no arguments. If the receiver returns a positive completion reply (which it must do with a 250 reply code), then for the rest of the session the MULT extension is enabled and the behavior of the receiver-SMTP is modified as described later in this document. The MULT extension is never again disabled in the session, not by RSET or any other command. The MULT command may be issued at any time the sender-SMTP is permitted to issue the MAIL command. 5. Effect on the DATA command When the MULT extension is enabled, there is one additional restriction placed on the DATA command, and one change to how replies to the final "." are sent. The additional restriction is that when there have been no successful RCPT commands in the mail transaction, the DATA command MUST fail with a 503 reply code. The change is that after the final ".", the SMTP-receiver returns one reply, in order, for each previously successful RCPT command in the mail transaction. EXAMPLE: R: 220 foo.edu SMTP server ready S: HELO foo.edu R: 250 foo.edu S: MULT R: 250 MULT extension now enabled S: MAIL FROM: R: 250 OK S: RCPT TO: R: 250 OK S: RCPT TO: R: 550 No such user here S: RCPT TO: R: 250 OK S: DATA R: 354 Start mail input; end with . S: Blah blah blah... J. Myers [Page 4] Internet DRAFT MULT October 5, 1995 S: ...etc. etc. etc. S: . R: 250 OK R: 452 is temporarily over quota S: QUIT R: 221 foo.edu closing connection 6. Effect on the BDAT command When the MULT extension is enabled and the receiver-SMTP supports the ESMTP CHUNKING extension [BINARYMIME], a BDAT command containing the LAST parameter returns one reply, in order, for each previously successful RCPT command in the mail transaction. If there were no previously successful RCPT commands in the mail transaction, then the BDAT LAST command returns zero replies. The behavior of BDAT commands without the LAST parameter is not changed; they still return exactly one reply. X. [[placeholder]] [[Keith Moore thinks mail11v3 may be broken: if the same address is presented twice, it may only return status for the first one. If that is the case, we may have to either document the problem here or pick a name other than MULT.]] 7. Duplicate messages Use of the MULT extension can aggravate the situation described in [DUP-MSGS]. To avoid this synchronization problem, the following steps should be taken. The MULT extension should not be used over wide area networks. The receiver-SMTP should send each reply as soon as possible. If it is going to spend a nontrivial amount of time handling delivery for the next recipient, it should flush any outgoing SMTP buffer, so the reply may be quickly received by the sender-SMTP. The sender-SMTP should process the replies as they come in, instead of waiting for all of the replies to arrive before processing any of them. If the connection closes after replies for some, but not all, recipients have arrived, the sender-SMTP MUST process the replies that arrived and treat the rest as temporary failures. J. Myers [Page 5] Internet DRAFT MULT October 5, 1995 8. Fallback strategies If a receiver-SMTP which does not implement a mail queue receives a mail transaction when the MULT extension has not been enabled, it has one of two choices: 1. Cause the MAIL command to fail with a 500 or some other Permanent Negative Completion reply. This will hopefully cause the misconfiguration of the sender-SMTP obvious. 2. Accept the MAIL command and at most one RCPT command. After returning one success reply to an RCPT command, further RCPT commands in the mail transaction fail with a 450 or some other Transient Negative Completion reply. This will permit delivery to one recipient per transaction. Remaining recipients will be hopefully queued for delivery during subsequent delivery attempts. 9. Acknowledgments The MULT extension was invented by unknown persons implementing gateways to the Mail-11 mail system. 10. References [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995 [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988 [ESMTP] Klensin, J. et. al., "SMTP Service Extensions", RFC 1651, July 1994 [HOST-REQ] Braden, R., "Requirements for Internet hosts - application and support", RFC 1123 section 5, October 1989. [SMTP] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. 11. Security Considerations There are no known security issues with the issues in this memo. 12. Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. J. Myers [Page 6] Internet DRAFT MULT October 5, 1995 Pittsburgh PA, 15213-3890 EMail: jgm+@cmu.edu J. Myers [Page 7] Internet DRAFT MULT October 5, 1995 Table of Contents Status of this Memo ............................................... i 1. Abstract ...................................................... 2 2. Conventions Used in this Document ............................. 2 3. Introduction and Overview ..................................... 2 4. The MULT command .............................................. 4 5. Effect on the DATA command .................................... 4 6. Effect on the BDAT command .................................... 5 X. [[placeholder]] ............................................... 5 7. Duplicate messages ............................................ 5 8. Fallback strategies ........................................... 6 9. Acknowledgments ............................................... 6 10. References ................................................... 6 11. Security Considerations ....................................... 6 12. Author's Address .............................................. 6 J. Myers [Page ii]