headers
Dave Crocker | 15 Jan 2003 18:14

port number for smtp over ssl


Folks,

The 'alternate' port used for doing SMTP over SSL is 465. This appears
to be a well-established, de facto standard.

However it is not registered with IANA.  The official entry for the port
is:

    urd             465/tcp    URL Rendesvous Directory for SSM

Given the importantce of secure SMTP posting across the net, it strikes
me that this documentation anomoly should get fixed, so that
administrators have the usual, official site to go to, to find out
correct port number assignments.

Thoughts?

d/
--

-- 
 Dave Crocker <mailto:dhc <at> dcrocker.net>
 Tribalwise <http://www.tribalwise.com>
Permalink | Reply | 7 comments |
headers
Keith Moore | 15 Jan 2003 18:47
Picon

Re: port number for smtp over ssl


On Wed, 15 Jan 2003 09:14:18 -0800
Dave Crocker <dhc <at> dcrocker.net> wrote:

> 
> Folks,
> 
> The 'alternate' port used for doing SMTP over SSL is 465. This appears
> to be a well-established, de facto standard.

Alternate port numbers are a bad idea, especially when implementations
try to do opportunistic encryption (as many do) by switching from one
port to another.  There is an SMTP extension allowing negotiation of
TLS-over-SMTP in RFC 3207.  This is what implementations should be
using.

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001
Permalink | Reply | 0 comments |
headers
ned+ietf-smtp | 15 Jan 2003 18:44

Re: port number for smtp over ssl


> The 'alternate' port used for doing SMTP over SSL is 465. This appears
> to be a well-established, de facto standard.

Only in a very limited sense. I see port 465 used for SMTP submission; the
SMTP server and port you submit to is, after all, not something that
changes very often so it is reasonable to put this in a client's configuration.

SMTP relay is another matter. Trying another port before falling back to
port 25 is not something SMTP relay clients can usually afford to do.

The correct way to use TLS/SSL with SMTP is through the use of the STARTTLS
SMTP extension defined in RFC 3207. This is widely implemented and used for
both submission and relay; although the latter unfortunately suffers somewhat
due to the presence of systems that advertise the extension but then fail to
successfully negotiate when someone tries to use it.

Finally, the use of a second port for TLS/SSL is actively discouraged as it
opens up a number of security issues of its own.

> However it is not registered with IANA.  The official entry for the port
> is:

>     urd             465/tcp    URL Rendesvous Directory for SSM

> Given the importantce of secure SMTP posting across the net, it strikes
> me that this documentation anomoly should get fixed, so that
> administrators have the usual, official site to go to, to find out
> correct port number assignments.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Matti Aarnio | 15 Jan 2003 19:02
Picon
Picon
Favicon

Re: port number for smtp over ssl


On Wed, Jan 15, 2003 at 09:14:18AM -0800, Dave Crocker wrote:
> Folks,
> 
> The 'alternate' port used for doing SMTP over SSL is 465. This appears
> to be a well-established, de facto standard.

  Well, yes and no..  It used to be established before  STARTTLS
  command was specified, and like with  IMAPS-port is being superceded
  with IMAP protocol's  STARTTLS extension, same fits also SMTP.

  I don't remember the source, but I have written into  ZMailer's smtp
  server subsystem configuration manual:

       PARAM listen-ssmtp
              Listen  on  port  TCP/465,  which   is   deprecated
              SSL/SMTP listener port.

       PARAM outlook-tls-bug
              Microsoft  does  it again...  If TLS is set at Out-
              look, and server port is not  25,  it  bloody  well
              seems to expect that the server starts in TLS hand-
              shake mode.

              This implements a 2 second startup  delay  in  case
              the port is some other than 25, and if some byte is
              received from client during that time, and it  hap-
              pens to be 0x80, then this server will initiate TLS
              negotiation.   If  nothing  happens  (well-behaving
              client), normal SMTP greeting is presented.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 15 Jan 2003 23:25

Re: port number for smtp over ssl


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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeff Stephenson | 16 Jan 2003 01:22
Picon

RE: port number for smtp over ssl


> From: Dave Crocker [mailto:dhc <at> dcrocker.net] 
> Sent: Wednesday, January 15, 2003 2:25 PM
> 
> ned> The correct way to use TLS/SSL with SMTP is through the 
> use of the 
> ned> STARTTLS 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.

I seem to recall that port 465 used to be registered for SMTP over SSL
before RFC 3207, but that once the STARTTLS ID was moved to RFC status
the WG made a request to IANA to have that port deregistered.  The idea
was to emphasize that the proper way to provide a secure layer was
(Continue reading)

Permalink | Reply | 8 comments |
headers
ned+ietf-smtp | 16 Jan 2003 01:32

Re: port number for smtp over ssl


> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
ned+ietf-smtp | 16 Jan 2003 01:56

RE: port number for smtp over ssl


> > From: Dave Crocker [mailto:dhc <at> dcrocker.net]
> > Sent: Wednesday, January 15, 2003 2:25 PM
> >
> > ned> The correct way to use TLS/SSL with SMTP is through the
> > use of the
> > ned> STARTTLS 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.

> I seem to recall that port 465 used to be registered for SMTP over SSL
> before RFC 3207, but that once the STARTTLS ID was moved to RFC status
> the WG made a request to IANA to have that port deregistered.  The idea
> was to emphasize that the proper way to provide a secure layer was
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dave Crocker | 16 Jan 2003 02:17

Re: port number for smtp over ssl


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.

>> 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
ned+ietf-smtp | 16 Jan 2003 09:25

Re: port number for smtp over ssl


> 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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane