which port to use for SSL/TLS?

[Phil Howard]

I'm trying to find out what port is to be used with "always on" SSL/TLS
(e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP
connection is made, which I understand smtpd_tls_wrappermode=yes will do),
and the RFCs are coming up empty. I thought it was 587. But RFC4409
doesn't say if this is, or is not, SSL/TLS. Some mail clients are using 465
by default, but that isn't even official for anything email related. Anyone
know where this port 465 came from? RFC4409 seems to just be about doing
authentication to allow submission (e.g. submission protocol, smtp with
authentication added). We definitely need to have a port running with
"always on" SSL/TLS so certain access rules can be enforced at firewalls
(that I seriously doubt can be easily made to verify that STARTTLS gets
used). In theory, this would be the same as if I used stunnel listening on
(probably) 587 and reconnecting back to [::1]:25 (aside from losing the
ability to do any connection peer IP address checks).

[Matt Hayes]

Post by Phil Howard
I'm trying to find out what port is to be used with "always on" SSL/TLS
(e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP
connection is made, which I understand smtpd_tls_wrappermode=yes will
do), and the RFCs are coming up empty. I thought it was 587. But
RFC4409 doesn't say if this is, or is not, SSL/TLS. Some mail clients
are using 465 by default, but that isn't even official for anything
email related. Anyone know where this port 465 came from? RFC4409
seems to just be about doing authentication to allow submission (e.g.
submission protocol, smtp with authentication added). We definitely
need to have a port running with "always on" SSL/TLS so certain access
rules can be enforced at firewalls (that I seriously doubt can be easily
made to verify that STARTTLS gets used). In theory, this would be the
same as if I used stunnel listening on (probably) 587 and reconnecting
back to [::1]:25 (aside from losing the ability to do any connection
peer IP address checks).

Phil,

Please respond here and not from your regular account.. I neglected to
hit reply to list!

Well, you can put SSL/TLS on any port really. Submission being 587,
pop3s being 995, smtps being 465.. which ports are you wanting SSL/TLS on?

-Matt

[Phil Howard]

Post by Matt Hayes

Post by Phil Howard
I'm trying to find out what port is to be used with "always on" SSL/TLS
(e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP
connection is made, which I understand smtpd_tls_wrappermode=yes will
do), and the RFCs are coming up empty. I thought it was 587. But
RFC4409 doesn't say if this is, or is not, SSL/TLS. Some mail clients
are using 465 by default, but that isn't even official for anything
email related. Anyone know where this port 465 came from? RFC4409
seems to just be about doing authentication to allow submission (e.g.
submission protocol, smtp with authentication added). We definitely
need to have a port running with "always on" SSL/TLS so certain access
rules can be enforced at firewalls (that I seriously doubt can be easily
made to verify that STARTTLS gets used). In theory, this would be the
same as if I used stunnel listening on (probably) 587 and reconnecting
back to [::1]:25 (aside from losing the ability to do any connection
peer IP address checks).

Well, you can put SSL/TLS on any port really. Submission being 587,
pop3s being 995, smtps being 465.. which ports are you wanting SSL/TLS on?

I want it on a non-conflicting port, or at least one I know I won't ever use
(which is pretty much the null set).

According to *ftp://ftp.iana.org/assignments/port-numbers* port 465 is
assigned to something else:

# Theodore Ts'o <tytso*MIT.EDU>
urd 465/tcp URL Rendesvous Directory for SSM
igmpv3lite 465/udp IGMP over UDP for SSM

So that leaves me with:

# Jon Postel <postel*isi.edu>
24/tcp any private mail system
24/udp any private mail system
# Rick Adams <rick*UUNET.UU.NET>
smtp 25/tcp Simple Mail Transfer
smtp 25/udp Simple Mail Transfer

and:

submission 587/tcp Submission
submission 587/udp Submission

It does look like these:

# Vera Heinau <heinau*fu-berlin.de>
# Heiko Schlichting <heiko*fu-berlin.de>
telnets 992/tcp telnet protocol over TLS/SSL
telnets 992/udp telnet protocol over TLS/SSL
imaps 993/tcp imap4 protocol over TLS/SSL
imaps 993/udp imap4 protocol over TLS/SSL
ircs 994/tcp irc protocol over TLS/SSL
ircs 994/udp irc protocol over TLS/SSL
# Christopher Allen <ChristopherA*consensus.com>
pop3s 995/tcp pop3 protocol over TLS/SSL (was spop3)
pop3s 995/udp pop3 protocol over TLS/SSL (was spop3)

