

What port should I use? - twakefield
http://blog.mailgun.com/25-465-587-what-port-should-i-use/

======
billyhoffman
It's nearly 2015, we are in a post-Snowden, and yet we are still considering
the design pattern of "start with untrusted/unencrypted connection, and then
just use an optional 'upgrade' command to make it encrypted/secure"
acceptable.

One Word: SSLStrip

We have had to completely overhaul HTTP/HTTPS because this "start insecure, go
to secure" just does not work. And even then, its been a series of hacks like
Strict Transport Security, preloading lists for HSTS into browsers, OSCP
Stapling, hard coding revoke lists, etc.

And now we need to go through all this pain again for mail?!?!

This is incredibly stupid and short sighted. Any network protocol that is
sending personal/private information, or sends authentication credentials,
needs to do so over an encrypted channel. New protocols get a single port,
encryption is required. Legacy protocols which do not have an encrypted
channel, like SMTP, POP, IMAP, FTP, HTTP, need a separate, dedicated port
number for the encrypted version.

~~~
jlgaddis
In reality, it doesn't really matter much if TLS is used. Most MTAs will use
TLS by default when it is available (i.e. if it sees the "STARTTLS" verb in
the server's response) but (also by default) most won't attempt to validate
the SSL certificate provided by the server -- it can be self-signed, expired,
have a messed up certificate chain, or have a hostname mismatch and it will
still be accepted.

Proper validation can be enabled, of course, but it is typically not by
default. Of course, connecting over a "plain text" connection and then
"upgrading" to TLS has its own problems, as you pointed out. The most
significant is that a man-in-the-middle can simply filter out the
"250-STARTTLS" response from the server and the client will not attempt to use
encryption.

Unfortunately, in order to be RFC-compliant, an MTA cannot refuse to transfer
mail just because encryption (TLS) is not available.

I wholeheartedly agree that the e-mail protocols need updated -- or perhaps
even completely overhauled -- but I think it will be a long time before we see
that happen. Besides, even if new protocols were introduced tomorrow that
fixed all of this, it would be years before there was 100% adoption meaning
that we'd still have to support the current protocols until then.

I don't think you can say, fairly, that "this is incredibly stupid and short
sighted", though. I've been working professionally in I.T. for nearly 20 years
and SMTP was still around way way before that. The problems that we are
currently trying to solve simply did not exist then and almost certainly could
not have even been imagined that long ago (recall that RFC733 was authored in
November 1977 and RFC822 in August 1982).

Overall, SMTP has proven to be a fairly robust protocol but, as with anything,
it needs to adapt.

~~~
richardwhiuk
I think you are missing something here / a clarification.

Almost all mail clients (MUAs) I've seen will validate the TLS certificate.

Almost no mail servers (MTAs) will validate the TLS certificate. This is
because a) TLS isn't required, so a MITM could just strip the STARTTLS and
everything would need to continue to work, and b) It doesn't provide any
security.

TLS on the client is really securing the client credentials - not the email.
TLS on the server is per hop - not to the final destination, so it doesn't
protect a MITM attack.

If you want encrypted email, encrypt the email - don't use per hop encryption.

~~~
jlgaddis
> _Almost no mail servers (MTAs) will validate the TLS certificate._

Right. This is what I was referring to -- sorry, I could have been more clear.

------
latitude
I went through the whole stack of SMTP RFCs just this week and the takeaway
was this.

    
    
      TCP/25 if you are talking directly to the recipient's mail server,
      though it's discouraged if you are not a mail server yourself.
    
      TCP/587 - the same as above, but you are a mail client. In particular,
      it's the port for talking to "your" server, which you are tasking with
      relaying your email to the destination.
    
      * If you have username/password and want to "login", you want TCP/587.
    

On the other hand

    
    
      TCP/465 is a deprecated way of *securing* an SMTP connection.
    

It's just SMTP over TLS. Deprecated, discouraged, but still widely supported.
Functionally it can be either TCP/25 or TCP/587, depending on the setup at the
server end.

To secure 25/587, you first speak a bit of SMTP and then initiate the TLS
handshake with STARTTLS command. It's all actually really simple. _Much_
simpler than it seems when you are looking at the SMTP configuration UI in a
typical mail client :)

    
    
      --
    

(Re-edit) Nevermind. Let's keep it on-topic.

~~~
josho
And for those that still aren't familiar with TLS yet, think of it as simply
SSL but newer and better. So, even though SMTP starts unencrypted the STARTTLS
command initiates an encrypted session.

Most mail servers these days use TLS. So, there is a good chance that the
email you send with your confidential pricing lists is being sent encrypted
over the network. Unfortunately, there really isn't a good way to tell if that
happened (at best you can view the mail headers which some servers add headers
that show a TLS session was used between mail servers).

~~~
jlgaddis
Yeah, it's usually possible to tell just from the Received: headers.

For example, here's a (slightly censored) Received: header from a recent
e-mail received by my personal mail server:

    
    
      Received: from mail.foo.com (mail.foo.com [192.0.2.8])
      	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
      	(No client certificate requested)
      	by mail.bar.com (Postfix) with ESMTPS id MX8675309
      	for <jlgaddis@bar.com>; Mon, 20 Oct 2014 18:31:26 -0400 (EDT)
    

N.B.: "with ESMTPS".

I'm sure that others will correct me if I'm wrong (please do!) and this almost
certainly isn't foolproof (and I'm likely missing some and there are probably
exceptions as well), but just from my own observations: "ESMTP" refers to a
standard, unencrypted SMTP session (25/TCP), "ESMTPS" to an SMTP session where
_STARTTLS_ was used (25/TCP), "ASMTP" to an authenticated SMTP session where
"full" SSL/TLS was used (e.g. 465/TCP), and "ESMTPSA" to an authenticated SMTP
session where _STARTTLS_ was used.

