idnits 2.17.1 draft-gellens-on-demand-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ETRN], [SMTP,ESMTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 May 1999) is 9121 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CODES-EXTENSION' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'SMTP-CODES' is defined on line 351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2554 (ref. 'AUTH') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 1893 (ref. 'SMTP-CODES') (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: On-Demand Mail Relay R. Gellens 2 Document: draft-gellens-on-demand-07.txt Qualcomm 3 Expires: 7 November 1999 7 May 1999 5 ON-DEMAND MAIL RELAY (ODMR) 6 SMTP with Dynamic IP Addresses 8 Status of this Memo: 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 A version of this draft document is intended for submission to the 30 RFC editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested. 33 Copyright Notice 35 Copyright (C) The Internet Society 1999. All Rights Reserved. 37 Table of Contents 39 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 41 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 4 45 5.1.1. EHLO . . . . . . . . . . . . . . . . . . . . . . . . 4 46 5.1.2. AUTH . . . . . . . . . . . . . . . . . . . . . . . . 4 47 5.1.3. QUIT . . . . . . . . . . . . . . . . . . . . . . . . 5 48 5.2. Authenticated State . . . . . . . . . . . . . . . . . . . 5 49 5.2.1. ATRN (Authenticated TURN) . . . . . . . . . . . . . 5 50 5.3. Reversed State . . . . . . . . . . . . . . . . . . . . . 6 51 5.4. Other Commands . . . . . . . . . . . . . . . . . . . . . 6 52 6. Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6 53 7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 7 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 58 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 60 1. Abstract 62 With the spread of low-cost computer systems and Internet 63 connectivity, the demand for local mail servers has been rising. 64 Many people now want to operate a mail server on a system which has 65 only an intermittent connection to a service provider. If the 66 system has a static IP address, the ESMTP ETRN command [ETRN] can be 67 used. However, systems with dynamic IP addresses (which are very 68 common with low-cost connections) have no widely-deployed solution. 70 This memo proposes a new service, On-Demand Mail Relay (ODMR), which 71 is a profile of SMTP [SMTP, ESMTP], providing for a secure, 72 extensible, easy to implement approach to the problem. 74 2. Conventions Used in this Document 76 Because the client and server roles reverse during the session, to 77 avoid confusion, the terms "customer" and "provider" will be used in 78 place of "client" and "server", although of course this protocol may 79 be useful in cases other than commercial service providers and 80 customers. 82 In examples, "P:" is used to indicate lines sent by the provider, 83 and "C:" indicates those sent by the customer. Line breaks within a 84 command are for editorial purposes only. 86 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 87 in this document are to be interpreted as defined in [KEYWORDS]. 89 Examples use 'example.net' as the provider, and 'example.org' and 90 'example.com' as the customers. 92 3. Comments 94 Private comments should be sent to the author. Public comments may 95 be sent to the IETF Disconnected SMTP mailing list, 96 . To subscribe, send a message to 97 containing the word SUBSCRIBE as 98 the body. 100 4. Description 102 On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. 103 Port 366 is reserved for On-Demand Mail Relay. The initial client 104 and server roles are short-lived, as the point is to allow the 105 intermittently-connected host to request mail held for it by a 106 service provider. 108 The customer initiates a connection to the provider, authenticates, 109 and requests its mail. The roles of client and server then reverse, 110 and normal SMTP [SMTP, ESMTP] proceeds. 112 The provider has an On-Demand Mail Relay process listening for 113 connections on the ODMR port. This process does not need to be a 114 full SMTP server. It does need to be an SMTP client with access to 115 the outgoing mail queues, and as a server implement the EHLO, AUTH, 116 ATRN, and QUIT commands. 118 An MTA normally has a mail client component which processes the 119 outgoing mail queues, attempting to send mail for particular 120 domains, based on time or event (such as new mail being placed in 121 the queue, or receipt of an ETRN command by the SMTP server 122 component). The On-Demand Mail Relay service processes the outgoing 123 queue not on a timer or new mail creation, but on request. 125 The provider side has normal SMTP server responsibilities [SMTP], 126 including generation of delivery failure notices, etc. as needed. 128 5. States 130 The On-Demand Mail Relay service has three states: an initial state, 131 an authenticated state, and a reversed state. The state progression 132 is illustrated in the following diagram: 134 --------------------------- 135 ! initial state ! 136 --------------------------- 137 ! ! 138 QUIT AUTH 139 ! ! 140 ! V 141 ! ----------------------- 142 ! ! authenticated state ! 143 ! ----------------------- 144 ! ! ! 145 ! QUIT ATRN 146 ! ! ! 147 ! ! V 148 ! ! ------------------ 149 ! ! ! reversed state ! 150 ! ! ------------------ 151 ! ! ! 152 ! ! QUIT 153 ! ! ! 154 V V V 155 --------------------- 156 ! termination ! 157 --------------------- 159 (Note that in the reversed state, commands are sent by the provider, 160 not the customer.) 162 5.1. Initial State 164 In the initial state, the provider is the server and the customer is 165 the client. Three commands are valid: EHLO, AUTH, and QUIT. 167 5.1.1. EHLO 169 The EHLO command is the same as in [ESMTP]. The response MUST 170 include AUTH and ATRN. 172 5.1.2. AUTH 174 The AUTH command is specified in [AUTH]. The AUTH command uses a 175 [SASL] mechanism to authenticate the session. The session is not 176 considered authenticated until a success response to AUTH has been 177 sent. 179 For interoperability, implementations MUST support the CRAM-MD5 180 mechanism [CRAM]. Other SASL mechanisms may be supported. A site 181 MAY disable CRAM-MD5 support if it uses more secure methods. The 182 EXTERNAL mechanism [SASL] might be useful in some cases, for 183 example, if the provider has already authenticated the client, such 184 as during a PPP connection. 186 5.1.3. QUIT 188 The QUIT command is the same as in [SMTP]. 190 5.2. Authenticated State 192 The authenticated state is entered after a successful AUTH command. 193 Two commands are valid in the authenticated state: ATRN and QUIT. 195 5.2.1. ATRN (Authenticated TURN) 197 Unlike the TURN command in [SMTP], the ATRN command optionally takes 198 one or more domains as a parameter. The ATRN command MUST be 199 rejected if the session has not been authenticated. Response code 200 530 [AUTH] is used for this. 202 The timeout for this command MUST be at least 10 minutes to allow 203 the provider time to process its mail queue. 205 An ATRN command sent with no domains is equivalent to an ATRN 206 command specifying all domains to which the customer has access. 208 If the authentication used by the customer does not provide access 209 to all of the domains specified in ATRN, the provider MUST NOT send 210 mail for any domains to the customer; the provider MUST reject the 211 ATRN command with a 450 code. 213 If the customer does have access to all of the specified domains, 214 but none of them have any queued mail, the provider normally rejects 215 the ATRN command with response code 453. The provider MAY instead 216 issue a 250 success code, and after the roles are reversed, send a 217 QUIT following the EHLO. 219 The provider MAY also reject the ATRN command with a 450 response to 220 indicate refusal to accept multiple requests issued within a 221 particular time interval. 223 If the customer has access to all of the specified domains and mail 224 exists in at least one of them, the provider issues a 250 success 225 code. 227 If the server is unable to verify access to the requested domains 228 (for example, a mapping database is temporarily unavailable), 229 response code 451 is sent. 231 [ABNF] for ATRN: 233 atrn = "ATRN" [SP domain *("," domain)] 235 domain = sub-domain 1*("." sub-domain) 237 sub-domain = (ALPHA / DIGIT) *(ldh-str) 239 ldh-str = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) 241 5.3. Reversed State 243 After the provider has sent a success reply to the ATRN command, the 244 roles reverse, and the customer becomes the server, and the provider 245 becomes the client. 247 After receiving the success response to ATRN, the customer sends a 248 standard SMTP initial greeting line. At this point normal SMTP 249 [SMTP, ESMTP] commands are used. Typically the provider sends EHLO 250 after seeing the customer's greeting, to be followed by MAIL FROM 251 and so on. 253 5.4. Other Commands 255 The provider MAY reject all commands other than EHLO, AUTH, ATRN, 256 and QUIT with response code 502. 258 6. Example On-Demand Mail Relay Session: 259 P: 220 EXAMPLE.NET on-demand mail relay server ready 260 C: EHLO example.org 261 P: 250-EXAMPLE.NET 262 P: 250-AUTH CRAM-MD5 EXTERNAL 263 P: 250 ATRN 264 C: AUTH CRAM-MD5 265 P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo= 266 C: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo= 267 P: 235 now authenticated as example.org 268 C: ATRN example.org,example.com 269 P: 250 OK now reversing the connection 270 C: 220 example.org ready to receive email 271 P: EHLO EXAMPLE.NET 272 C: 250-example.org 273 C: 250 SIZE 274 P: MAIL FROM: 275 C: 250 OK 276 P: RCPT TO: 277 C: 250 OK, recipient accepted 278 ... 279 P: QUIT 280 C: 221 example.org closing connection 282 7. Response Codes 284 The response codes used in this document are: 286 250 Requested mail action okay, completed 287 450 ATRN request refused 288 451 Unable to process ATRN request now 289 453 You have no mail 290 502 Command not implemented 291 530 Authentication required [AUTH] 293 8. Security Considerations 295 Because access to the On-Demand Mail Relay server is only useful 296 with a prior arrangement between the parties (so the provider is the 297 target of MX records for the customer's domains and thus has mail to 298 relay), it may be useful for the provider to restrict access to the 299 On-Demand Mail Relay port. For example, the ODMR server could be 300 configurable, or a TCP wrapper or firewall could be used, to block 301 access to port 366 except within the provider's network. This might 302 be useful when the provider is the customer's ISP. Use of such 303 mechanisms does not reduce the need for the AUTH command, however, 304 but can increase the security it provides. 306 Use of SASL in the AUTH command allows for substitution of more 307 secure authentication mechanisms in the future. 309 See sections 5.1.2 and 5.2.1 for additional security details. 311 9. Acknowledgments 313 This draft has been developed in part based on comments and 314 discussions which took place on and off the IETF-disconn-smtp 315 mailing list. Special thanks to Chris Newman and Ned Freed for 316 their comments. 318 10. References 320 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 321 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 322 November 1997. 324 [AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 325 2554, Netscape Communications, March 1999. 326 328 [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning 329 Enhanced Error Codes", RFC 2034, October 1996, 330 332 [CRAM] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for 333 Simple Challenge/Response", RFC 2195, September 1997, 334 336 [ESMTP] Klensin, Freed, Rose, Stefferud, and Crocker, "SMTP Service 337 Extensions", RFC 1869, STD 10, November 1995, 338 340 [ETRN] De Winter, J., "SMTP Service Extension for Remote Message 341 Queue Starting", RFC 1985, August 1996, 342 344 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", RFC 2119, March 1997, 346 348 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 349 RFC 2222, October 1997, 351 [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 352 1893, January 1996, 354 [SMTP] Postel, J., "Simple Mail Transfer Protocol", RFC 821, STD 10, 355 August 1982, 357 11. Full Copyright Statement 359 Copyright (C) The Internet Society 1999. All Rights Reserved. 361 This document and translations of it may be copied and furnished to 362 others, and derivative works that comment on or otherwise explain it 363 or assist in its implementation may be prepared, copied, published 364 and distributed, in whole or in part, without restriction of any 365 kind, provided that the above copyright notice and this paragraph 366 are included on all such copies and derivative works. However, this 367 document itself may not be modified in any way, such as by removing 368 the copyright notice or references to the Internet Society or other 369 Internet organizations, except as needed for the purpose of 370 developing Internet standards in which case the procedures for 371 copyrights defined in the Internet Standards process must be 372 followed, or as required to translate it into languages other than 373 English. 375 The limited permissions granted above are perpetual and will not be 376 revoked by the Internet Society or its successors or assigns. 378 This document and the information contained herein is provided on an 379 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 380 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 381 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 382 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 383 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 385 12. Author's Address 387 Randall Gellens +1.619.651.5115 388 QUALCOMM Incorporated randy@qualcomm.com 389 6455 Lusk Blvd. 390 San Diego, CA 92121-2779 391 U.S.A.