and a few others are clearly over TLS/SSL (and not just STARTTLS as an
option). Since port 25 must stay clear for acceptance of (insecure) mail
exchange, at least it could use STARTTLS (why not?). So I wasn't expecting
that submission (starting in the clear) would need a separate port (e.g. its
current standard of 587 ... and apparently not over TLS/SSL).

There seems to not be enough ports, if submission and/or STARTTLS are more
than just mere extensions to SMTP.

I guess I can use port 24?

[John Peach]

On Fri, 21 May 2010 15:26:33 -0400

Post by Phil Howard

Post by Matt Hayes

Post by Phil Howard
I'm trying to find out what port is to be used with "always on"
SSL/TLS (e.g. no STARTTLS command needed, it just does SSL/TLS
once the TCP connection is made, which I understand
smtpd_tls_wrappermode=yes will do), and the RFCs are coming up
empty. I thought it was 587. But RFC4409 doesn't say if this
is, or is not, SSL/TLS. Some mail clients are using 465 by
default, but that isn't even official for anything email
related. Anyone know where this port 465 came from? RFC4409
seems to just be about doing authentication to allow submission
(e.g. submission protocol, smtp with authentication added). We
definitely need to have a port running with "always on" SSL/TLS
so certain access rules can be enforced at firewalls (that I
seriously doubt can be easily made to verify that STARTTLS gets
used). In theory, this would be the same as if I used stunnel
listening on (probably) 587 and reconnecting back to [::1]:25
(aside from losing the ability to do any connection peer IP
address checks).

Well, you can put SSL/TLS on any port really. Submission being 587,
pop3s being 995, smtps being 465.. which ports are you wanting
SSL/TLS on?

I want it on a non-conflicting port, or at least one I know I won't
ever use (which is pretty much the null set).
According to *ftp://ftp.iana.org/assignments/port-numbers* port 465 is
# Theodore Ts'o <tytso*MIT.EDU>
urd 465/tcp URL Rendesvous Directory for SSM
igmpv3lite 465/udp IGMP over UDP for SSM
# Jon Postel <postel*isi.edu>
24/tcp any private mail system
24/udp any private mail system
# Rick Adams <rick*UUNET.UU.NET>
smtp 25/tcp Simple Mail Transfer
smtp 25/udp Simple Mail Transfer
submission 587/tcp Submission
submission 587/udp Submission
# Vera Heinau <heinau*fu-berlin.de>
# Heiko Schlichting <heiko*fu-berlin.de>
telnets 992/tcp telnet protocol over TLS/SSL
telnets 992/udp telnet protocol over TLS/SSL
imaps 993/tcp imap4 protocol over TLS/SSL
imaps 993/udp imap4 protocol over TLS/SSL
ircs 994/tcp irc protocol over TLS/SSL
ircs 994/udp irc protocol over TLS/SSL
# Christopher Allen
<ChristopherA*consensus.com> pop3s 995/tcp pop3 protocol
over TLS/SSL (was spop3) pop3s 995/udp pop3 protocol
over TLS/SSL (was spop3)
and a few others are clearly over TLS/SSL (and not just STARTTLS as an
option). Since port 25 must stay clear for acceptance of (insecure)
mail exchange, at least it could use STARTTLS (why not?). So I
wasn't expecting that submission (starting in the clear) would need a
separate port (e.g. its current standard of 587 ... and apparently
not over TLS/SSL).
There seems to not be enough ports, if submission and/or STARTTLS are
more than just mere extensions to SMTP.
I guess I can use port 24?

465 is for SMTP over SSL, which is deprecated.

[Phil Howard]

Post by John Peach
465 is for SMTP over SSL, which is deprecated.

What is deprecated? Using port 465? Or doing SMTP over SSL?
Unfortunately, I need to do the latter because of some network security and
access issues (and for like reason am doing IMAP over SSL on port 993 and
POP over SSL on port 995).

I could go ahead and do SMTP over SSL on port 465. Are you sure it won't
conflict with anything?

I'm doing optional STARTTLS (e.g. smtpd_tls_security_level=may and
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination)
on port 25.

What should I be doing on port 587?

[John Peach]

On Fri, 21 May 2010 15:35:55 -0400

Post by Phil Howard

