diff options
Diffstat (limited to 'RFC/rfc2033.txt')
| -rw-r--r-- | RFC/rfc2033.txt | 395 |
1 files changed, 0 insertions, 395 deletions
diff --git a/RFC/rfc2033.txt b/RFC/rfc2033.txt deleted file mode 100644 index a47433e8..00000000 --- a/RFC/rfc2033.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 2033 Carnegie Mellon -Category: Informational October 1996 - - - Local Mail Transfer Protocol - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -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 server 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 the LMTP protocol for transporting mail into - such systems. - - Although LMTP is an alternative protocol to ESMTP, it uses (with a - few changes) the syntax and semantics of ESMTP. This design permits - LMTP to utilize the extensions defined for ESMTP. LMTP should be - used only by specific prior arrangement and configuration, and it - MUST NOT be used on TCP port 25. - -Table of Contents - - 1. Abstract ................................................ 1 - 2. Conventions Used in this Document ....................... 2 - 3. Introduction and Overview ............................... 2 - 4. The LMTP protocol ....................................... 3 - 4.1. The LHLO, HELO and EHLO commands ........................ 4 - 4.2. The DATA command ........................................ 4 - 4.3. The BDAT command ........................................ 5 - 5. Implementation requirements ............................. 6 - 6. Acknowledgments ......................................... 6 - 7. References .............................................. 7 - 8. Security Considerations ................................. 7 - 9. Author's Address ........................................ 7 - - - - - -Myers Informational [Page 1] - -RFC 2033 LMTP October 1996 - - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -3. Introduction and Overview - - The design of the SMTP protocol effectively requires the server 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 server 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 client of the situation. The - server 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 server which does not manage a queue, instead relying on the client - to perform queue management. As an example, consider a hypothetical - host with a mail system designed as follows: - - - - 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 - - - -Myers Informational [Page 2] - -RFC 2033 LMTP October 1996 - - - 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 common practice of invoking a delivery agent with the envelope - address(es) as command-line arguments, then having the delivery agent - communicate status with an exit code has three serious problems: the - agent can only return one exit code to be applied to all recipients, - it is difficult to extend the interface to deal with ESMTP extensions - such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and - exits performed by system libraries due to temporary conditions - frequently get interpreted as permanent errors. - - The LMTP protocol causes the server to return, after the final "." of - the DATA command, one reply for each recipient. Therefore, if the - queue manager is configured to use LMTP instead of SMTP 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 LMTP protocol are drawn in the diagram above using - asterisks. - - Note that it is not beneficial to use the LMTP protocol 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. - -4. The LMTP protocol - - The LMTP protocol is identical to the SMTP protocol SMTP [SMTP] - [HOST-REQ] with its service extensions [ESMTP], except as modified by - this document. - - A "successful" RCPT command is defined as an RCPT command which - returns a Positive Completion reply code. - - A "Positive Completion reply code" is defined in Appendix E of STD - 10, RFC 821 [SMTP] as a reply code which "2" as the first digit. - - - -Myers Informational [Page 3] - -RFC 2033 LMTP October 1996 - - -4.1. The LHLO, HELO and EHLO commands - - The HELO and EHLO commands of ESMTP are replaced by the LHLO command. - This permits a misconfiguration where both parties are not using the - same protocol to be detected. - - The LHLO command has identical semantics to the EHLO command of ESMTP - [ESMTP]. - - The HELO and EHLO commands of ESMTP are not present in LMTP. A LMTP - server MUST NOT return a Postive Completion reply code to these - commands. The 500 reply code is recommended. - -4.2. The DATA command - - In the LMTP protocol, 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 server returns one reply - for each previously successful RCPT command in the mail transaction, - in the order that the RCPT commands were issued. Even if there were - multiple successful RCPT commands giving the same forward-path, there - must be one reply for each successful RCPT command. - - When one of these replies to the final "." is a Positive Completion - reply, the server is accepting responsibility for delivering or - relying the message to the corresponding recipient. It must take - this responsibility seriously, i.e., it MUST NOT lose the message for - frivolous reasons, e.g., because the host later crashes or because of - a predictable resource shortage. - - A multiline reply is still considered a single reply and corresponds - to a single RCPT command. - - EXAMPLE: - - S: 220 foo.edu LMTP server ready - C: LHLO foo.edu - S: 250-foo.edu - S: 250-PIPELINING - S: 250 SIZE - C: MAIL FROM:<chris@bar.com> - S: 250 OK - - - -Myers Informational [Page 4] - -RFC 2033 LMTP October 1996 - - - C: RCPT TO:<pat@foo.edu> - S: 250 OK - C: RCPT TO:<jones@foo.edu> - S: 550 No such user here - C: RCPT TO:<green@foo.edu> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - S: 452 <green@foo.edu> is temporarily over quota - C: QUIT - S: 221 foo.edu closing connection - - -NOTE: in the above example, the domain names of both the client and - server are identical. This is because in the example the client and - server are different subsystems of the same mail domain. - -4.3. The BDAT command - - If the server supports the ESMTP CHUNKING extension [BINARYMIME], a - BDAT command containing the LAST parameter returns one reply for each - previously successful RCPT command in the mail transaction, in the - order that the RCPT commands were issued. Even if there were - multiple successful RCPT commands giving the same forward-path, there - must be one reply for each successful RCPT command. If there were no - previously successful RCPT commands in the mail transaction, then the - BDAT LAST command returns zero replies. - - When one of these replies to the BDAT LAST command is a Positive - Completion reply, the server is accepting responsibility for - delivering or relaying the message to the corresponding recipient. - It must take this responsibility seriously, i.e., it MUST NOT lose - the message for frivolous reasons, e.g., because the host later - crashes or because of a predictable resource shortage. - - A multiline reply is still considered a single reply and corresponds - to a single RCPT command. - - The behavior of BDAT commands without the LAST parameter is not - changed; they still return exactly one reply. - - - - - - - -Myers Informational [Page 5] - -RFC 2033 LMTP October 1996 - - -5. Implementation requirements - - As LMTP is a different protocol than SMTP, it MUST NOT be used on the - TCP service port 25. - - A server implementation MUST implement the PIPELINING [PIPELINING] - and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. A - server implementation SHOULD implement the 8BITMIME [8BITMIME] - extension. - - Use of LMTP can aggravate the situation described in [DUP-MSGS]. To - avoid this synchronization problem, the following requirements are - made of implementations: - - A server implementation which is capable of quickly accepting - responsibility for delivering or relaying a message to multiple - recipients and which is capable of sending any necessary notification - messages SHOULD NOT implement the LMTP protocol. - - The LMTP protocol SHOULD NOT be used over wide area networks. - - The server 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 LMTP buffer, so the - reply may be quickly received by the client. - - The client 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 client MUST process the replies that - arrived and treat the rest as temporary failures. - -6. Acknowledgments - - This work is a refinement of the MULT extension, which was invented - by Jeff Michaud and was used in implementing gateways to the Mail-11 - mail system. - - Many thanks to Matt Thomas for assisting me in understanding the - semantics of the Mail-11 MULT extension. - - - - - - - - - - - -Myers Informational [Page 6] - -RFC 2033 LMTP October 1996 - - -7. References - - [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME - transport", RFC 1652, July 1994. - - [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission - of Large and Binary MIME Messages", RFC 1830, August 1995. - - [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for - Delivery Status Notifications", RFC 1894, January 1996. - - [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, - February 1988. - - [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for - Returning Enhanced Error Codes", RFC 2034, October 1996. - - [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., - "SMTP Service Extensions", RFC 1869, November 1995. - - [HOST-REQ] Braden, R., "Requirements for Internet hosts - application - and support", STD 3, RFC 1123 section 5, October 1989. - - [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for - Command Pipelining", RFC 1854, October 1995. - - [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - August 1982. - - - There are no known security issues with the issues in this memo. - -9. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - EMail: jgm+@cmu.edu - - - - - - - - - - - -Myers Informational [Page 7] - |