Re: Fwd: Balsa default mail submission on TCP port 587, not port 25 [major satx rr com]



On 2001.07.10 10:20 balsa@microwave.com wrote:
> On Tue, 10 Jul 2001, Brian Stafford wrote:
> 
> > On 2001.07.09 18:35:20 +0100 balsa@microwave.com wrote:
> >
> > > > > Ok, perhaps not a 'port' field, but some indication of what a
> defaut value
> > > > > is. Perhaps if someone enters just "smtp.foobar.com", it should
> > > > > automatically add (not just internally, but in the displayed
> setting as
> > > > > well), the :587 (or whatever the official designator is)..
> > > >
> > > > I disagree.  libESMTP, and hence Balsa, does the correct thing with
> a bare
> > > > domain name.
> > >
> > > It may very well 'do' the correct thing, but it doesnt take much care
> to
> > > *show* what it is doing.
> >
> > Well, the application just passes the string to the libESMTP API which
> parses
> > it as it sees fit.  As long as the application does not make
> assumptions
> > about the syntax of this, it is easy to extend it in the future without
> breaking
> > the application. I consider that it is enough to document the syntax
> somewhere.
> >
> > One possible future syntax extension might be to accept something like
> > "|/usr/sbin/sendmail -bs"; its sort of hard to see how to explain the
> default
> > port number on that one.  The situation is bad if the application nails
> > on ":587" to the end of the string the user specifies.  Worse still if
> it
> > refuses to pass the string to the libESMTP API or crashes because it
> can't
> > parse the syntax.
> 
> Im not suggesting that the application tack it on unless it is the app
> that is defaulting it, I am suggesting that if what is entered is not a
> FULL canonical representation of the setting, that whatever canonizes it
> (which I guess to be libESMTP from your message), should feed the
> canonical setting back to be displayed in the UI. It should not be
> allowed
> to remain in 'partial' format in the stored/displayed settings
> 
> I suppose libESMTP probably has no support to do that right now. Perhaps
> the "correct" fix would be for that to be added.
> 
> >
> > > > > I can think of no other MUA that both defaults to what is (irt
> current
> > > > > deployment) a non-standard port,
> > > >
> > > > Er, sorry but RFC 2476 states that 587 is the standard port for
> mail
> > > > *submission*.  Port 25 is the standard port for mail *relay*.  Like
> it or
> > > > not these are different protocols, hence the different port
> numbers.
> > > > RFC 2476 is s standards track RFC so you are wrong about the non
> standard
> > bit.
> > >
> > > Ok, it may be the current _specified_ standard, but it is deployed
> almost
> > > nowhere. (Probably since very few current 'popular' (eg Micro$oft) 
> MUAs
> > > have any idea what it is yet)
> >
> > So what?  Are you saying that the open source community must wait for
> > commercial software to adopt a standard before it does so for itself?
> > The reality is that RFC 2476 is only about 18 months old.  However
> > recent releases of MTAs are starting to adopt it (sendmail comes to
> mind,
> > it hasn't waited for Netscape or MS to act first).
> 
> No, I am NOT saying not to adopt it. In fact, I am very much in agreement
> with splitting mail relay from mail submission (eg, using port 587).
> 
> I AM saying then when you do adopt something as default that is
> implemented almost nowhere, you should make it very obvious that you are
> doing so. Hence giving SOME indication when making this configuration
> entry that if a raw hostname is entered, port 587 will be used.
> 
> > > > Um... read Balsa's docs or the README file.  Both explain the
> default.
> > >
> > > 'immediate', eg on the config dialog. Not buried in documentation.
> >
> > Provide a patch to put the info in a tool tip or something if you
> > feel that strongly about it.
> >
> > > > When it comes to adopting new protocols or standards, someone has
> to take
> > > > the lead.  The argument that other programs don't do it yet hardly
> stands
> > > > up, especially considering that there are no issues with
> interoperability.
> > >
> > > I dont have a problem with balsa defaulting to 587, just that it
> doesnt
> > > make it very apparent that it is doing so.
> >
> > Would you have a problem with the default being port 25 without
> explanation?
> > I doubt you'd have thought to even raise the point, despite the fact
> that SMTP
> > on port 25 was designed for mail relay and was never intended for mail
> > submission (hence RFC 2476).
> 
> Yes, but that is what has been implemented for quite some time. It would,
> regardless, STILL be technically incorrect to not make the default clear
> ON THE CONFIG PANE, wether it was port 25, 587, or 12345. It just has
> more
> opportunity to cause problems if the hidden default is not the "best
> current practice"
> 
> > The problem here is people "just know" that SMTP happens to be on port
> 25
> > therefore that is where their MUA should look for a server.  The plain
> fact
> > is that such folk knowledge is wrong.  By implementing the correct
> standard
> > people are forced to confront the issue and configure things properly
> or,
> > at worst, to suit their local situation.  If they actually read the
> > documentation first they might not even have to complain about this on
> > the list.
> >
> > Brian Stafford
> >
> 
> 

Balsa and all other Mail User Agents must allow the user to specify a port
for the Remote SMTP Server to be in accordance with RFC2476, "Message
Submission" (http://www.faqs.org/rfcs/rfc2476.html), and with RFC2821,
"Simple Mail Transfer Protocol" (http://www.faqs.org/rfcs/rfc2821.html).

RFC2476, Section 3.1, "Submission Identification", states "Port 587 is
reserved for email message submission as specified in this document.
Messages received on this port are defined to be submissions. The protocol
used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified
here.... While most email clients and servers can be configured to use port
587 instead of 25, there are cases where this is not possible or
convenient. A site MAY choose to use port 25 for message submission, by
designating some hosts to be MSAs and others to be MTAs."

RFC2821, Section 3.7, "Relaying", states "... Many mail-sending clients
exist, especially in conjunction with facilities that receive mail via POP3
or IMAP, that have limited capability to support some of the requirements
of this specification, such as the ability to queue messages for subsequent
delivery attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing and
subsequent distribution. SMTP, as specified here, is not ideally suited for
this role, and work is underway on standardized mail submission protocols
that might eventually supercede the current practices. In any event,
because these arrangements are private and fall outside the scope of this
specification, they are not described here."

Note that RFC2476, Section 3.1, uses the word "MAY" in accordance with
RFC2119, "Key words for use in RFCs to Indicate Requirement Levels"
(http://www.faqs.org/rfcs/rfc2119.html), to indicate "that an item is truly
optional". RFC2821, Section 3.7, indicates that private arrangements may be
made. These two RFCs taken together or separately clearly indicate that a
site may use port 25 for message submission. RFC2476 clearly encourages the
use of port 587 for message submission, but it ultimately leaves a choice
whether or not to actually do so. RFC2821 does reference RFC2476, and
RFC2821 clearly recommends that message submission is better left to a
dedicated message submission agent, but it acknowledges the common practice
of
private arrangements that violate that recommendation.

In order to accommodate sites that designate message submission hosts that
use port 25 and sites that could, by private arrangement, use potentially
any port, Balsa and all other Mail User Agents must allow the user to
specify a port for the Remote SMTP Server in some type of configuration
dialog or setting.

-----------------
major@satx.rr.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]