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

[jlgaddis]

To add just a little more to your great summary or perhaps clarify a bit ...

MTA to MTA (mail server to mail server) traffic will use 25/TCP (with a very few "special case" exceptions).

MUAs (i.e. desktop clients) -- Outlook, Thunderbird, etc. -- should almost always use 587/TCP (the "submission" ports) and use authentication. This is almost certainly the case if your ISP is not also your e-mail provider.

ISPs will often allow their own users (or, more correctly, hosts on their own IP networks) to send mail through their own mail servers on 25/TCP without authentication, but not always. If not, use 587/TCP and authentication.

Many ISPs will block traffic destined for 25/TCP to hosts outside of their network, except from their own mail servers. In these cases, you'll need to either use your ISP's mail servers as relay hosts or send mail via port 587/TCP on your e-mail provider's mail servers (and you'll have to authenticate, of course).

Also, it is entirely possible that your ISP's "dynamic" IP addresses have been blacklisted by popular third party blacklists, e.g. the Spamhaus PBL [0] or Zen [1] lists (Zen incorporates the PBL and others into a single list). If the remote mail server you're attempting to connect to uses these RBLs, you'll be unable to send mail via that server, even if your ISP isn't blocking 25/TCP outbound (which is becoming more and more popular nowadays).

As latitude mentioned, the primary difference between 465/TCP (which, again, is deprecated but still fairly widely used) and 587/TCP is in the use of TLS. 587/TCP starts off as "plain text" and switches to "encrypted mode" upon the client's issuance of the "STARTTLS" command while with 465/TCP the entire conversation is encrypted (such as with HTTPS). Both will require authentication (unless, as mentioned above, you are using your ISP's own servers and they allow unauthenticated relaying from their own IP space) but encryption (TLS) is (usually) optional with 587/TCP.

For sake of completeness, on the "mail receiving" side, POP3 and IMAP operate similarly. The "regular" POP3 (110/TCP) and IMAP (143/TCP) ports often (but not always) support "STARTTLS" (converting the "plain text" connection to an "encrypted" one) while the POP3S (995/TCP) and IMAPS (993/TCP) ports are fully encrypted from start to finish (again, such as with HTTPS).

I run my own personal mail servers as well as those at my employer (an ISP) and the biggest (e-mail related) issue we seem to have is with "off-net" customers who are trying to send mail -- typically this is a business customer (or a business customer's employee) who sets up their mail client on a laptop while on our network (where authentication is optional) and then attempts to send mail via our server while outside of our network but is denied due to either lack of authentication or port 25/TCP being blocked. This is easily solved by reconfiguring the client to use SMTP authentication and/or 587/TCP.

If you're responsible for managing end users' mail clients, just set them up to use 587/TCP, STARTTLS, and authentication from the start and save yourself some trouble down the road.

[0]: http://www.spamhaus.org/pbl/ [1]: http://www.spamhaus.org/zen/

[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 <[e-mail]>; 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.