Post by John Peach
465 is for SMTP over SSL, which is deprecated.

What is deprecated? Using port 465? Or doing SMTP over SSL?

SMTP over SSL

Post by Phil Howard
Unfortunately, I need to do the latter because of some network
security and access issues (and for like reason am doing IMAP over
SSL on port 993 and POP over SSL on port 995).
I could go ahead and do SMTP over SSL on port 465. Are you sure it
won't conflict with anything?

Just use port 465 if you want, but the submission port would make more
sense (587)

Post by Phil Howard
I'm doing optional STARTTLS (e.g. smtpd_tls_security_level=may and
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination)
on port 25.
What should I be doing on port 587?

Why not use "smtpd_tls_security_level = encrypt" on port 587?

http://www.postfix.org/TLS_README.html

[Wietse Venema]

Post by Phil Howard
I'm doing optional STARTTLS (e.g. smtpd_tls_security_level=may and
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination)
on port 25.
What should I be doing on port 587?

There's an example submission (port 587) service in recent master.cf
files:

#submission inet n - n - - smtpd
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

This example should also have

-o smtpd_sasl_tls_security_options=noanonymous

to allow plain-text passwords over TLS.

Wietse

[Phil Howard]

Post by John Peach
Why not use "smtpd_tls_security_level = encrypt" on port 587?

The remote site involved is tunneling these connections through something
like SSL, as far as I can tell. It works fine on port 993 for IMAP.

Why is SMTP over SSL depricated while others over SSL are not? Seems
inconsistent. OTOH, almost everything over TCP could have a use for an SSL
variant. But with no consistent way to do STARTTLS on all protocols, there
would be no clear way to engage it short of a designated port ... or
creating a new transport (e.g. something that could have been called TCPTLS
or such).

OK, I can do SMTP over TLS/SSL on port 465 (with a slight and unlikely risk
of usage collision). So what is port 587 for?

[Charles Marcus]

Post by Phil Howard
OK, I can do SMTP over TLS/SSL on port 465 (with a slight and unlikely
risk of usage collision). So what is port 587 for?

? This question has been answered at least 3 or 4 times in this very thread.

port 465 is for SMTP+SSL
this is DEPRECATED and has been for a long time

port 587 is for SMTP+STARTTLS
this is the designated SMTP SUBMISSION port

The submission port should always be used instead of port 465 unless you
must support older clients like Outlook Express and older versions of
Outlook that will only do SMTP+SSL over port 465.

[Phil Howard]

Post by Charles Marcus

Post by Phil Howard
OK, I can do SMTP over TLS/SSL on port 465 (with a slight and unlikely
risk of usage collision).  So what is port 587 for?

? This question has been answered at least 3 or 4 times in this very thread.
port 465 is for SMTP+SSL
this is DEPRECATED and has been for a long time
port 587 is for SMTP+STARTTLS
this is the designated SMTP SUBMISSION port
The submission port should always be used instead of port 465 unless you
must support older clients like Outlook Express and older versions of
Outlook that will only do SMTP+SSL over port 465.

I don't want to use port 465 because it isn't an unassigned port
(though even unassigned has a risk that it could become assigned later
on). But I need to use SMTP over TLS/SSL. It's not due to a client,
but instead, due to networking (tunnelled TCP connections). It seems
my choice is between using 465 or using some unassigned arbitrary
port. Maybe 60025?

[Victor Duchovni]

Post by Phil Howard

Post by Charles Marcus
port 465 is for SMTP+SSL
this is DEPRECATED and has been for a long time
port 587 is for SMTP+STARTTLS
this is the designated SMTP SUBMISSION port
The submission port should always be used instead of port 465 unless you
must support older clients like Outlook Express and older versions of
Outlook that will only do SMTP+SSL over port 465.

I don't want to use port 465 because it isn't an unassigned port
(though even unassigned has a risk that it could become assigned later
on).

You are making a mistake, "465" was once assigned to the deprecated
"smtps" service and remans widely used in that capacity.

Post by Phil Howard
But I need to use SMTP over TLS/SSL. It's not due to a client,
but instead, due to networking (tunnelled TCP connections). It seems
my choice is between using 465 or using some unassigned arbitrary
port. Maybe 60025?

Using ports in the "dynamic" range would be a really bad idea. Use
465.

[mouss]

