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