ned,
Wednesday, January 15, 2003, 9:44:35 AM, you wrote:
The 'alternate' port used for doing SMTP over SSL is 465. This appears
to be a well-established, de facto standard.
ned> Only in a very limited sense. I see port 465 used for SMTP submission; the
ned> SMTP server and port you submit to is, after all, not something that
ned> changes very often so it is reasonable to put this in a client's
configuration.
I'm easy. I'll settle for limiting the discussion to submission, since
it is that mode that motivates my attention to the topic.
When a client has a setting for SMTP over TLS, not using StartTLS, it
defaults to 465. When you look around the net for documentation about
using SMTP over TLS not on port 25, you will find port 465 cited. Some
clients make it easy to use a port other than 465. Some do not. Some
do not even permit configuring an alternative.
That is why I say well-established. This is not an academic issue for
me, since it has been problematic for some years in my direct use,
particularly when traveling and using a variety of clients.
ned> The correct way to use TLS/SSL with SMTP is through the use of the STARTTLS
ned> SMTP extension defined in RFC 3207.
1. common practise is common practise and we have registered a number of
protocols over TLS on alternate ports, including IMAP and POP. So why
not SMTP? Given that it is already established practise, the concern
over the supposed "damage" of "encouraging" its use does not apply.
2. There is a very basic difference between changing a protocol
implementation, versus changing a port number configuration. As a matter
of purity, I entirely agree that negotiation of a substrate mode is
better done inline. I think that promiscuous consumption of multiple
port numbers for the same application protocol is, at least, sloppy.
However there are some operational realities here and operationally, it
is much easier to get ops folks to run an existing server on a new port
than to run a revised server. Ops folks are typically conservative
about making software upgrades. and they should be.
3. Also from the ops world is an absolutely massive belief in that
community that it is ok to have firewalls block outgoing port 25, in the
name of spam control. Again, this is something has had direct negative
effect on me when traveling, so I've tried to lobby the point, to no
avail.
Now, faced with these kinds of realities, I find myself less concerned
with what one "ought" to do than with what works. Hence my initial
posting on this topic.
ned> I'd much rather move towards use of RFC 3207 than give the two port
ned> approach any additional legitimacy.
Too late.
d/
--
Dave <mailto:dhc(_at_)dcrocker(_dot_)net>
Brandenburg InternetWorking <http://www.brandenburg.com>
t +1.408.246.8253; f +1.408.850.1850