rfcs/rfc2033.txt -rw-r--r-- 14.4 KiB
1
2
3
4
5
6
7Network Working Group J. Myers
8Request for Comments: 2033 Carnegie Mellon
9Category: Informational October 1996
10
11
12 Local Mail Transfer Protocol
13
14Status of this Memo
15
16 This memo provides information for the Internet community. This memo
17 does not specify an Internet standard of any kind. Distribution of
18 this memo is unlimited.
19
201. Abstract
21
22 SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a
23 mechanism for transferring mail reliably and efficiently. The design
24 of the SMTP protocol effectively requires the server to manage a mail
25 delivery queue.
26
27 In some limited circumstances, outside the area of mail exchange
28 between independent hosts on public networks, it is desirable to
29 implement a system where a mail receiver does not manage a queue.
30 This document describes the LMTP protocol for transporting mail into
31 such systems.
32
33 Although LMTP is an alternative protocol to ESMTP, it uses (with a
34 few changes) the syntax and semantics of ESMTP. This design permits
35 LMTP to utilize the extensions defined for ESMTP. LMTP should be
36 used only by specific prior arrangement and configuration, and it
37 MUST NOT be used on TCP port 25.
38
39Table of Contents
40
41 1. Abstract ................................................ 1
42 2. Conventions Used in this Document ....................... 2
43 3. Introduction and Overview ............................... 2
44 4. The LMTP protocol ....................................... 3
45 4.1. The LHLO, HELO and EHLO commands ........................ 4
46 4.2. The DATA command ........................................ 4
47 4.3. The BDAT command ........................................ 5
48 5. Implementation requirements ............................. 6
49 6. Acknowledgments ......................................... 6
50 7. References .............................................. 7
51 8. Security Considerations ................................. 7
52 9. Author's Address ........................................ 7
53
54
55
56
57
58Myers Informational [Page 1]
59
60RFC 2033 LMTP October 1996
61
62
632. Conventions Used in this Document
64
65 In examples, "C:" and "S:" indicate lines sent by the client and
66 server respectively.
67
683. Introduction and Overview
69
70 The design of the SMTP protocol effectively requires the server to
71 manage a mail delivery queue. This is because a single mail
72 transaction may specify multiple recipients and the final "." of the
73 DATA command may return only one reply code, to indicate the status
74 of the entire transaction. If, for example, a server is given a
75 transaction for two recipients, delivery to the first succeeds, and
76 delivery to the second encounters a temporary failure condition,
77 there is no mechanism to inform the client of the situation. The
78 server must queue the message and later attempt to deliver it to the
79 second recipient.
80
81 This queuing requirement is beneficial in the situation for which
82 SMTP was originally designed: store-and-forward relay of mail between
83 networked hosts. In some limited situations, it is desirable to have
84 a server which does not manage a queue, instead relying on the client
85 to perform queue management. As an example, consider a hypothetical
86 host with a mail system designed as follows:
87
88
89
90 TCP port 25 +-----------------+
91 ---------------------->| | #########
92 | Queue |<># Mail #
93 TCP port 25 | Manager | # Queue #
94 <----------------------| | #########
95 +-----------------+
96 Local * ^ Local * Local
97 IPC * | IPC * IPC
98 * | *
99 * | *
100 * | *
101 V | V
102 Non-SMTP +----------+ +----------+
103 Protocol | Gateway | | Local | #########
104 <==============>| Delivery | | Delivery |>># Mail #
105 | Agent | | Agent | # Spool #
106 +----------+ +----------+ #########
107
108
109 The host's mail system has three independent, communicating
110 subsystems. The first is a queue manager, which acts as a
111
112
113
114Myers Informational [Page 2]
115
116RFC 2033 LMTP October 1996
117
118
119 traditional SMTP agent, transferring messages to and from other hosts
120 over TCP and managing a mail queue in persistent storage. The other
121 two are agents which handle delivery for addresses in domains for
122 which the host takes responsibility. One agent performs gatewaying
123 to and from some other mail system. The other agent delivers the
124 message into a persistent mail spool.
125
126 It would be desirable to use SMTP over a local inter-process
127 communication channel to transfer messages from the queue manager to
128 the delivery agents. It would, however, significantly increase the
129 complexity of the delivery agents to require them to manage their own
130 mail queues.
131
132 The common practice of invoking a delivery agent with the envelope
133 address(es) as command-line arguments, then having the delivery agent
134 communicate status with an exit code has three serious problems: the
135 agent can only return one exit code to be applied to all recipients,
136 it is difficult to extend the interface to deal with ESMTP extensions
137 such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and
138 exits performed by system libraries due to temporary conditions
139 frequently get interpreted as permanent errors.
140
141 The LMTP protocol causes the server to return, after the final "." of
142 the DATA command, one reply for each recipient. Therefore, if the
143 queue manager is configured to use LMTP instead of SMTP when
144 transferring messages to the delivery agents, then the delivery
145 agents may attempt delivery to each recipient after the final "." and
146 individually report the status for each recipient. Connections which
147 should use the LMTP protocol are drawn in the diagram above using
148 asterisks.
149
150 Note that it is not beneficial to use the LMTP protocol when
151 transferring messages to the queue manager, either from the network
152 or from a delivery agent. The queue manager does implement a mail
153 queue, so it may store the message and take responsibility for later
154 delivering it.
155
1564. The LMTP protocol
157
158 The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
159 [HOST-REQ] with its service extensions [ESMTP], except as modified by
160 this document.
161
162 A "successful" RCPT command is defined as an RCPT command which
163 returns a Positive Completion reply code.
164
165 A "Positive Completion reply code" is defined in Appendix E of STD
166 10, RFC 821 [SMTP] as a reply code which "2" as the first digit.
167
168
169
170Myers Informational [Page 3]
171
172RFC 2033 LMTP October 1996
173
174
1754.1. The LHLO, HELO and EHLO commands
176
177 The HELO and EHLO commands of ESMTP are replaced by the LHLO command.
178 This permits a misconfiguration where both parties are not using the
179 same protocol to be detected.
180
181 The LHLO command has identical semantics to the EHLO command of ESMTP
182 [ESMTP].
183
184 The HELO and EHLO commands of ESMTP are not present in LMTP. A LMTP
185 server MUST NOT return a Postive Completion reply code to these
186 commands. The 500 reply code is recommended.
187
1884.2. The DATA command
189
190 In the LMTP protocol, there is one additional restriction placed on
191 the DATA command, and one change to how replies to the final "." are
192 sent.
193
194 The additional restriction is that when there have been no successful
195 RCPT commands in the mail transaction, the DATA command MUST fail
196 with a 503 reply code.
197
198 The change is that after the final ".", the server returns one reply
199 for each previously successful RCPT command in the mail transaction,
200 in the order that the RCPT commands were issued. Even if there were
201 multiple successful RCPT commands giving the same forward-path, there
202 must be one reply for each successful RCPT command.
203
204 When one of these replies to the final "." is a Positive Completion
205 reply, the server is accepting responsibility for delivering or
206 relying the message to the corresponding recipient. It must take
207 this responsibility seriously, i.e., it MUST NOT lose the message for
208 frivolous reasons, e.g., because the host later crashes or because of
209 a predictable resource shortage.
210
211 A multiline reply is still considered a single reply and corresponds
212 to a single RCPT command.
213
214 EXAMPLE:
215
216 S: 220 foo.edu LMTP server ready
217 C: LHLO foo.edu
218 S: 250-foo.edu
219 S: 250-PIPELINING
220 S: 250 SIZE
221 C: MAIL FROM:<chris@bar.com>
222 S: 250 OK
223
224
225
226Myers Informational [Page 4]
227
228RFC 2033 LMTP October 1996
229
230
231 C: RCPT TO:<pat@foo.edu>
232 S: 250 OK
233 C: RCPT TO:<jones@foo.edu>
234 S: 550 No such user here
235 C: RCPT TO:<green@foo.edu>
236 S: 250 OK
237 C: DATA
238 S: 354 Start mail input; end with <CRLF>.<CRLF>
239 C: Blah blah blah...
240 C: ...etc. etc. etc.
241 C: .
242 S: 250 OK
243 S: 452 <green@foo.edu> is temporarily over quota
244 C: QUIT
245 S: 221 foo.edu closing connection
246
247
248NOTE: in the above example, the domain names of both the client and
249 server are identical. This is because in the example the client and
250 server are different subsystems of the same mail domain.
251
2524.3. The BDAT command
253
254 If the server supports the ESMTP CHUNKING extension [BINARYMIME], a
255 BDAT command containing the LAST parameter returns one reply for each
256 previously successful RCPT command in the mail transaction, in the
257 order that the RCPT commands were issued. Even if there were
258 multiple successful RCPT commands giving the same forward-path, there
259 must be one reply for each successful RCPT command. If there were no
260 previously successful RCPT commands in the mail transaction, then the
261 BDAT LAST command returns zero replies.
262
263 When one of these replies to the BDAT LAST command is a Positive
264 Completion reply, the server is accepting responsibility for
265 delivering or relaying the message to the corresponding recipient.
266 It must take this responsibility seriously, i.e., it MUST NOT lose
267 the message for frivolous reasons, e.g., because the host later
268 crashes or because of a predictable resource shortage.
269
270 A multiline reply is still considered a single reply and corresponds
271 to a single RCPT command.
272
273 The behavior of BDAT commands without the LAST parameter is not
274 changed; they still return exactly one reply.
275
276
277
278
279
280
281
282Myers Informational [Page 5]
283
284RFC 2033 LMTP October 1996
285
286
2875. Implementation requirements
288
289 As LMTP is a different protocol than SMTP, it MUST NOT be used on the
290 TCP service port 25.
291
292 A server implementation MUST implement the PIPELINING [PIPELINING]
293 and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. A
294 server implementation SHOULD implement the 8BITMIME [8BITMIME]
295 extension.
296
297 Use of LMTP can aggravate the situation described in [DUP-MSGS]. To
298 avoid this synchronization problem, the following requirements are
299 made of implementations:
300
301 A server implementation which is capable of quickly accepting
302 responsibility for delivering or relaying a message to multiple
303 recipients and which is capable of sending any necessary notification
304 messages SHOULD NOT implement the LMTP protocol.
305
306 The LMTP protocol SHOULD NOT be used over wide area networks.
307
308 The server SHOULD send each reply as soon as possible. If it is
309 going to spend a nontrivial amount of time handling delivery for the
310 next recipient, it SHOULD flush any outgoing LMTP buffer, so the
311 reply may be quickly received by the client.
312
313 The client SHOULD process the replies as they come in, instead of
314 waiting for all of the replies to arrive before processing any of
315 them. If the connection closes after replies for some, but not all,
316 recipients have arrived, the client MUST process the replies that
317 arrived and treat the rest as temporary failures.
318
3196. Acknowledgments
320
321 This work is a refinement of the MULT extension, which was invented
322 by Jeff Michaud and was used in implementing gateways to the Mail-11
323 mail system.
324
325 Many thanks to Matt Thomas for assisting me in understanding the
326 semantics of the Mail-11 MULT extension.
327
328
329
330
331
332
333
334
335
336
337
338Myers Informational [Page 6]
339
340RFC 2033 LMTP October 1996
341
342
3437. References
344
345 [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME
346 transport", RFC 1652, July 1994.
347
348 [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission
349 of Large and Binary MIME Messages", RFC 1830, August 1995.
350
351 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
352 Delivery Status Notifications", RFC 1894, January 1996.
353
354 [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
355 February 1988.
356
357 [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for
358 Returning Enhanced Error Codes", RFC 2034, October 1996.
359
360 [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N.,
361 "SMTP Service Extensions", RFC 1869, November 1995.
362
363 [HOST-REQ] Braden, R., "Requirements for Internet hosts - application
364 and support", STD 3, RFC 1123 section 5, October 1989.
365
366 [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for
367 Command Pipelining", RFC 1854, October 1995.
368
369 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
370 August 1982.
371
372
373 There are no known security issues with the issues in this memo.
374
3759. Author's Address
376
377 John G. Myers
378 Carnegie-Mellon University
379 5000 Forbes Ave.
380 Pittsburgh PA, 15213-3890
381
382 EMail: jgm+@cmu.edu
383
384
385
386
387
388
389
390
391
392
393
394Myers Informational [Page 7]
395