Subject: RE: port number for smtp over ssl
From: [email-masked]
To: Pete Resnick <[email-masked]>
Cc: [email-masked], Jeff Stephenson <[email-masked]>, [email-masked]
Date: Thu, 16 Jan 2003 16:04:25 -0800 (PST)
List-Id: <ietf-smtp.imc.org>

> OK, so we established back at the beginning of this that we're only
> really concerned with people using 465 for SSL submission. Let's see
> how this play's out with Jeff's and Ned's most recent comments:

> On 1/16/03 at 11:30 AM -0800, [email-masked] wrote:

> >>Registering SMTPS again would only provide short-term relief
> >>(providers would soon block it as well) at the cost of creating
> >>standards confusion.
> >
> >Exactly right. SMTPS really is a solution to a very different
> >problem, one that cannot be leveraged as a solution to the problem
> >you describe except in, as you say, the short term.

> Actually, I think this might argue *in favor* of registering 465.
> Right now, 465 is used for unauthenticated encrypted submission. We
> don't want people using unauthenticated encrypted submission; we want
> them using authenticated submission, either on port 25 or on port
> 587. As a matter of fact, open 465 ports mean that, for example,
> spammers will have a new way to get through firewalls and spam. (And
> I would not be at all shocked if there were installed SMTP
> implementations with SSL-SMTP listening on port 465 without their ops
> knowing about it.) Maybe 465 should be registered to, in effect,
> encourage people to make sure it is turned off.

Let me be clear here: I am not opposed to providing information about the use
of this port for SMTPS.

However, as Keith points out, registration by itself doesn't provide much
information. And because of this the registration can end up being in effect an
invitation to the uninformed to be used incorrectly.

> I think it's rather ostrich like to say, "No, no, no, there's nothing
> at all on port 465 that looks like SMTP; we're not registering
> anything there and we're not going to talk about it." I think
> documenting the current state of affairs (people are submitting mail
> encrypted but unauthenticated on port 465) and labelling it "Worst
> Current Practice" has some hope of cutting down on it getting more
> widespread and acceptable.

A document describing the practice as a bad idea is another matter. I think
such a document would be a fine thing to have.

Unfortunately the current state of affairs in the IETF is that such documents
are incredibly difficult to get through the process. The line that has to be
tread between not criticizing the two port practice in general (it arguably
makes sense in some cases) while not in any way supporting the use of the two
port approach for SMTP specifically ends up being a lot thinner than you'd
think. The underlying problem I've encountered in such cases is that quite a
few people who review such things tend to see them more in light of their own
prejudices than in light of what the document actually says.

John Klensin had quite a bit to say about this meta-issue in another context on
the main IETF list; I think a lot of what he said was very much on 
target. And the fact that this is a sad state of affairs doesn't change it.

				Ned

Date: Thu, 16 Jan 2003 18:45:43 -0500
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

> >>Registering SMTPS again would only provide short-term relief 
> >>(providers would soon block it as well) at the cost of creating 
> >>standards confusion.
> >
> >Exactly right. SMTPS really is a solution to a very different 
> >problem, one that cannot be leveraged as a solution to the problem 
> >you describe except in, as you say, the short term.
> 
> Actually, I think this might argue *in favor* of registering 465. 
> Right now, 465 is used for unauthenticated encrypted submission. We 
> don't want people using unauthenticated encrypted submission; we want 
> them using authenticated submission, either on port 25 or on port 
> 587. As a matter of fact, open 465 ports mean that, for example, 
> spammers will have a new way to get through firewalls and spam. (And 
> I would not be at all shocked if there were installed SMTP 
> implementations with SSL-SMTP listening on port 465 without their ops 
> knowing about it.) Maybe 465 should be registered to, in effect, 
> encourage people to make sure it is turned off.

the problem is that port registration conveys so little information, 
and it invites people to make incorrect inferences.

maybe what we need is an RFC titled

"use of TLS or SSL with separate ports considered harmful"

or

"use of port 465 with SMTP and SSL considered harmful"

Keith

Date: Thu, 16 Jan 2003 17:32:59 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: RE: port number for smtp over ssl
Cc: Jeff Stephenson <[email-masked]>, [email-masked]
Sender: [email-masked]

OK, so we established back at the beginning of this that we're only 
really concerned with people using 465 for SSL submission. Let's see 
how this play's out with Jeff's and Ned's most recent comments:

On 1/16/03 at 11:30 AM -0800, [email-masked] wrote:

