Post by Greg A. WoodsThis might seem odd to some for me to say, but I really don't understand
why you're trying so vainly to be such a stickler for the so-called
"standards" in this case.
IANA's "port numbers" are more a Best Common Practice than a literal
standard. You're free to provide whatever service you so wish to
provide on any port you please. The published port assignments,
especially those in the 0-1023 range, i.e. the Well Known Ports, are
simply a guideline to help you to inter-operate with "unknown callers".
If your users are all known to you then they will all know which port to
use through prior arrangement. By definition one could conclude that
all users of a service requiring authentication and authorization are in
fact "known callers".
But it's more than just BCP for me (or you). It's a knowledge of BCP
for others as that might impact me (or you). For example, it means it
is unlikely that a reputable manufacturer will implement or deploy
(MSFT doesn't fit that for me).
Post by Greg A. WoodsFinally, since running SMTP through SSL was previously defined and
assigned a port number, then supporting legacy applications using this
protocol and port number is well within the boundaries of valid use.
That can justify it ... on a "phasing it out" basis.
I did actually turn 465 on to see if it worked. It did. Then I
commented it out. So I have "phased it out".
Post by Greg A. WoodsThe only really valid reason for _not_ providing SMTP through SSL, (aka
"ssmtp" or "smtps") on port 465 would be if you really had to support
the newly assigned "urd" (URL Rendesvous Directory for SSM) protocol for
_unknown_ callers also on port 465, and also on the exact same IP
address (or perhaps through the same NAT-based firewall if for some
stupid reason you've put your servers behind a NAT on some non-public IP
addresses).
I disagree. If port 465 becomes regularly used for a non-standard
purpose, people will begin to use it and expect it to be there. If
later on (for example a few years later), the official use for port
465 (urd) needs to be deployed, then a conflict suddenly exists. And
it might not be noticed in the planning phase because it might be
different teams using these things. It may become necessary to
abruptly shut off SMTPS on port 465 because of that (if there's no
easy way to make these different services coexist, which is not a
known certainty ahead of time).
Post by Greg A. WoodsPost by Phil HowardBut IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993
and 995), since a standard does exist (but I'm not telling anyone but
the other admin about it ... I'm promoting STARTTLS/STLS for
everything).
Are you sure your soap-box is the most secure one to promote?
I'm not on a soap box. It has been for a long term practice (for me)
to stick with standards unless I have a compelling need to deviate
(and believe me, I have many times needed to do that). At this time,
there is no specific need for SMTPS that cannot be filled by
{SMTP|Submission}+STARTTLS on 25|587 ... so ... at this time, there is
no compelling need for SMTPS that would have me consider how to "go
beyond" the standards. If it were a standard port, I would have fired
it up just to see if it needed to be used. What I did instead is
configured it as commented out, and will address any complaints
when/if they arrive (none to date ... 2 days into activation).
Post by Greg A. WoodsThe only real reason why SMTPS was "deprecated" was solely because of
politics. There was never any technical reason to deprecate SMTPS. It
was done as a result of someone having the fool-headed idea to think
that since it is _possible_ to initiate TLS from within the SMTP
transaction, then that should be the _only_ way to do it.
I'm not disagreeing with this. I think there should be an SMTPS.
Post by Greg A. WoodsNote that the original RFC 2487 even goes so far to suggest that
STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and
suggesting only a relatively ludicrous work-around). That RFC's author
gave the following contradictory excuse to IANA via e-mail in order to
cause the unilateral deprecation of SMTPS: "The email community has
reached rough concensus that widespread use of such a port will be
harmful to the performance, interoperability and security of SMTP."
Correct me if I am wrong (as I have heard this only 2nd hand), but my
understanding is that the intended use of SMTPS included MX purposes
(albeit wrapped in TLS).
Post by Greg A. WoodsNote there are even further MitM weaknesses in the original STARTTLS
protocol as well, all of which are avoided entirely by SMTPS.
Indeed, SMTPS threatens the success of STARTTLS because it is more
secure than using STARTTLS.
I don't disagree. If you need more people to champion the cause to
bring back SMTPS, let me know.
Post by Greg A. WoodsSo, one must ask one's self if STARTTLS was truly the best option for
SMTP, when why was it not so for every other protocol that could have
been similarly extended from within, including HTTP, IMAP, NNTP, FTP,
TELNET, IRC, and so on? The whole idea of trying to support TLS as an
add-on or extension to an existing protocol and to do so by using an
"optional" in-band request, is entirely antithetical to the ideal of
using TLS to protect the _entire_ encapsulated protocol.
Perhaps (I'm speculating), the nature of the protocols (including a
_narrow_ view of SMTP) as seen by some suggested that SMTP didn't need
the level of authentication the others did. I don't agree, but just
trying to see how the process might have come to the conclusion it
did. I was never involved in that process, even as an observer (I
wish I had been).
Post by Greg A. WoodsFinally remember that the deprecation of SMTPS was never done officially
or via any published standard. It was done simply by fiat when Paul
Hoffman asked IANA on his own to deprecate SMTPS prior to the final
publication of his STARTTLS RFC 2487. The language suggesting the
deprecation of SMTPS and reassignment of port 465 was then removed from
the STARTTLS draft and there was no opportunity for further discussion
through the RFC process.
There are a number of unassigned ports still in the range less than
1024. Do you feel it is worth the cause to bring back SMTPS at least
on another port number? I'm curious why it is that port 465 got
assigned to another service rather than one of the still unassigned
ports?
FYI, I do run SSH on various unassigned ports. That's because I don't
want the log floods I'd get if I had SSH facing the wild on port 22
(I've had on a couple days over a million dictionary attempts to root,
all unsuccessful, but occupying 99% of the log file space).
Yes. And I hate it. But I have to live with it and work around it.