Post by Phil Howard
I'm trying to find out what port is to be used with "always on" SSL/TLS
(e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP
connection is made, which I understand smtpd_tls_wrappermode=yes will
do), and the RFCs are coming up empty. I thought it was 587. But
RFC4409 doesn't say if this is, or is not, SSL/TLS. Some mail clients
are using 465 by default, but that isn't even official for anything
email related. Anyone know where this port 465 came from? RFC4409
seems to just be about doing authentication to allow submission (e.g.
submission protocol, smtp with authentication added). We definitely
need to have a port running with "always on" SSL/TLS so certain access
rules can be enforced at firewalls (that I seriously doubt can be easily
made to verify that STARTTLS gets used). In theory, this would be the
same as if I used stunnel listening on (probably) 587 and reconnecting
back to [::1]:25 (aside from losing the ability to do any connection
peer IP address checks).

if you mean "wrapper mode ssl" (aka smtps), then
$ grep smtps /etc/services
ssmtp 465/tcp smtps # SMTP over SSL

this is non standard. but it's used by outlook and by other "people".

in the old days, people kept adding new ports for SSL (http -> https,
ftp -> ftps, foo -> foos). while this was "simple", it creates its own
set of problems. so that approach was replaced by providing security
"inside" the protocol, instead of relying on an additional and
independent layer. so the standard for smtp is to use the STARTTLS
command. only use the old "smtps" as a compatibility mode (that you
discourage as much as you can).

[Phil Howard]

Post by mouss
if you mean "wrapper mode ssl" (aka smtps), then
$ grep smtps /etc/services
ssmtp           465/tcp         smtps           # SMTP over SSL
this is non standard. but it's used by outlook and by other "people".
in the old days, people kept adding new ports for SSL (http -> https,
ftp -> ftps, foo -> foos). while this was "simple", it creates its own
set of problems. so that approach was replaced by providing security
"inside" the protocol, instead of relying on an additional and
independent layer. so the standard for smtp is to use the STARTTLS
command. only use the old "smtps" as a compatibility mode (that you
discourage as much as you can).

Is it the case that 465 once was assigned as smtps and later retracted
and re-assigned differently? Or was it never official at all and the
/etc/services file you have isn't just an old one, but an unofficial
one? I get mine from IANA and 465 is assigned differently.

There are "wrapper mode ssl" ports for a few other services. Probably
most known is https (443). Others include nntps (563), ldaps (636),
telnets (992), pop3s (995). And imap seems to have 2 variants ...
imaps (993) and an apparently older depricated imap4-ssl (585) (this
is in the IANA copy). So are these protocols somehow different in
that they need a wrapper mode, even though, in theory, some form of
STARTTLS could work on at least some of them?

Personally, I think what should have been done was to create a whole
new transport protocol in peer with TCP, call it something that merges
TCP with TLS, assign it a new protocol number (like TCP has protocol 6
and SCTP has protocol 132), and define it to function like TCP for IP,
but everything that uses it is "wrapper mode" TLS. Of course, that
would have required a lot of development at the system level to get
going, whereas wrapper mode as it is done now is just an add-on in
user space.

[Charles Marcus]

Post by Phil Howard
Is it the case that 465 once was assigned as smtps and later retracted
and re-assigned differently? Or was it never official at all and the
/etc/services file you have isn't just an old one, but an unofficial
one? I get mine from IANA and 465 is assigned differently.

I think that yes, it was once officially assigned as such, but you are
worrying about nothing.

If you need wrapper-mode smtp over SSL, use port 465. Period. I promise
nothing will explode, nor will you be attacked by the green slime... ;)

[mouss]

This post might be inappropriate. Click to display it.

[Phil Howard]

Post by mouss
As far as I know, it was never standardised.

Good enough reason for me to not use it.

Post by mouss

Post by Phil Howard
I get mine from IANA and 465 is assigned differently.

what OS do you run? if smtps != 465 on your system, then the default
master.cf doesn't work for you, which means you have an odd system (and
not the opposite)...

Several. The current project is on Ubuntu 9.10. I may move it to
Slackware 13.1. Nothing odd about these or any others I have used. I
do update and upgrade where practical. I'm finding that with Ubuntu
that's not always so, beyond what they pre-package. But for the
/etc/services file, that's never been a problem to regularly get the
official one from IANA, which I have been doing for a couple decades.