>>Registering SMTPS again would only provide short-term relief 
>>(providers would soon block it as well) at the cost of creating 
>>standards confusion.
>
>Exactly right. SMTPS really is a solution to a very different 
>problem, one that cannot be leveraged as a solution to the problem 
>you describe except in, as you say, the short term.

Actually, I think this might argue *in favor* of registering 465. 
Right now, 465 is used for unauthenticated encrypted submission. We 
don't want people using unauthenticated encrypted submission; we want 
them using authenticated submission, either on port 25 or on port 
587. As a matter of fact, open 465 ports mean that, for example, 
spammers will have a new way to get through firewalls and spam. (And 
I would not be at all shocked if there were installed SMTP 
implementations with SSL-SMTP listening on port 465 without their ops 
knowing about it.) Maybe 465 should be registered to, in effect, 
encourage people to make sure it is turned off.

I think it's rather ostrich like to say, "No, no, no, there's nothing 
at all on port 465 that looks like SMTP; we're not registering 
anything there and we're not going to talk about it." I think 
documenting the current state of affairs (people are submitting mail 
encrypted but unauthenticated on port 465) and labelling it "Worst 
Current Practice" has some hope of cutting down on it getting more 
widespread and acceptable.

>>How we fix this is a really good question...
>
>IMO the only way to fix it is to get the message out. We have the 
>solutions; they just need to be used. RIght now the problem is less 
>one of providers blocking SMTP submit than it is of providers not 
>offering submission services at all.

I don't see how that is mutually exclusive of registration.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 16 Jan 2003 11:30:12 -0800 (PST)
From: [email-masked]
Subject: RE: port number for smtp over ssl
To: Jeff Stephenson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, January 16, 2003 8:20 AM

> > > At a minimum, there needs to be some dialogue between the ops
> > > community and the email community to resolve this.
> >
> > > How should we proceed?
> >
> > The email community has already specified a solution to this
> > problem. All you have to do is use it. I'm really not sure
> > what else needs to be said.

> The problem is that until the *ops* community changes its approach, the
> poor end user is stuck.  As Dave points out, most ISPs now seem to block
> port 25 (except to their own servers), presumably as an "anti-spam"
> measure.  In reality, I think, they don't actually care about spam, but
> want to make sure that one of their assigned IP addresses doesn't appear
> in spam and thus end up in a RBL.

RBL lists aren't the problem so much as DULs.

> If you're only using a provider as
> dial-up Internet access you don't have a mail account with the provider
> and thus can't use their SMTP server; if they block port 25 you can't
> use any other server.  You're stuck.

Yes. Regardless of why port 25 is blocked, it does get blocked. This is one of
the reasons why SMTP submission as an SMTP extension on port 25 didn't happen.

> Registering SMTPS again would only provide short-term relief (providers
> would soon block it as well) at the cost of creating standards
> confusion.

Exactly right. SMTPS really is a solution to a very different problem, one
that cannot be leveraged as a solution to the problem you describe except in,
as you say, the short term.

> The SMTP submission port faces the same problem - the moment
> spammers start using it, the providers will block it.

I don't think this follows. Port 25 offers access to email everywhere, so
spammers willing to send their stuff directly can use to reach whoever they
please. SMTP submit, OTOH, only offers access to the system where you have  an
account.

I suppose it is possible for a spammer to set up an account with provider A and
use an account on provider B to access provider A through SMTP submit, but this
really is a much more complex proposition than what is often the case, and
what, I think, operations folks are attempting to prevent when they block port
25.

> I think the
> problem really comes from brain-dead maintenance and use of RBLs - no
> ISP wants one of their assigned IPs appearing as the originating address
> of spam, so they'll always block any mail submission mechanism that
> isn't to one of their own servers.

I agree, modulo the sort of list you're talking about.

> How we fix this is a really good question...

IMO the only way to fix it is to get the message out. We have the solutions;
they just need to be used. RIght now the problem is less one of providers
blocking SMTP submit than it is of providers not offering submission
services at all.

				Ned

Date: Thu, 16 Jan 2003 13:20:09 -0600
From: Chip Rosenthal <[email-masked]>
To: [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

On Thu, Jan 16, 2003 at 10:41:00AM -0800, Jeff Stephenson wrote:
> The SMTP submission port faces the same problem - the moment
> spammers start using it, the providers will block it.

Except it's unlikely spammers are going to use it.  Typically when an
organization is smart enough to setup port 587 (submission), they are
clueful enough to do so without creating a spam relay vulnerability.

Remember, the port 25 relay vulnerability persists due to either:
1) crappy old software the admin is too lazy to upgrade, 2) terminal
cluelessness, or 3) your name is John Gilmore. :-)

