| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group J. Myers |
| 8 | Request for Comments: 2033 Carnegie Mellon |
| 9 | Category: Informational October 1996 |
| 10 | |
| 11 | |
| 12 | Local Mail Transfer Protocol |
| 13 | |
| 14 | Status 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 | |
| 20 | 1. 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 | |
| 39 | Table 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 | |
| 58 | Myers Informational [Page 1] |
| 59 | |
| 60 | RFC 2033 LMTP October 1996 |
| 61 | |
| 62 | |
| 63 | 2. Conventions Used in this Document |
| 64 | |
| 65 | In examples, "C:" and "S:" indicate lines sent by the client and |
| 66 | server respectively. |
| 67 | |
| 68 | 3. 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 | |
| 114 | Myers Informational [Page 2] |
| 115 | |
| 116 | RFC 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 | |
| 156 | 4. 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 | |
| 170 | Myers Informational [Page 3] |
| 171 | |
| 172 | RFC 2033 LMTP October 1996 |
| 173 | |
| 174 | |
| 175 | 4.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 | |
| 188 | 4.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 | |
| 226 | Myers Informational [Page 4] |
| 227 | |
| 228 | RFC 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 | |
| 248 | NOTE: 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 | |
| 252 | 4.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 | |
| 282 | Myers Informational [Page 5] |
| 283 | |
| 284 | RFC 2033 LMTP October 1996 |
| 285 | |
| 286 | |
| 287 | 5. 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 | |
| 319 | 6. 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 | |
| 338 | Myers Informational [Page 6] |
| 339 | |
| 340 | RFC 2033 LMTP October 1996 |
| 341 | |
| 342 | |
| 343 | 7. 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 | |
| 375 | 9. 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 | |
| 394 | Myers Informational [Page 7] |
| 395 | |