7 ms·

What port should I use?

110 points by twakefield 12y ago

gtrubetskoy 12y ago
There is also 925.
latitude 12y ago
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 12y ago
  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 12y ago
    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.
- jlgaddis 12y ago
  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/ http://www.spamhaus.org/pbl/ [1]: http://www.spamhaus.org/zen/ http://www.spamhaus.org/zen/
ciupicri 12y ago
I had to use port 465 for the Outlook that comes with the Lumia phone.
- ohyesyodo 12y ago
  Email configuration on Windows Phone is very confusing in my opinion.
deleted 12y ago
[deleted]
josho 12y ago
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 12y ago
  Your last sentence is the answer to the first.
  - richardwhiuk 12y ago
    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 12y ago
      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.
billyhoffman 12y ago
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.
- huhtenberg 12y ago
  STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH without STARTTLS first. Clients won't send emails if they are set to use it and it's not supported. One can certainly misconfigure the hell out of mail server, but then no "secure from start" will stand a chance against these leet skills either. Besides, STARTTLS dates back to 2002, so not sure what's up with your "?!?!" and "now we need to ..." comments. Looks like a basic rant to me :-/
  - jlgaddis 12y ago
    With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).
  - rwg 12y ago
    I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
Animats 12y ago
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 12y ago
  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.
AlyssaRowan 12y ago
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.html https://www.ietf.org/mail-archive/web/uta/current/msg00176.h... 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 12y ago
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.

110 points by twakefield 12y ago

There is also 925.

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 12y ago
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 12y ago
  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.
jlgaddis 12y ago
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/ http://www.spamhaus.org/pbl/ [1]: http://www.spamhaus.org/zen/ http://www.spamhaus.org/zen/

ciupicri 12y ago

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

ohyesyodo 12y ago
Email configuration on Windows Phone is very confusing in my opinion.

deleted 12y ago

[deleted]

josho 12y ago

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 12y ago
Your last sentence is the answer to the first.
- richardwhiuk 12y ago
  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 12y ago
    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.

billyhoffman 12y ago

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.

huhtenberg 12y ago
STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH without STARTTLS first. Clients won't send emails if they are set to use it and it's not supported. One can certainly misconfigure the hell out of mail server, but then no "secure from start" will stand a chance against these leet skills either. Besides, STARTTLS dates back to 2002, so not sure what's up with your "?!?!" and "now we need to ..." comments. Looks like a basic rant to me :-/
- jlgaddis 12y ago
  With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).
- rwg 12y ago
  I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

Animats 12y ago

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 12y ago
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.

AlyssaRowan 12y ago

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.html https://www.ietf.org/mail-archive/web/uta/current/msg00176.h... 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 12y ago

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.