> How we fix this is a really good question...

I believe you are projecting a problem that does not nor will not
exist.

-- 
Chip Rosenthal * [email-masked] * http://www.unicom.com/
"Why look back in anguish when we can look forward to the future
with cynicism?" * http://www.unicom.com/chrome/a/000029.html

Date: Thu, 16 Jan 2003 10:48:19 -0800 (PST)
From: [email-masked]
Subject: Re: port number for smtp over ssl
To: [email-masked]
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Thu, 16 Jan 2003 12:12:11 EST, Keith Moore said:

> > 465 is intended for message submissions.  because it is a new port,
> > it's reasonable to require authentication.  and because authentication is
> > required it's far less likely to be used as a means of relaying mail from
> > unauthorized parties.  also, having a separate port for message submission
> > provides an opportunity to provide additional processing that is appropriate at
> > message submission  (like rewriting message headers to add missing domains,
> > dates, etc., and/or rejecting messages which aren't perfectly formatted) but
> > not appropriate for mail relays.

I think Keith misspoke. I believe he intended to say 587, not 465.

> And here I thought we already had 587 for that....

> I've finally gotten enough caffeine, and it certainly seems like what this is
> really advocating is "465 for those vendors too stupid to implement STARTTLS
> on 587"?

Or SASL on 587. Or STARTTLS + SASL. Remember, authentication != TLS. And since
that is the case, one cannot assume a connection on 465 is authenticated. Heck,
it may not even be encrypted or integrity checked. As such, if 465 were to be
widely adopted it could easily end up being used for unauthenticated relay,
which would put it in the same boat as port 25.

				Ned

Content-class: urn:content-classes:message
Subject: RE: port number for smtp over ssl
Date: Thu, 16 Jan 2003 10:41:00 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, January 16, 2003 8:20 AM

> > At a minimum, there needs to be some dialogue between the ops 
> > community and the email community to resolve this.
> 
> > How should we proceed?
> 
> The email community has already specified a solution to this 
> problem. All you have to do is use it. I'm really not sure 
> what else needs to be said.

The problem is that until the *ops* community changes its approach, the
poor end user is stuck.  As Dave points out, most ISPs now seem to block
port 25 (except to their own servers), presumably as an "anti-spam"
measure.  In reality, I think, they don't actually care about spam, but
want to make sure that one of their assigned IP addresses doesn't appear
in spam and thus end up in a RBL.  If you're only using a provider as
dial-up Internet access you don't have a mail account with the provider
and thus can't use their SMTP server; if they block port 25 you can't
use any other server.  You're stuck.

Registering SMTPS again would only provide short-term relief (providers
would soon block it as well) at the cost of creating standards
confusion.  The SMTP submission port faces the same problem - the moment
spammers start using it, the providers will block it.  I think the
problem really comes from brain-dead maintenance and use of RBLs - no
ISP wants one of their assigned IPs appearing as the originating address
of spam, so they'll always block any mail submission mechanism that
isn't to one of their own servers.

How we fix this is a really good question...

-- jeff?????

Date: Thu, 16 Jan 2003 13:34:35 -0500
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

On Thu, 16 Jan 2003 12:21:39 -0500
[email-masked] wrote:

> On Thu, 16 Jan 2003 12:12:11 EST, Keith Moore said:
> 
> > 465 is intended for message submissions.  because it is a new port,
> > it's reasonable to require authentication.  and because authentication is
> > required it's far less likely to be used as a means of relaying mail from
> > unauthorized parties.  also, having a separate port for message submission
> > provides an opportunity to provide additional processing that is appropriate at
> > message submission  (like rewriting message headers to add missing domains,
> > dates, etc., and/or rejecting messages which aren't perfectly formatted) but
> > not appropriate for mail relays.
> 
> And here I thought we already had 587 for that....

sorry, that's what I meant.  I hadn't had enough caffeine when I wrote that.

I don't think we should legitimize 465.

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: port number for smtp over ssl 
From: [email-masked]
Date: Thu, 16 Jan 2003 12:21:39 -0500
Sender: [email-masked]

--==_Exmh_683313496P
Content-Type: text/plain; charset=us-ascii

On Thu, 16 Jan 2003 12:12:11 EST, Keith Moore said:

> 465 is intended for message submissions.  because it is a new port,
> it's reasonable to require authentication.  and because authentication is
> required it's far less likely to be used as a means of relaying mail from
> unauthorized parties.  also, having a separate port for message submission
> provides an opportunity to provide additional processing that is appropriate at
> message submission  (like rewriting message headers to add missing domains,
> dates, etc., and/or rejecting messages which aren't perfectly formatted) but
> not appropriate for mail relays.

And here I thought we already had 587 for that....

I've finally gotten enough caffeine, and it certainly seems like what this is
really advocating is "465 for those vendors too stupid to implement STARTTLS
on 587"?

--==_Exmh_683313496P
Content-Type: application/pgp-signature

--==_Exmh_683313496P--

Date: Thu, 16 Jan 2003 12:12:11 -0500
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

> If an ISP will firewall port 25 due to spamming concerns, what is
> stopping them from firewalling port 465 as well, besides lack of clue
> and/or lack of actual use of the port?

25 is used for message relaying in the absence of any explicit agreement
between the parties.  the ability to authenticate cannot be assumed.  therefore, if you block 25 on a certain path you need to have reasonable assurance that you won't be blocking mail that you want to send or receive.

465 is intended for message submissions.  because it is a new port,
it's reasonable to require authentication.  and because authentication is required it's far less likely to be used as a means of relaying mail from unauthorized parties.  also, having a separate port for message submission provides an opportunity to provide additional processing that is appropriate at message submission  (like rewriting message headers to add missing domains, dates, etc., and/or rejecting messages which aren't perfectly formatted) but not appropriate for mail relays.

of course a network can block 465 if it wants to do so.  but often it's useful for a network to block outgoing traffic on port 25 but unnecessary for that network to block traffic on port 465.

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001

To: Dave Crocker <[email-masked]>
Cc: [email-masked], Jeff Stephenson <[email-masked]>, [email-masked]
Subject: Re: port number for smtp over ssl 
From: [email-masked]
Date: Thu, 16 Jan 2003 11:54:54 -0500
Sender: [email-masked]

--==_Exmh_666999656P
Content-Type: text/plain; charset=us-ascii

On Thu, 16 Jan 2003 07:39:49 PST, Dave Crocker said:
> Hmmm. I focused so much on the existence of the practise that I probably
> did not pursue a second point adequately:
> 
>    The views expressed on this list are directly in conflict with the
>    views expressed among the ops community about blocking outbound port
>    25 through firewalls.
> 
> This kills travellers. (And, no, simply using the "local" SMTP server is
> not viable, primarily for reasons of trust, but also some concern for
> reliability, given how differential ISP mail service is.)

While I sympathize with Dave's concerns here, and agree that trying to do
SMTP while roaming is a problem, there's something I'm failing to understand
here.

If an ISP will firewall port 25 due to spamming concerns, what is stopping
them from firewalling port 465 as well, besides lack of clue and/or lack of
actual use of the port?

We codify 465, spammers start using it, ISPs block it, game over.

Now, I suppose that we *COULD* say "but you should be using AUTH or similar",
so that it's not usable for open relaying/injection. But then the correct
answer is "Use STARTTLS and/or AUTH on 25 and 587".

Are there any scenarios that are *NOT* addressed with the proper combination
of STARTTLS and AUTH using port 25 for relay and 587 for initial submission?
And does the current use of port 465 solve the scenario in any fashion *OTHER*
than "it happens to work with some software currently"?

The mere fact that some sites deployed something else before the STARTTLS
got to RFC status doesn't mean it's a Good Idea - if it were, we'd have written
THAT up instead....

> At a minimum, there needs to be some dialogue between the ops community
> and the email community to resolve this.

This seems much more reasonable.  Encouraging the proper use of port 587 would
be more productive....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_666999656P
Content-Type: application/pgp-signature

--==_Exmh_666999656P--

Date: Thu, 16 Jan 2003 08:20:27 -0800 (PST)
From: [email-masked]
Subject: Re: port number for smtp over ssl
To: Dave Crocker <[email-masked]>
Cc: [email-masked], Jeff Stephenson <[email-masked]>, [email-masked]
Sender: [email-masked]

> ned+ietf-smtp,

> Wednesday, January 15, 2003, 4:56:57 PM, you wrote:
> > In any case, the situation is what it is, and I do not think the
> > continued registration of POPS and IMAPS should not be taken as a
> > rationale for also registering SMTPS.

> Hmmm. I focused so much on the existence of the practise that I probably
> did not pursue a second point adequately:

>    The views expressed on this list are directly in conflict with the
>    views expressed among the ops community about blocking outbound port
>    25 through firewalls.

> This kills travellers. (And, no, simply using the "local" SMTP server is
> not viable, primarily for reasons of trust, but also some concern for
> reliability, given how differential ISP mail service is.)

I again repeat that this is exactly the problem that SMTP submission on
port 587 is intended to solve. You're not supposed to be able to use
port 587 for submission without authenticating first. This means it should
be safe to allow access to it for travellers.

I note in passing that the same cannot be said for SMTPS; allowing access to it
is effectively the same as allowing access to port 25 insofar as authentication
is concerned. So if the practice of using SMTPS truly became commonplace the
ops community would end up treating it in the same way as port 25.

> At a minimum, there needs to be some dialogue between the ops community
> and the email community to resolve this.

> How should we proceed?

The email community has already specified a solution to this problem. All you
have to do is use it. I'm really not sure what else needs to be said.

				Ned

Date: Thu, 16 Jan 2003 07:39:49 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: Jeff Stephenson <[email-masked]>, [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

ned+ietf-smtp,

Wednesday, January 15, 2003, 4:56:57 PM, you wrote:
> In any case, the situation is what it is, and I do not think the
> continued registration of POPS and IMAPS should not be taken as a
> rationale for also registering SMTPS.

Hmmm. I focused so much on the existence of the practise that I probably
did not pursue a second point adequately:

   The views expressed on this list are directly in conflict with the
   views expressed among the ops community about blocking outbound port
   25 through firewalls.

This kills travellers. (And, no, simply using the "local" SMTP server is
not viable, primarily for reasons of trust, but also some concern for
reliability, given how differential ISP mail service is.)

At a minimum, there needs to be some dialogue between the ops community
and the email community to resolve this.

How should we proceed?

d/
-- 
 Dave <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850

Date: Thu, 16 Jan 2003 00:25:37 -0800 (PST)
From: [email-masked]
Subject: Re: port number for smtp over ssl
To: Dave Crocker <[email-masked]>
Cc: [email-masked], Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> 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

Date: Wed, 15 Jan 2003 17:17:12 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

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.

Ned, this is not a negotiation.  I cited prevalent, existing,
well-documented practise.

d/
-- 
 Dave <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850

Date: Wed, 15 Jan 2003 16:56:57 -0800 (PST)
From: [email-masked]
Subject: RE: port number for smtp over ssl
To: Jeff Stephenson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > From: Dave Crocker [mailto:[email-masked]]
> > 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
> through STARTTLS.  I don't think we should back off that, regardless of
> de facto usage.

Hmm. You could be right -- I may not remember the history correctly. In any
case, the situation is what it is, and I do not think the continued
registration of POPS and IMAPS should not be taken as a rationale for also
registering SMTPS.

				Ned

Date: Wed, 15 Jan 2003 16:32:38 -0800 (PST)
From: [email-masked]
Subject: Re: port number for smtp over ssl
To: Dave Crocker <[email-masked]>
Cc: [email-masked], Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

> 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

Content-class: urn:content-classes:message
Subject: RE: port number for smtp over ssl
Date: Wed, 15 Jan 2003 16:22:34 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> From: Dave Crocker [mailto:[email-masked]] 
> 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
through STARTTLS.  I don't think we should back off that, regardless of
de facto usage.

-- jeff

Date: Wed, 15 Jan 2003 14:25:11 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

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

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.

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.

ned> I'd much rather move towards use of RFC 3207 than give the two port
ned> approach any additional legitimacy.

Too late.

d/
-- 
 Dave <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850

Date: 	Wed, 15 Jan 2003 20:02:17 +0200
From: Matti Aarnio <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

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.

...
> Thoughts?
> d/
> -- 
>  Dave Crocker <mailto:[email-masked]>
>  Tribalwise <http://www.tribalwise.com>

-- 
/Matti Aarnio	<[email-masked]>

Date: Wed, 15 Jan 2003 09:44:35 -0800 (PST)
From: [email-masked]
Subject: Re: port number for smtp over ssl
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

> Thoughts?

I'd much rather move towards use of RFC 3207 than give the two port
approach any additional legitimacy.

				Ned

Date: Wed, 15 Jan 2003 12:47:13 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: port number for smtp over ssl
Sender: [email-masked]

On Wed, 15 Jan 2003 09:14:18 -0800
Dave Crocker <[email-masked]> 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

Date: Wed, 15 Jan 2003 09:14:18 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: TribalWise
To: [email-masked]
Subject: port number for smtp over ssl
Sender: [email-masked]

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:[email-masked]>
 Tribalwise <http://www.tribalwise.com>