idnits 2.17.00 (12 Aug 2021) /tmp/idnits34574/draft-melnikov-submit-port-01.txt: 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 Internet-Drafts being working documents. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 310 lines 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. ** There are 27 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC-2476]), 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 == Line 25 has weird spacing: '...ocument sugge...' == Line 26 has weird spacing: '... and requ...' == Line 36 has weird spacing: '...ol used for ...' == Line 40 has weird spacing: '...servers may ...' == Line 44 has weird spacing: '...ble way to...' == (12 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ESMTP' is mentioned on line 117, but not defined ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTP-URL' ** Obsolete normative reference: RFC 2192 (ref. 'IMAP-URL') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1738 (ref. 'BASIC-URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-melnikov-submit-port-01.txt Alexey Melnikov 3 An SMTP Service Extension for discovering 4 the location of a Submit server 6 Status of this Memo 8 This document is an Internet-Draft and is in full conformance with 9 all provisions of Section 10 of RFC2026. Internet-Drafts are 10 working documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet- Drafts as 17 reference material or to cite them other than as "work in progress." 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 This document suggests a proposed protocol for the Internet 26 community, and requests discussion and suggestions for 27 improvements. Distribution of this draft is unlimited. 29 The protocol discussed in this document is experimental and subject 30 to change. Persons planning on either implementing or using this 31 protocol are STRONGLY URGED to get in touch with the author before 32 embarking on such a project. 34 Abstract 36 [RFC-2476] defines a new protocol used for message submission. 37 In many circumstances it could be located on port different from the 38 traditional SMTP port. The fate of a message may depend on whether 39 a particular server is a Submit or SMTP server, because even inside the 40 same organization, Submit and SMTP servers may enforce different 41 policies. Thus the correct discovery of the submit server location is 42 important. 44 Currently there is no standardized and generally acceptable way to 45 discover the location of submit server. One may use DNS SRV 46 records, the other may choose to query SLP, LDAP or ACAP server. 48 This document describes an easy way to discover the location of 49 submit server while staying in bounds of SMTP protocol. The 50 advantage of the extension is its almost zero cost of 51 implementation. 53 0. Meta-information on this draft 55 This information is intended to facilitate discussion. It will be 56 removed when this document leaves the Internet-Draft stage. 58 0.1 Open Issues 60 1). Should "AUTH=" authentication parameter be allowed in Submit URL? 62 2). Should multiple URL's be allowed? 64 0.2. History of changes 66 Changes from the revision 00: 68 1). Added motivation section. I am not sure about it yet. If you have 69 additional examples how to use this extension, feel free to send them. 71 2). Corrected a lot of language nuances. Thanks to Tony Hansen. 73 1. Conventions Used in this Document 75 SMTP server that client connects to initially will be called 76 Initial SMTP server. 78 In examples, "C:" and "S:" indicate lines sent by the client and 79 server respectively. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 83 this document are to be interpreted as described in [KEYWORDS]. 85 2. Motivation 87 In several cases users have no need to change (and hence discover) the 88 location of a Submission Server. For example, user has free access to home 89 Submission Server from office, home and being on the road. In addition, 90 organization policy demands from the user to use corporate Submit Server 91 to send all outgoing mail in order to perform logging and audit trail. 93 However, conditions could exist that may force users to use different 94 Submission Servers in different periods of time and thus use the extension 95 defined in this document. For example, 97 1). A network is isolated from the outside world by a firewall, that 98 prohibits connections to the mail server from the outside. At home the user 99 is forced to use another submission server. 101 2). A user is working for several different organizations. Each organization 102 may insist on using their own submission server. 104 Administrators may consider using this extension in order to make Submit 105 Server migration transparent. 107 The extension is intended to help both users and administrators to minimize 108 efforts of configuring/reconfiguring mail clients in order to send mail 109 through Submit Server. 111 It is possible that that extension will be eliminated in the future 112 by widely deployed general use protocol. 114 3. Framework for the Submit Server Discovery SMTP service extension 116 The Submit Server Location Discovery SMTP service extension uses 117 the SMTP service extension mechanism described in [ESMTP]. The 118 following SMTP service extension is therefore defined: 120 (1) The name of the SMTP service extension is "Submit Server Location 121 Discovery". 123 (2) The EHLO keyword value associated with this service extension is 124 "SUBMIT". 126 (3) One optional parameter is allowed with this EHLO keyword value, an 127 SMTP URL that specifies the location of Submit Server (referral). 128 The syntax of the parameter is defined in section 5. 130 If the parameter is omitted, this means that that server is a Submit 131 Server itself. 133 (4) no additional SMTP verbs are defined by this extension. 135 4. The Submit Server Discovery SMTP service extension 137 A SMTP client wishing to locate a Submit Server may issue the EHLO 138 command to start a SMTP session and to determine if the SMTP server 139 supports the service extension. If the server responds with code 140 250 to the EHLO command, and the response includes the EHLO keyword 141 SUBMIT, then the Submit Server Discovery SMTP service extension is 142 supported by the server and client may use the parameter of the SUBMIT 143 keyword as an address of Submit Server. 145 The parameter of the SUBMIT keyword is either an SMTP URL or 146 a Truncated SMTP URL. 148 The later is a brief form of an SMTP URL with an omitted host name. 149 In order to connect to Submit Server client should add the host it 150 used to connect to this particular SMTP Server. 152 A SUBMIT capable ESMTP server SHOULD NOT return an URL referring 153 to a server that will return a referral. A client MUST NOT follow 154 more than 10 levels of referral without consulting the user. 156 Example 1: 157 S: 220 smtp.example.com ESMTP server ready 158 C: EHLO dragon.demo.ru 159 S: 250-smtp.example.com 160 S: 250-AUTH CRAM-MD5 DIGEST-MD5 161 S: 250 SUBMIT smtp://submit.example.com:11111 162 C: QUIT 164 Example 2 (Submit server was moved to a different location): 165 S: 521 This host doesn't accept mail any more 166 C: EHLO main.demo.ru 167 S: 250-smtp.example.com 168 S: 250 SUBMIT smtp://submit.example.com 169 C: QUIT 171 5. Formal Syntax 173 The following syntax specification uses the augmented Backus-Naur 174 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 175 rules as specified in Appendix A of the ABNF specification [ABNF]. 177 Except as noted otherwise, all alphabetic characters are case- 178 insensitive. The use of upper or lower case characters to define 179 token strings is for editorial clarity only. Implementations MUST 180 accept these strings in a case-insensitive fashion. 182 Tokens that are used but otherwise unspecified come from [SMTP-URL]. 184 submit-referral = (url-smtp / url-smtp-truncated) 186 url-smtp-truncated = "smtp://" ":" [port] 187 ;; See [BASIC-URL] for definition of "port". 188 ;; Client should use the same host and 189 ;; specified Submit port. 190 ;; If no port specified then default port 191 ;; for Submission server (587) is used 192 ;; as specified in [RFC-2476] 194 6. Security Considerations 196 The Submit Server Discovery extension makes use of SMTP URLs, and as 197 such, have the same security considerations as general internet URLs 198 [BASIC-URL], and in particular SMTP URLs [SMTP-URL]. 200 Server MUST NOT send an URL other than an [SMTP-URL]. Client MUST ignore 201 non-SMTP URLs. Server SHOULD NOT send an ";AUTH=" parameter as a part of 202 submit-referral. Client SHOULD check the syntax of the submit-referral and 203 ignore the URL if the syntax is invalid. Client SHOULD treat any ";AUTH=" 204 parameter as ";AUTH=*" [IMAP-URL], i.e. the client SHOULD select an 205 appropriate authentication mechanism itself. 207 A server SHOULD NOT send a host name that doesn't have an associated DNS A or 208 CNAME RR. The IP address could be used in the case when a host doesn't have a 209 resolvable DNS name. 211 A client MUST treat a permanent DNS error (for example "No Such Domain") as a 212 permanent error to inject message into Mail Transport Environment and 213 SHOULD NOT try to use the Initial SMTP server as the Submit server. 215 Server MAY decide not to send URL to the client that has untrustworthy IP 216 address or host name. How server makes decision is outside the scope of this 217 document. 219 7. Copyright 221 Copyright (C) The Internet Society 1999. All Rights Reserved. 223 This document and translations of it may be copied and furnished to 224 others, and derivative works that comment on or otherwise explain it 225 or assist in its implementation may be prepared, copied, published 226 and distributed, in whole or in part, without restriction of any 227 kind, provided that the above copyright notice and this paragraph 228 are included on all such copies and derivative works. However, this 229 document itself may not be modified in any way, such as by removing 230 the copyright notice or references to the Internet Society or other 231 Internet organizations, except as needed for the purpose of 232 developing Internet standards in which case the procedures for 233 copyrights defined in the Internet Standards process must be 234 followed, or as required to translate it into languages other than 235 English. 237 The limited permissions granted above are perpetual and will not be 238 revoked by the Internet Society or its successors or assigns. 240 This document and the information contained herein is provided on an 241 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 242 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 243 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 244 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 245 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 8. Acknowledgments 249 This document is the product of informal discussions that took place 250 in Orlando IETF. The help of those who took the time to review this 251 memo and make suggestions is appreciated, especially that of Randall 252 Gellens, Daniel Senie, and Dan Wing. Special thanks to Tony Hansen 253 for reviewing the document. 255 9. References 257 [RFC-2476] Gellens, Klensin, "Message Submission", RFC 2476, 258 December 1998. 260 262 [SMTP-URL] Earhart, "An SMTP URL Interface", Work in progress, 264 266 [IMAP-URL] Newman, "IMAP URL Scheme", RFC 2192, July 1997. 268 270 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 271 ABNF", RFC 2234, November 1997. 273 275 [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource 276 Locators (URL)", RFC 1738, December 1994. 278 280 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 285 10. Author's Address 287 Alexey Melnikov 288 Messaging Direct, Inc. 290 Home address : 291 121293, Russia, Moscow, 292 general Ermolov street, 6 - 90 294 Email: alexey.melnikov@messagingdirect.com 296 Fax (San Diego, CA) : 1 (619) 8393837