Of course, you can't see these on any outgoing messages you send, only
incoming mail.

------
AlyssaRowan
This information is outdated. I quote here from the Using TLS in Applications
Working Group @ IETF, and their current draft
<[https://tools.ietf.org/html/draft-ietf-uta-tls-
attacks-04>](https://tools.ietf.org/html/draft-ietf-uta-tls-attacks-04>):

 _2.2. STARTTLS Command Injection Attack (CVE-2011-0411)_

    
    
       Similarly, there are attacks on the transition between unprotected
       and TLS-protected traffic.  A number of IETF application protocols
       have used an application-level command, usually STARTTLS, to upgrade
       a clear-text connection to use TLS.  Multiple implementations of
       STARTTLS had a flaw where an application-layer input buffer retained
       commands that were pipelined with the STARTTLS command, such that
       commands received prior to TLS negotiation are executed after TLS
       negotiation.  This problem is resolved by requiring the application-
       level command input buffer to be empty before negotiating TLS.  Note
       that this flaw lives in the application layer code and does not
       impact the TLS protocol directly.
    

SMTP and IMAP clients are affected by this, so best practice is to use their
encrypted ports. The use of STARTTLS-type techniques in future protocols is
deprecated due to the downgrade risk.

This of course has a bit of a problem as 465 was a private assignment, later
unfortunately reassigned to a Cisco protocol ("URD, a transitional technology
for IGMPv2/IGMPv3 & SSM"), and some routers could mess it up: "routers running
URD intercept all packets using port 465, regardless of destination". (You do
NOT, however, want to run URD, and if you ever see it on the internet… well,
think the whole thing through… if you have a Cisco, and find you have trouble
with 465 through it sometimes, and haven't turned on URD yourself, maybe get
your router forensically examined! <g>) That was on the whole not a good day
for the IETF/IANA.

I have limited time this morning: so here's the thread on UTA, see for
yourself. [https://www.ietf.org/mail-
archive/web/uta/current/msg00176.h...](https://www.ietf.org/mail-
archive/web/uta/current/msg00176.html) Long story short: using 465 is probably
OK, lots of people are doing it (I am). Maybe use another port, too, in case
you find a crazy misconfigured Cisco in-path, which complicates a dual-
assignment.

The advice in the article is wrong: you are _not_ in breach of an RFC if you
use port 465 - and you probably should, but there's no clear consensus or
resolution yet, so it may just get another port assignment (have I overlooked
that happening?).

------
rlpb
I think there's some history missing here.

"The RFC proposed a split of the traditional message submission and message
relay concept."

What this is misses is that the former specifications never accounted for
message submission in the first place. In the beginning, an MTA was installed
on every system, and "sendmail" was used to get email submitted into the MTA.
So there was no need for any other protocol to do this. But this only worked
on Unix.

When less-well Internet-connected hosts came along (eg. Windows), there was a
need to be able to submit mail to an MTA that was on a different host, since
one was no longer present locally. Lacking a specification for this, MUA
implementers just re-used (and overloaded) SMTP, by making the MUA pretend to
be an MTA.

This caused a mess because MTAs were liberal in what they accepted (Postel's
law), so they needed to tidy up badly formed submitted email such as fixing up
headers. But this broke MTA to MTA transmission because email flowing that way
ended up getting modified in unexpected ways, breaking old assumptions that
MTAs generally only added headers.

And finally, more recently, the spam problem meant that MTAs needed to
authenticate clients requesting relaying, since they didn't want to be
labelled as spam originators.

Proposing "a split of the traditional message submission and message relay
concept" was really just about sorting out the mess that we de-facto ended up
in.

------
josho
Since we are making progress to use secure mail transports, why are we not
seeing more use of S/MIME to secure the contents of the message? I set up
signing/encrypting on my mail clients, but have yet to see anyone, or any
company, use it.

~~~
ohyesyodo
Your last sentence is the answer to the first.

~~~
richardwhiuk
Plus the UX sucks and there is absolutely zero demand for it, except within an
organization.

Inside an organization, Exchange will perfectly happily do secure mail - it
works, it's nearly hassle free and novice users can do it.

Outside, you have a pile of Web of Trust problems which novice users don't
understand, and no pushing requirement.

~~~
josho
Zero demand? Wouldn't it be nice to send confidential email to business
partners and know that it's secure?

I am surprised that large businesses have tolerated this for so long. Maybe
SMIME isn't the answer, but it's surprising that we haven't seen some method
to guarantee secure delivery of mail between companies.

------
Animats
It's unlikely that anything anyone has to say using "Mailgun" needs much
security. It's basically for spamming, after all.

Yeah, I read the "transactional email" bullshit. That usually means spamming
to somebody who at some time in the past had some vague connection with you.
The fact that Mailgun touts their own API as a means to send more email fast
means they're marketing to spammers. Most businesses don't do enough
transactions per second to have this as a problem. Amazon and eBay do, and
they don't use Mailgun.

~~~
Xorlev
I send registration welcomes / email confirmations via Mailgun. Likewise, my
company does the same thing with a different provider. It's not spam, just
handy.

------
ciupicri
I had to use port 465 for the Outlook that comes with the Lumia phone.

~~~
ohyesyodo
Email configuration on Windows Phone is very confusing in my opinion.

------
gtrubetskoy
There is also 925.

