Re: Submit Server Discovery extension

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