ned+ietf-smtp,
Wednesday, January 15, 2003, 4:32:38 PM, you wrote:
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.
ned+ietf-smtp> Um, it isn't "an existing server". You have to add TLS/SSL in
either case.
However a) it is a discrete package, and b) it, too, gets reused. The
modularity is a significant part of what appeals.
ned+ietf-smtp> Yes, I'm aware of the various TLS/SSL wrappers and such that
make it easy to
ned+ietf-smtp> put existing servers under TLS/SSL. I'm also aware of the
security problems
ned+ietf-smtp> this causes.
They aren't. If they should not be engaging in this practise, then the
IETF needs to offer guidance.
That would be nice, as would countless other guidance documents. However, since
nobody has stepped to write one...
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.
ned+ietf-smtp> Then why not use port 587? Separation of submission and relay
is why
ned+ietf-smtp> it was added.
Ned, this is not a negotiation. I cited prevalent, existing,
well-documented practise.
Whatever. I remain unconvinced that an attempt to register SMTPS is
appopriate. And I remain completely convinced that any attempt to do so will
encounter very strong and widespread resistance.
Ned