Post by mouss
wrapper mode SSL != STARTTLS. the former means the SSL/TLS negociation
happens before anything else. This provides more "confidentiality" (with
https, a sniffer doesn't know where you're trying to go), but it also
creates problems (for example, you currently need one IP per https
server [until the extensions to workaround this are widely implemented]).

Even with STARTTLS (or STLS, or A STARTTLS, or whatever is used for
some protocol), you still need one IP per hostname identified
certificate, unless you have some means to select the host in advance
that is safe to do (not sure if that is possible).

Post by mouss
STARTTLS is enough, if you want control at app level. if you don't, then
use IPSec. There is no need to invent useless protocols (the more
protocols we have, the more opportunity for incompatibility, bugs,
vulnearbilities, ... etc).

It is hard for firewall level controls to force encryption, unless it
is known that a given port always does. So from that perspective,
wrapper mode TLS/SSL is easier, when using standard ports for that.
You (in the role of firewall admin) can, for example, allow port 443
and disallow port 80 to ensure everyone is using encryption. In the
case of ports using STARTTLS or the like, you need to do sniff into
the TCP stream layer and see if STARTTLS is really being done (or be
the server admin and force it there).

[Victor Duchovni]

Post by Phil Howard

Post by mouss
As far as I know, it was never standardised.

Good enough reason for me to not use it.

This is the de-facto standard port for the service. Shoot yourself in
the foot if you wish, but for the record anyone implementing SMTP over
SSL (rather STARTTLS over SMTP) should use port 465 for that service.

[Kris Deugau]

Post by Victor Duchovni

Post by Phil Howard

Post by mouss
As far as I know, it was never standardised.

Good enough reason for me to not use it.

This is the de-facto standard port for the service. Shoot yourself in
the foot if you wish, but for the record anyone implementing SMTP over
SSL (rather STARTTLS over SMTP) should use port 465 for that service.

Not to mention the fact that, IIRC, old versions of Outlook (and
possibly Outlook Express) that support SMTP over SSL *hardcode* port 465
- or at least bury any option to change it somewhere most people will
never find it. If you must support those clients, you must use that port.

-kgd

[Phil Howard]

Post by Victor Duchovni

Post by Phil Howard

Post by mouss
As far as I know, it was never standardised.

Good enough reason for me to not use it.

This is the de-facto standard port for the service. Shoot yourself in
the foot if you wish, but for the record anyone implementing SMTP over
SSL (rather STARTTLS over SMTP) should use port 465 for that service.

Not to mention the fact that, IIRC, old versions of Outlook (and possibly
Outlook Express) that support SMTP over SSL *hardcode* port 465 - or at
least bury any option to change it somewhere most people will never find it.
 If you must support those clients, you must use that port.

At this point I'm just not going to support SMTP wrapped/tunneled over
SSL/TLS ... on any port. But just in case something comes up where I
have to support it, I do have the config for it in comments with port
465. They won't get that until after they've heard "show me the RFC"
and "Microsoft doesn't follow real standards" a couple times.

But 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).

[mouss]

This post might be inappropriate. Click to display it.

[Greg A. Woods]

At Tue, 25 May 2010 16:00:36 -0400, Phil Howard <***@gmail.com> wrote:
Subject: Re: which port to use for SSL/TLS?

Post by Phil Howard
At this point I'm just not going to support SMTP wrapped/tunneled over
SSL/TLS ... on any port. But just in case something comes up where I
have to support it, I do have the config for it in comments with port
465. They won't get that until after they've heard "show me the RFC"
and "Microsoft doesn't follow real standards" a couple times.

This 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".

Finally, 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.

The 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).

Post by Phil Howard
But 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?

The 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.

Note 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."

Note 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.

So, 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.

Finally 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.

Politics.

[Phil Howard]

Post by Greg A. Woods
This 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. Woods
Finally, 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. Woods
The 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. Woods

Post by Phil Howard
But 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. Woods
The 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. Woods
Note 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. Woods
Note 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. Woods
So, 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. Woods
Finally 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).

Post by Greg A. Woods
Politics.

Yes. And I hate it. But I have to live with it and work around it.

[Victor Duchovni]

Post by Phil Howard
I'm not disagreeing with this. I think there should be an SMTPS.

Rhetorical question: How would a sending domain know that a particular
receiving domain supports SMTPS?

Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather
it is only alternative to to port 587+STARTTLS for submission servers.

