Subject: Re: Submit Server Discovery extension
From: Randall Gellens <[email-masked]>
To: Dan Wing <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 12 Mar 1999 17:26:41 -0800

At 10:29 PM -0800 3/11/99, Dan Wing wrote:

> I don't see the value here.  Why would a client be configured with the
> address of an SMTP server that is something _other_ than its submit
> server?

It's a migration issue.  In any organization (company, ISP, etc.) 
there are likely to be a lot of existing clients configured to submit 
messages using port 25 on some server.  If the intent is to migrate 
all users to submit via the submission port, having a response from 
the old SMTP server may help a lot.

Date: Fri, 12 Mar 1999 11:06:25 -0700
From: Alexey Melnikov <[email-masked]>
To: Dan Wing <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Submit Server Discovery extension
Sender: [email-masked]

Dan Wing wrote:

> On Thu, 11 Mar 1999 19:16 -0700, Alexey Melnikov wrote:
>
> > > On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote:
> > >
> > > > 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.
> > >
> > > How does one determine the IP address (or hostname) of the first SMTP
> > > server (which supports the SUBMIT service extension and tells you the
> > > submit server you're supposed to use)?
> >
> > Client should connect to standard (25) SMTP service port first. If server
> > supports Submit extension and is not submit server it will reference
> > client to the right location.
>
> I don't see the value here.  Why would a client be configured with the
> address of an SMTP server that is something _other_ than its submit
> server?

There is no reason. But the question is that *how* client may find the location
of a submit server. It is good when user knows the exact location of submit
server, but what to do if she doesn't?

Imagine that in some organization there is both submit and regular SMTP
servers.
Regular SMTP only relays mail. It refuses to accept mail from local users.
Submit server authenticate user and allows her to inject message in mail
system. If Submit server is located on non-standard submit port and/or
different host, there is no way to find out its location. In such circumstances
user will be unable to send her mail, till she knows exact host and port.

> If you do decide to go forward with the I-D, though, you certainly need
> to add information on what a client is supposed to do if it can't
> resolve the information provided in the SUBMIT response (such as
> unknown URI or unresolvable DNS hostname).  Should the client ignore
> the ever-so-gentle request to not use that SMTP server as its submit
> server and just go ahead and use it anyway, or ?

Ok. I will think about it.

You also gave me an idea what to add to Security Consideration section.

--
Regards,
Alexey Melnikov

Date: Thu, 11 Mar 1999 22:29:30 -0800 (PST)
From: Dan Wing <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Submit Server Discovery extension
Sender: [email-masked]

On Thu, 11 Mar 1999 19:16 -0700, Alexey Melnikov wrote:

> > On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote:
> >
> > > 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.
> >
> > How does one determine the IP address (or hostname) of the first SMTP
> > server (which supports the SUBMIT service extension and tells you the
> > submit server you're supposed to use)?
> 
> Client should connect to standard (25) SMTP service port first. If server
> supports Submit extension and is not submit server it will reference
> client to the right location.

I don't see the value here.  Why would a client be configured with the
address of an SMTP server that is something _other_ than its submit
server?

If you do decide to go forward with the I-D, though, you certainly need
to add information on what a client is supposed to do if it can't
resolve the information provided in the SUBMIT response (such as 
unknown URI or unresolvable DNS hostname).  Should the client ignore
the ever-so-gentle request to not use that SMTP server as its submit
server and just go ahead and use it anyway, or ?

-Dan Wing

Date: Thu, 11 Mar 1999 19:16:01 -0700
From: Alexey Melnikov <[email-masked]>
To: Dan Wing <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Submit Server Discovery extension
Sender: [email-masked]

Dan Wing wrote:

> On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote:
>
> > 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.
>
> How does one determine the IP address (or hostname) of the first SMTP
> server (which supports the SUBMIT service extension and tells you the
> submit server you're supposed to use)?

Client should connect to standard (25) SMTP service port first. If server
supports Submit extension and is not submit server it will reference
client to the right location.

--
Regards,
AMelnikov

Date: Thu, 11 Mar 1999 15:38:05 -0800 (PST)
From: Dan Wing <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Submit Server Discovery extension
Sender: [email-masked]

On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote:

> 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.

How does one determine the IP address (or hostname) of the first SMTP
server (which supports the SUBMIT service extension and tells you the
submit server you're supposed to use)?

-Dan Wing

Date: Fri, 05 Mar 1999 00:51:16 -0700
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Submit Server Discovery extension
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------529A92F3833DD2685090534E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

--------------529A92F3833DD2685090534E
Content-Type: text/plain; charset=us-ascii;
 name="draft-melnikov-submit-port-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-melnikov-submit-port-00.txt"

                  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: [email-masked]

    Fax (San Diego, CA) : 1 (619) 8393837

--------------529A92F3833DD2685090534E--