As per Relevance of the word delivery, we have this rfc below:
Network Working Group J.
Request for Comments: 2033 Carnegie
Category: Informational October 1996
Local Mail Transfer
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide
mechanism for transferring mail reliably and efficiently. The
of the SMTP protocol effectively requires the server to manage a
delivery queue
In some limited circumstances, outside the area of mail
between independent hosts on public networks, it is desirable
implement a system where a mail receiver does not manage a queue
This document describes the LMTP protocol for transporting mail
such systems
Although LMTP is an alternative protocol to ESMTP, it uses (with
few changes) the syntax and semantics of ESMTP. This design
LMTP to utilize the extensions defined for ESMTP. LMTP should
used only by specific prior arrangement and configuration, and
MUST NOT be used on TCP port 25.
Table of
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
In examples, "C:" and "S:" indicate lines sent by the client
server respectively
3. Introduction and
The design of the SMTP protocol effectively requires the server
manage a mail delivery queue. This is because a single
transaction may specify multiple recipients and the final "." of
DATA command may return only one reply code, to indicate the
of the entire transaction. If, for example, a server is given
transaction for two recipients, delivery to the first succeeds,
delivery to the second encounters a temporary failure condition
there is no mechanism to inform the client of the situation.
server must queue the message and later attempt to deliver it to
second recipient
This queuing requirement is beneficial in the situation for
SMTP was originally designed: store-and-forward relay of mail
networked hosts. In some limited situations, it is desirable to
a server which does not manage a queue, instead relying on the
to perform queue management. As an example, consider a
host with a mail system designed as follows
TCP port 25 +-----------------+
---------------------->| | #########
| Queue |<># Mail #
TCP port 25 | Manager | # Queue #
<----------------------| | #########
+-----------------+
Local * ^ Local *
IPC * | IPC *
* | *
* | *
* | *
V |
Non-SMTP +----------+ +----------+
Protocol | Gateway | | Local | #########
<==============>| Delivery | | Delivery |>># Mail #
| Agent | | Agent | # Spool #
+----------+ +----------+ #########
The host's mail system has three independent,
subsystems. The first is a queue manager, which acts as
Myers Informational [Page 2]
RFC 2033 LMTP October 1996
traditional SMTP agent, transferring messages to and from other
over TCP and managing a mail queue in persistent storage. The
two are agents which handle delivery for addresses in domains
which the host takes responsibility. One agent performs
to and from some other mail system. The other agent delivers
message into a persistent mail spool
It would be desirable to use SMTP over a local inter-
communication channel to transfer messages from the queue manager
the delivery agents. It would, however, significantly increase
complexity of the delivery agents to require them to manage their
mail queues
The common practice of invoking a delivery agent with the
address(es) as command-line arguments, then having the delivery
communicate status with an exit code has three serious problems:
agent can only return one exit code to be applied to all recipients
it is difficult to extend the interface to deal with ESMTP
such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES],
exits performed by system libraries due to temporary
frequently get interpreted as permanent errors
The LMTP protocol causes the server to return, after the final "."
the DATA command, one reply for each recipient. Therefore, if
queue manager is configured to use LMTP instead of SMTP
transferring messages to the delivery agents, then the
agents may attempt delivery to each recipient after the final "."
individually report the status for each recipient. Connections
should use the LMTP protocol are drawn in the diagram above
asterisks
Note that it is not beneficial to use the LMTP protocol
transferring messages to the queue manager, either from the
or from a delivery agent. The queue manager does implement a
queue, so it may store the message and take responsibility for
delivering it
4. The LMTP
The LMTP protocol is identical to the SMTP protocol SMTP [SMTP
[HOST-REQ] with its service extensions [ESMTP], except as modified
this document
A "successful" RCPT command is defined as an RCPT command
returns a Positive Completion reply code
A "Positive Completion reply code" is defined in Appendix E of
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
The HELO and EHLO commands of ESMTP are replaced by the LHLO command
This permits a misconfiguration where both parties are not using
same protocol to be detected
The LHLO command has identical semantics to the EHLO command of
[ESMTP].
The HELO and EHLO commands of ESMTP are not present in LMTP. A
server MUST NOT return a Postive Completion reply code to
commands. The 500 reply code is recommended
4.2. The DATA
In the LMTP protocol, there is one additional restriction placed
the DATA command, and one change to how replies to the final "."
sent
The additional restriction is that when there have been no
RCPT commands in the mail transaction, the DATA command MUST
with a 503 reply code
The change is that after the final ".", the server returns one
for each previously successful RCPT command in the mail transaction
in the order that the RCPT commands were issued. Even if there
multiple successful RCPT commands giving the same forward-path,
must be one reply for each successful RCPT command
When one of these replies to the final "." is a Positive
reply, the server is accepting responsibility for delivering
relying the message to the corresponding recipient. It must
this responsibility seriously, i.e., it MUST NOT lose the message
frivolous reasons, e.g., because the host later crashes or because
a predictable resource shortage
A multiline reply is still considered a single reply and
to a single RCPT command
EXAMPLE
S: 220 foo.edu LMTP server
C: LHLO foo.
S: 250-foo.
S: 250-
S: 250
C: MAIL FROM:
S: 250
Myers Informational [Page 4]
RFC 2033 LMTP October 1996
C: RCPT TO:
S: 250
C: RCPT TO:
S: 550 No such user
C: RCPT TO:
S: 250
C:
S: 354 Start mail input; end with .
C: Blah blah blah...
C: ...etc. etc. etc
C: .
S: 250
S: 452 is temporarily over
C:
S: 221 foo.edu closing
NOTE: in the above example, the domain names of both the client
server are identical. This is because in the example the client
server are different subsystems of the same mail domain
4.3. The BDAT
If the server supports the ESMTP CHUNKING extension [BINARYMIME],
BDAT command containing the LAST parameter returns one reply for
previously successful RCPT command in the mail transaction, in
order that the RCPT commands were issued. Even if there
multiple successful RCPT commands giving the same forward-path,
must be one reply for each successful RCPT command. If there were
previously successful RCPT commands in the mail transaction, then
BDAT LAST command returns zero replies
When one of these replies to the BDAT LAST command is a
Completion reply, the server is accepting responsibility
delivering or relaying the message to the corresponding recipient
It must take this responsibility seriously, i.e., it MUST NOT
the message for frivolous reasons, e.g., because the host
crashes or because of a predictable resource shortage
A multiline reply is still considered a single reply and
to a single RCPT command
The behavior of BDAT commands without the LAST parameter is
changed; they still return exactly one reply
Myers Informational [Page 5]
RFC 2033 LMTP October 1996
5. Implementation
As LMTP is a different protocol than SMTP, it MUST NOT be used on
TCP service port 25.
A server implementation MUST implement the PIPELINING [PIPELINING
and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.
server implementation SHOULD implement the 8BITMIME [8BITMIME
extension
Use of LMTP can aggravate the situation described in [DUP-MSGS].
avoid this synchronization problem, the following requirements
made of implementations
A server implementation which is capable of quickly
responsibility for delivering or relaying a message to
recipients and which is capable of sending any necessary
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
going to spend a nontrivial amount of time handling delivery for
next recipient, it SHOULD flush any outgoing LMTP buffer, so
reply may be quickly received by the client
The client SHOULD process the replies as they come in, instead
waiting for all of the replies to arrive before processing any
them. If the connection closes after replies for some, but not all
recipients have arrived, the client MUST process the replies
arrived and treat the rest as temporary failures
6.
This work is a refinement of the MULT extension, which was
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
semantics of the Mail-11 MULT extension
Myers Informational [Page 6]
RFC 2033 LMTP October 1996
7.
[8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-
transport", RFC 1652, July 1994.
[BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for
of Large and Binary MIME Messages", RFC 1830, August 1995.
[DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format
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
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 -
and support", STD 3, RFC 1123 section 5, October 1989.
[PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension
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
John G.
Carnegie-Mellon
5000 Forbes Ave
Pittsburgh PA, 15213-3890
EMail: jgm+@cmu.
Myers Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
