draft-melnikov-submit-port-01.txt Alexey Melnikov An SMTP Service Extension for discovering the location of a Submit server Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this draft is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Abstract [RFC-2476] defines a new protocol used for message submission. In many circumstances it could be located on port different from the traditional SMTP port. The fate of a message may depend on whether a particular server is a Submit or SMTP server, because even inside the same organization, Submit and SMTP servers may enforce different policies. Thus the correct discovery of the submit server location is important. Currently there is no standardized and generally acceptable way to discover the location of submit server. One may use DNS SRV records, the other may choose to query SLP, LDAP or ACAP server. This document describes an easy way to discover the location of submit server while staying in bounds of SMTP protocol. The advantage of the extension is its almost zero cost of implementation. 0. Meta-information on this draft This information is intended to facilitate discussion. It will be removed when this document leaves the Internet-Draft stage. 0.1 Open Issues 1). Should "AUTH=" authentication parameter be allowed in Submit URL? 2). Should multiple URL's be allowed? 0.2. History of changes Changes from the revision 00: 1). Added motivation section. I am not sure about it yet. If you have additional examples how to use this extension, feel free to send them. 2). Corrected a lot of language nuances. Thanks to Tony Hansen. 1. Conventions Used in this Document SMTP server that client connects to initially will be called Initial SMTP server. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 2. Motivation In several cases users have no need to change (and hence discover) the location of a Submission Server. For example, user has free access to home Submission Server from office, home and being on the road. In addition, organization policy demands from the user to use corporate Submit Server to send all outgoing mail in order to perform logging and audit trail. However, conditions could exist that may force users to use different Submission Servers in different periods of time and thus use the extension defined in this document. For example, 1). A network is isolated from the outside world by a firewall, that prohibits connections to the mail server from the outside. At home the user is forced to use another submission server. 2). A user is working for several different organizations. Each organization may insist on using their own submission server. Administrators may consider using this extension in order to make Submit Server migration transparent. The extension is intended to help both users and administrators to minimize efforts of configuring/reconfiguring mail clients in order to send mail through Submit Server. It is possible that that extension will be eliminated in the future by widely deployed general use protocol. 3. Framework for the Submit Server Discovery SMTP service extension The Submit Server Location Discovery SMTP service extension uses the SMTP service extension mechanism described in [ESMTP]. The following SMTP service extension is therefore defined: (1) The name of the SMTP service extension is "Submit Server Location Discovery". (2) The EHLO keyword value associated with this service extension is "SUBMIT". (3) One optional parameter is allowed with this EHLO keyword value, an SMTP URL that specifies the location of Submit Server (referral). The syntax of the parameter is defined in section 5. If the parameter is omitted, this means that that server is a Submit Server itself. (4) no additional SMTP verbs are defined by this extension. 4. The Submit Server Discovery SMTP service extension A SMTP client wishing to locate a Submit Server may issue the EHLO command to start a SMTP session and to determine if the SMTP server supports the service extension. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword SUBMIT, then the Submit Server Discovery SMTP service extension is supported by the server and client may use the parameter of the SUBMIT keyword as an address of Submit Server. The parameter of the SUBMIT keyword is either an SMTP URL or a Truncated SMTP URL. The later is a brief form of an SMTP URL with an omitted host name. In order to connect to Submit Server client should add the host it used to connect to this particular SMTP Server. A SUBMIT capable ESMTP server SHOULD NOT return an URL referring to a server that will return a referral. A client MUST NOT follow more than 10 levels of referral without consulting the user. Example 1: S: 220 smtp.example.com ESMTP server ready C: EHLO dragon.demo.ru S: 250-smtp.example.com S: 250-AUTH CRAM-MD5 DIGEST-MD5 S: 250 SUBMIT smtp://submit.example.com:11111 C: QUIT Example 2 (Submit server was moved to a different location): S: 521 This host doesn't accept mail any more C: EHLO main.demo.ru S: 250-smtp.example.com S: 250 SUBMIT smtp://submit.example.com C: QUIT 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of the ABNF specification [ABNF]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Tokens that are used but otherwise unspecified come from [SMTP-URL]. submit-referral = (url-smtp / url-smtp-truncated) url-smtp-truncated = "smtp://" ":" [port] ;; See [BASIC-URL] for definition of "port". ;; Client should use the same host and ;; specified Submit port. ;; If no port specified then default port ;; for Submission server (587) is used ;; as specified in [RFC-2476] 6. Security Considerations The Submit Server Discovery extension makes use of SMTP URLs, and as such, have the same security considerations as general internet URLs [BASIC-URL], and in particular SMTP URLs [SMTP-URL]. Server MUST NOT send an URL other than an [SMTP-URL]. Client MUST ignore non-SMTP URLs. Server SHOULD NOT send an ";AUTH=" parameter as a part of submit-referral. Client SHOULD check the syntax of the submit-referral and ignore the URL if the syntax is invalid. Client SHOULD treat any ";AUTH=" parameter as ";AUTH=*" [IMAP-URL], i.e. the client SHOULD select an appropriate authentication mechanism itself. A server SHOULD NOT send a host name that doesn't have an associated DNS A or CNAME RR. The IP address could be used in the case when a host doesn't have a resolvable DNS name. A client MUST treat a permanent DNS error (for example "No Such Domain") as a permanent error to inject message into Mail Transport Environment and SHOULD NOT try to use the Initial SMTP server as the Submit server. Server MAY decide not to send URL to the client that has untrustworthy IP address or host name. How server makes decision is outside the scope of this document. 7. Copyright Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Acknowledgments This document is the product of informal discussions that took place in Orlando IETF. The help of those who took the time to review this memo and make suggestions is appreciated, especially that of Randall Gellens, Daniel Senie, and Dan Wing. Special thanks to Tony Hansen for reviewing the document. 9. References [RFC-2476] Gellens, Klensin, "Message Submission", RFC 2476, December 1998. <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2476.txt> [SMTP-URL] Earhart, "An SMTP URL Interface", Work in progress, <ftp://ftp.ietf.org/internet-drafts/draft-earhart-url-smtp-00.txt> [IMAP-URL] Newman, "IMAP URL Scheme", RFC 2192, July 1997. <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2192.txt> [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2234.txt> [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1738.txt> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2119.txt> 10. Author's Address Alexey Melnikov Messaging Direct, Inc. Home address : 121293, Russia, Moscow, general Ermolov street, 6 - 90 Email: alexey.melnikov@messagingdirect.com Fax (San Diego, CA) : 1 (619) 8393837