From: Victor Duchovni on
On Fri, May 21, 2010 at 04:43:15PM -0400, Phil Howard wrote:

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

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

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

From: mouss on
Phil Howard a �crit :
> 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).

From: Phil Howard on
On Fri, May 21, 2010 at 18:03, mouss <mouss(a)ml.netoyen.net> wrote:
> 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.

From: Charles Marcus on
On 2010-05-24 9:33 AM, Phil Howard wrote:
> 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... ;)

--

Best regards,

Charles

From: mouss on
Phil Howard a �crit :
> [snip]
> 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?


As far as I know, it was never standardised.

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

>
> There are "wrapper mode ssl" ports for a few other services. Probably
> most known is https (443).

it started with that.

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

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

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

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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Multiple SMTPD, different SSL certs
Next: SRS implementation