| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group J. De Winter |
| 8 | Request for Comments: 1985 Wildbear Consulting, Inc. |
| 9 | Category: Standards Track August 1996 |
| 10 | |
| 11 | |
| 12 | SMTP Service Extension |
| 13 | for Remote Message Queue Starting |
| 14 | |
| 15 | Status of this Memo |
| 16 | |
| 17 | This document specifies an Internet standards track protocol for the |
| 18 | Internet community, and requests discussion and suggestions for |
| 19 | improvements. Please refer to the current edition of the "Internet |
| 20 | Official Protocol Standards" (STD 1) for the standardization state |
| 21 | and status of this protocol. Distribution of this memo is unlimited. |
| 22 | |
| 23 | Abstract |
| 24 | |
| 25 | This memo defines an extension to the SMTP service whereby an SMTP |
| 26 | client and server may interact to give the server an opportunity to |
| 27 | start the processing of its queues for messages to go to a given |
| 28 | host. This extension is meant to be used in startup conditions as |
| 29 | well as for mail nodes that have transient connections to their |
| 30 | service providers. |
| 31 | |
| 32 | 1. Introduction |
| 33 | |
| 34 | The TURN command was a valid attempt to address the problem of having |
| 35 | to start the processing for the mail queue on a remote machine. |
| 36 | However, the TURN command presents a large security loophole. As |
| 37 | there is no verification of the remote host name, the TURN command |
| 38 | could be used by a rogue system to download the mail for a site other |
| 39 | than itself. |
| 40 | |
| 41 | Therefore, this memo introduces the ETRN command. This command uses |
| 42 | the mechanism defined in [4] to define extensions to the SMTP service |
| 43 | whereby a client ("sender-SMTP") may request that the server |
| 44 | ("receiver-SMTP") start the processing of its mail queues for |
| 45 | messages that are waiting at the server for the client machine. If |
| 46 | any messages are at the server for the client, then the server should |
| 47 | create a new SMTP session and send the messages at that time. |
| 48 | |
| 49 | |
| 50 | |
| 51 | |
| 52 | |
| 53 | |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | De Winter Standards Track [Page 1] |
| 59 | |
| 60 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 61 | |
| 62 | |
| 63 | 2. Framework for the ETRN Extension |
| 64 | |
| 65 | The following service extension is therefore defined: |
| 66 | |
| 67 | (1) the name of the SMTP service extension is "Remote Queue |
| 68 | Processing Declaration"; |
| 69 | |
| 70 | (2) the EHLO keyword value associated with this extension is "ETRN", |
| 71 | with no associated parameters; |
| 72 | |
| 73 | (3) one additional verb, ETRN, with a single parameter that |
| 74 | specifies the name of the client(s) to start processing for; |
| 75 | |
| 76 | (4) no additional SMTP verbs are defined by this extension. |
| 77 | |
| 78 | The remainder of this memo specifies how support for the extension |
| 79 | affects the behavior of an SMTP client and server. |
| 80 | |
| 81 | 3. The Remote Queue Processing Declaration service extension |
| 82 | |
| 83 | To save money, many small companies want to only maintain transient |
| 84 | connections to their service providers. In addition, there are some |
| 85 | situations where the client sites depend on their mail arriving |
| 86 | quickly, so forcing the queues on the server belonging to their |
| 87 | service provider may be more desirable than waiting for the retry |
| 88 | timeout to occur. |
| 89 | |
| 90 | Both of these situations could currently be fixed using the TURN |
| 91 | command defined in [1], if it were not for a large security loophole |
| 92 | in the TURN command. As it stands, the TURN command will reverse the |
| 93 | direction of the SMTP connection and assume that the remote host is |
| 94 | being honest about what its name is. The security loophole is that |
| 95 | there is no documented stipulation for checking the authenticity of |
| 96 | the remote host name, as given in the HELO or EHLO command. As such, |
| 97 | most SMTP and ESMTP implementations do not implement the TURN command |
| 98 | to avoid this security loophole. |
| 99 | |
| 100 | This has been addressed in the design of the ETRN command. This |
| 101 | extended turn command was written with the points in the first |
| 102 | paragraph in mind, yet paying attention to the problems that |
| 103 | currently exist with the TURN command. The security loophole is |
| 104 | avoided by asking the server to start a new connection aimed at the |
| 105 | specified client. |
| 106 | |
| 107 | In this manner, the server has a lot more certainty that it is |
| 108 | talking to the correct SMTP client. This mechanism can just be seen |
| 109 | as a more immediate version of the retry queues that appear in most |
| 110 | SMTP implementations. In addition, as this command will take a |
| 111 | |
| 112 | |
| 113 | |
| 114 | De Winter Standards Track [Page 2] |
| 115 | |
| 116 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 117 | |
| 118 | |
| 119 | single parameter, the name of the remote host(s) to start the queues |
| 120 | for, the server can decide whether it wishes to respect the request |
| 121 | or deny it for any local administrative reasons. |
| 122 | |
| 123 | 4. Definitions |
| 124 | |
| 125 | Remote queue processing means that using an SMTP or ESMTP connection, |
| 126 | the client may request that the server start to process parts of its |
| 127 | messaging queue. This processing is performed using the existing |
| 128 | SMTP infrastructure and will occur at some point after the processing |
| 129 | is initiated. |
| 130 | |
| 131 | The server host is the node that is responding to the ETRN |
| 132 | command. |
| 133 | |
| 134 | The client host is the node that is initiating the ETRN command. |
| 135 | |
| 136 | The remote host name is defined to be a plain-text field that |
| 137 | specifies a name for the remote host(s). This remote host name may |
| 138 | also include an alias for the specified remote host or special |
| 139 | commands to identify other types of queues. |
| 140 | |
| 141 | 5. The extended ETRN command |
| 142 | |
| 143 | The extended ETRN command is issued by the client host when it wishes |
| 144 | to start the SMTP queue processing of a given server host. The |
| 145 | syntax of this command is as follows: |
| 146 | |
| 147 | ETRN [<option character>]<node name><CR><LF> |
| 148 | |
| 149 | This command may be issued at any time once a session is established, |
| 150 | as long as there is not a transaction occuring. Thus, this command |
| 151 | is illegal between a MAIL FROM: command and the end of the DATA |
| 152 | commands and responses. |
| 153 | |
| 154 | The specified node name must be a fully qualified domain name for the |
| 155 | node, which may refer to a CNAME or MX pointer in the DNS. If an |
| 156 | alias is used for the node, multiple ETRN commands may be needed to |
| 157 | start the processing for the node as it may be listed at the remote |
| 158 | site under multiple names. This can also be addressed using the |
| 159 | options discussed in section 5.3. |
| 160 | |
| 161 | The option character under normal circumstances is not used. |
| 162 | |
| 163 | |
| 164 | |
| 165 | |
| 166 | |
| 167 | |
| 168 | |
| 169 | |
| 170 | De Winter Standards Track [Page 3] |
| 171 | |
| 172 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 173 | |
| 174 | |
| 175 | 5.1 Server action on receipt of the extended ETRN command |
| 176 | |
| 177 | When the server host receives the ETRN command, it should have a look |
| 178 | at the node name that is specified in the command and make a local |
| 179 | decision if it should honour the request. If not, the appropriate |
| 180 | error codes should be returned to the client. |
| 181 | |
| 182 | Otherwise, the server host should force its retry queues to start |
| 183 | sending messages to that remote site, using another SMTP connection. |
| 184 | At the moment, there is no requirement that a connection must occur, |
| 185 | or that the connection must occur within a given time frame. This |
| 186 | should be noted in the case where there are no messages for the |
| 187 | client host at the server host and only the 250 response is used. |
| 188 | |
| 189 | Since the processing of the queues may take an indeterminate amount |
| 190 | of time, this command should return immediately with a response to |
| 191 | the client host. The valid return codes for this command are: |
| 192 | |
| 193 | 250 OK, queuing for node <x> started |
| 194 | 251 OK, no messages waiting for node <x> |
| 195 | 252 OK, pending messages for node <x> started |
| 196 | 253 OK, <n> pending messages for node <x> started |
| 197 | 458 Unable to queue messages for node <x> |
| 198 | 459 Node <x> not allowed: <reason> |
| 199 | 500 Syntax Error |
| 200 | 501 Syntax Error in Parameters |
| 201 | |
| 202 | The 250 response code does not indicate that messages will be sent to |
| 203 | the system in question, just that the queue has been started and some |
| 204 | action will occur. If the server is capable of supporting it, the |
| 205 | 251, 252 or 253 response codes should be used to give more |
| 206 | information to the client side. In this case, if there are messages |
| 207 | waiting for the client side node, a check can be performed using |
| 208 | these responses codes as an indication of when there are no more |
| 209 | pending messages in the queue for that node. |
| 210 | |
| 211 | The 458 and 459 result codes should be used to give more information |
| 212 | back to the client host as to why the action was not performed. If |
| 213 | the syntax of the request is not correct, then the 500 and 501 result |
| 214 | codes should be used. |
| 215 | |
| 216 | 5.2 Client action on receiving response to extended ETRN command |
| 217 | |
| 218 | If one of the 500 level error codes (550 or 551) are sent, the client |
| 219 | should assume that the protocol is not supported in the remote host |
| 220 | or that the protocol has not been implemented correctly on either the |
| 221 | client or server host. In this case, multiple ETRN commands (dealing |
| 222 | with the aliases for the system) should not be sent. |
| 223 | |
| 224 | |
| 225 | |
| 226 | De Winter Standards Track [Page 4] |
| 227 | |
| 228 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 229 | |
| 230 | |
| 231 | If the 250 response is received, then the client host can assume that |
| 232 | the server host found its request to be satisfactory and it will send |
| 233 | any queued messages. This process may involve going through a very |
| 234 | large retry queue, and may take some time. |
| 235 | |
| 236 | If the 400 level response is received, then the client can assume |
| 237 | that the server supports the command, but for some local reason does |
| 238 | not want to accept the ETRN command as is. In most cases, it will |
| 239 | mean that there is a list of nodes that it will accept the command |
| 240 | from and the current client is not on that list. The 459 response |
| 241 | code is presented to allow for a more in-depth reason as to why the |
| 242 | remote queuing cannot be started. |
| 243 | |
| 244 | 5.3 Use Of ETRN to release mail for a subdomain or queue |
| 245 | |
| 246 | If the requesting server wishes to release all of the mail for a |
| 247 | given subdomain, a variation on the ETRN command can be used. To |
| 248 | perform this request, the option character '@' should be used in |
| 249 | front of the node name. In this manner, any domain names that are |
| 250 | formed with a suffix of the specified node name are released. |
| 251 | |
| 252 | For example, if the command ETRN @foo.com was issued, then any |
| 253 | accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com |
| 254 | may be released. It should be noted that the receiving side of the |
| 255 | ETRN command should make a decision based on the client in question |
| 256 | and only allow certain combinations for each of the nodes. This is |
| 257 | more of a security issue than anything else. |
| 258 | |
| 259 | In a similar vein, it might be necessary under some circumstances to |
| 260 | release a certain queue, where that queue does not correspond to a |
| 261 | given domain name. To this end, the option character '#' can be used |
| 262 | to force the processing of a given queue. In this case, the node |
| 263 | name would be used as a queue name instead, and its syntactical |
| 264 | structure would be dependant on the receiving server. An example of |
| 265 | this would be using the command ETRN #uucp to force the flush of a |
| 266 | UUCP queue. Note that the use of this option is entirely a local |
| 267 | matter and there is no way for a client to find a list of any such |
| 268 | queues that exist. |
| 269 | |
| 270 | 6. Minimal usage |
| 271 | |
| 272 | A "minimal" client may use this extension with its host name to start |
| 273 | the queues on the server host. This minimal usage will not handle |
| 274 | cases where mail for 'x.y' is sent to 's.x.y'. |
| 275 | |
| 276 | A minimal server may use this extensions to start the processing of |
| 277 | the queues for all remote sites. In this case, the 458 error |
| 278 | response will not be seen, and it should always return the 250 |
| 279 | |
| 280 | |
| 281 | |
| 282 | De Winter Standards Track [Page 5] |
| 283 | |
| 284 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 285 | |
| 286 | |
| 287 | response as it will always try and start the processing for any |
| 288 | request. |
| 289 | |
| 290 | 7. Example |
| 291 | |
| 292 | The following example illustrates the use of remote queue processing |
| 293 | with some permanent and temporary failures. |
| 294 | |
| 295 | S: <wait for connection on TCP port 25> |
| 296 | C: <open connection to server> |
| 297 | S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) |
| 298 | C: EHLO ymir.claremont.edu |
| 299 | S: 250-sigurd.innosoft.com |
| 300 | S: 250-EXPN |
| 301 | S: 250-HELP |
| 302 | S: 250 ETRN |
| 303 | C: ETRN |
| 304 | S: 500 Syntax Error |
| 305 | C: ETRN localname |
| 306 | S: 501 Syntax Error in Parameters |
| 307 | C: ETRN uu.net |
| 308 | S: 458 Unable to queue messages for node uu.net |
| 309 | ... |
| 310 | |
| 311 | C: ETRN sigurd.innosoft.com |
| 312 | S: 250 OK, queuing for node sigurd.innosoft.com started |
| 313 | C: ETRN innosoft.com |
| 314 | S: 250 OK, queuing for node innosoft.com started |
| 315 | |
| 316 | OR |
| 317 | |
| 318 | C: ETRN sigurd.innosoft.com |
| 319 | S: 251 OK, no messages waiting for node sigurd.innosoft.com |
| 320 | C: ETRN innosoft.com |
| 321 | S: 252 OK, pending messages for node innosoft.com started |
| 322 | C: ETRN mysoft.com |
| 323 | S: 253 OK, 14 pending messages for node mysoft.com started |
| 324 | |
| 325 | ... |
| 326 | C: ETRN foo.bar |
| 327 | S: 459 Node foo.bar not allowed: Unable to resolve name. |
| 328 | ... |
| 329 | C: QUIT |
| 330 | S: 250 Goodbye |
| 331 | |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | De Winter Standards Track [Page 6] |
| 339 | |
| 340 | RFC 1985 SMTP Service Extension - ETRN August 1996 |
| 341 | |
| 342 | |
| 343 | 8. Security Considerations |
| 344 | |
| 345 | This command does not compromise any security considerations of any |
| 346 | existing SMTP or ESMTP protocols as it merely shortens the time that |
| 347 | a client needs to wait before their messages are retried. |
| 348 | |
| 349 | Precautions should be taken to make sure that any client server can |
| 350 | only use the @ and # option characters for systems that make sense. |
| 351 | Failure to implement some kind of sanity checking on the parameters |
| 352 | could lead to congestion. This would be evident if a person asking |
| 353 | to release @com, which would release mail for any address that ended |
| 354 | with com. |
| 355 | |
| 356 | 9. Acknowledgements |
| 357 | |
| 358 | This document was created with lots of support from the users of our |
| 359 | products, who have given some input to the functionality that they |
| 360 | would like to see in the software that they bought. |
| 361 | |
| 362 | 10. References |
| 363 | |
| 364 | [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC |
| 365 | 821, August 1982. |
| 366 | |
| 367 | [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, |
| 368 | E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United |
| 369 | Nations University, Innosoft International, Inc., Dover Beach |
| 370 | Consulting, Inc., Network Management Associates, Inc., The Branch |
| 371 | Office, February 1993. |
| 372 | |
| 373 | 11. Author's Address |
| 374 | |
| 375 | Jack De Winter |
| 376 | Wildbear Consulting, Inc. |
| 377 | 17 Brock Street |
| 378 | Kitchener, Ontario, Canada |
| 379 | N2M 1X2 |
| 380 | |
| 381 | Phone: +1 519 576 3873 |
| 382 | EMail: jack@wildbear.on.ca |
| 383 | |
| 384 | |
| 385 | |
| 386 | |
| 387 | |
| 388 | |
| 389 | |
| 390 | |
| 391 | |
| 392 | |
| 393 | |
| 394 | De Winter Standards Track [Page 7] |
| 395 | |