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.
This is simply a matter of timing, nothing more. The policy regarding two port
usage is relatively new. And as with most new policies, getting it applied
evening from the get-go is difficult. In this particular this led to POPS and
IMAPS being registered but not SMTPS.
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.
Um, it isn't "an existing server". You have to add TLS/SSL in either case.
Yes, I'm aware of the various TLS/SSL wrappers and such that make it easy to
put existing servers under TLS/SSL. I'm also aware of the security problems
this causes. And I'm also aware that of the various security vulnerabilities
that have shown up at the TLS/SSL layer which effectively mean you need to be
running a "new server" regardless of the approach you choose.
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.
Then why not use port 587? Separation of submission and relay is why
it was added.
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.
Well, since we're talking about what's practical, I'd have to say that I
think the registration of SMTPS at this is unlikely in the extreme
to happen, regrdless of my position on the matter.
Ned