I've missed deadline, so I am posting new draft to mailing lists.
Suggestions are welcome. Also it would be very interested to know
whether this feature will have support.
--
Regards,
Alexey Melnikov
An SMTP Extension for discovering
the location of 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."
To view the list Internet-Draft Shadow Directories, see
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
[SUBMIT] 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
particular server is Submit or SMTP server, because even inside the
same organization Submit and SMTP servers may inforce different
user policy. Thus the correct discovering of 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 this document is its almost zero cost of
implementation.
It is possible that that protocol will be eliminated in the future
by widely deployed general use protocol.
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
Should "AUTH=" authentication parameter be allowed in Submit URL?
Should multiple URL's be allowed?
1. Conventions Used in this Document
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. 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, a
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 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 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 SUBMIT
keyword as an address of Submit Server.
The parameter of SUBMIT keyword is either SMTP URL or Truncated
SMTP URL.
The later is a brief form of SMTP URL with 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 referencing
to a server that will return a referral. A client MUST NOT follow
more than 10 levels of referral without consulting the user.
Examples:
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
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 Submit
;; port is used
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].
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. References
[SMTP-URL] Earhart, "An SMTP URL Interface", Work in progress,
<ftp://ftp.ietf.org/internet-drafts/draft-earhart-url-smtp-00.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>
9. Author's Address
Alexey Melnikov
Epsylon Technologies
Home address :
121293, Russia, Moscow,
general Ermolov street, 6 - 90
Email: mel(_at_)taxxi(_dot_)com
Fax (San Diego, CA) : 1 (619) 8393837