This means that if we want to support (opportunistic) TLS for domain
to domain delivery, we need STARTTLS. And in fact opportunistic TLS
is now widely (though not universally) deployed in this context.

Given that SMTP + STARTTLS is available, there is little need for yet
another protocol for submission. So on the whole SMTPS would not solve
any issues that SMTP + STARTTLS does not handle adequately. Over and
out.

[Phil Howard]

On Fri, May 28, 2010 at 14:24, Victor Duchovni

Post by Victor Duchovni

I'm not disagreeing with this.  I think there should be an SMTPS.

Rhetorical question: How would a sending domain know that a particular
receiving domain supports SMTPS?

Try it an see. If it fails to connect or times out, and local policy
and/or message parameters allow this, fall back to SMTP. Specific
detail are probably subject to discussion and maybe standardization.

Post by Victor Duchovni
Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather
it is only alternative to to port 587+STARTTLS for submission servers.

I don't agree. But it could be argued that SMTP+STARTTLS is
sufficient for MX. I haven't done the analysis to know if the
exposure risks in STARTTLS apply to MX or not.

Post by Victor Duchovni
This means that if we want to support (opportunistic) TLS for domain
to domain delivery, we need STARTTLS. And in fact opportunistic TLS
is now widely (though not universally) deployed in this context.

And this goes back to the arguments for SMTPS. Is there any
definitive analysis that says that STARTTLS has risks for submission
and never can have any for MX?

Post by Victor Duchovni
Given that SMTP + STARTTLS is available, there is little need for yet
another protocol for submission. So on the whole SMTPS would not solve
any issues that SMTP + STARTTLS does not handle adequately. Over and
out.

I guess you need to argue that with Greg. He seems to be more of an
advocate for that than I do (I don't have the time to do the analysis
... though I do have the biased preference to simply move EVERYTHING
on TCP ... and even SCTP ... over to wrapped TLS).

[Victor Duchovni]

Post by Phil Howard
On Fri, May 28, 2010 at 14:24, Victor Duchovni

Post by Victor Duchovni

I'm not disagreeing with this. ?I think there should be an SMTPS.

Rhetorical question: How would a sending domain know that a particular
receiving domain supports SMTPS?

Try it an see. If it fails to connect or times out, and local policy
and/or message parameters allow this, fall back to SMTP. Specific
detail are probably subject to discussion and maybe standardization.

No. This is a really poor idea. You're not supposed to answer rhetorical
questions, you just risk looking a bit silly...

Post by Phil Howard

Post by Victor Duchovni
Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather
it is only alternative to to port 587+STARTTLS for submission servers.

I don't agree. But it could be argued that SMTP+STARTTLS is
sufficient for MX. I haven't done the analysis to know if the
exposure risks in STARTTLS apply to MX or not.

See above.

Post by Phil Howard
And this goes back to the arguments for SMTPS. Is there any
definitive analysis that says that STARTTLS has risks for submission
and never can have any for MX?

There is no fundamental need for a second protocol, but Postfix supports
it because legacy clients (that will over the next few years disappear,
since modern Outlook supports STARTTLS) don't support 587 + STARTTLS.

Post by Phil Howard
I guess you need to argue that with Greg. He seems to be more of an
advocate for that than I do (I don't have the time to do the analysis
... though I do have the biased preference to simply move EVERYTHING
on TCP ... and even SCTP ... over to wrapped TLS).

I don't get into arguments with Greg.

[Phil Howard]

On Fri, May 28, 2010 at 14:46, Victor Duchovni

Post by Victor Duchovni

Try it an see.  If it fails to connect or times out, and local policy
and/or message parameters allow this, fall back to SMTP.  Specific
detail are probably subject to discussion and maybe standardization.

No. This is a really poor idea. You're not supposed to answer rhetorical
questions, you just risk looking a bit silly...

Rhetorical questions that make no sense need to be refuted somehow.
What do you suggest as an alternative to just plain answering them
(for ones that are in the negative)?

Post by Victor Duchovni

I don't agree.  But it could be argued that SMTP+STARTTLS is
sufficient for MX.  I haven't done the analysis to know if the
exposure risks in STARTTLS apply to MX or not.

See above.

And see what Greg posted. Analysis would be going in depth on what
lots of people say, and examining their evidence where available.

Post by Victor Duchovni
I don't get into arguments with Greg.

Fine. Just understand there is more than one point of view.

[Charles Marcus]

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).

? That's what (something like) fail2ban is for...