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

[Brian Stafford <brian stafford uklinux net>]

On Mon,  9 July 16:17 balsa@microwave.com wrote:
> 
> Perhaps, as was suggested, this should be made more apparent by adding a
> "Port" field to the relevant dialog, which shows the default if it is not
> changed.

The reason this is not the case can be found in the archive.

In summary, as features are added to libESMTP the syntax of the host:service
field may be expanded to allow for the greater flexibility, e.g. URI syntax
may be more appropriate in the future.  Now that libESMTP uses the protocol
independent getaddrinfo() resolver interface, specifying port numbers at
all may be considered to be wrong.  The remote host should be specified
as a domain name and a service name.  Taking these two considerations
together it is obvious that forcing the application to guess the correct
syntax from two fields is fraught with difficulty.

Furthermore, mail submission is fundamentally a different protocol to
SMTP.  Just because it looks the same on the wire does not mean it has the
same semantics.  Different things can happen when connected to an MSA on
587 than to an MTA on 25.  See RFC 2476 for examples of the differences.
Although it looks like a duck and quacks like a duck, it certainly is not
a duck.

Users must be aware that submitting mail on port 25 may not behave as
expected, for example, if they expect incomplete domain names in message
headers to be qualified.  If this happens on 25 it's just plain wrong and
it damages the mail transport infrastructure.  Mail should never be submitted
on port 25 except in strictly controlled circumstances.  However until use of
port 587 is more fully deployed we are stuck with a less than ideal situation.

The decision to default to 587 and to eliminate the seperate port number
field in Balsa's interface was not a frivolous one.  However the reasoning
behind it requires a good understanding of the current mail RFCs and
some idea of where libESMTP might go in the future.

Brian Stafford