Hi, I’m trying to reset my email settings after updating the software - emails are not going out.
My SMTP server is yandex.com.tr; there are only 2 port choices (25 and 587) ; I need 465 and am not able to type 465 in the box.
Need urgent assistance please,
Thx
Unfortunately Manager does not support 465 due to the fact that additional libraries and coding would need to be installed into Manager. However it does look like Yandex supports Port 587
Hello,
My service provider only allows ports 465 for SSL/TLS and 26 for non SSL .
Any luck in getting this ?
No, nor is there any likelihood of it. First, I think you mean Port 25, not Port 26. There has never been a recognized SMTP Port 26, and Port 25 is often blocked for spam prevention. So it should only be used as a fallback.
Port 465 is no longer officially recognized by the Internet Assigned Numbers Authority (IANA) and has been reassigned for other uses. Unfortunately, some legacy systems still accept or even require it. Manager does not support it because it is out of date. So it is never going to be added back.
Port 587 is the currently accepted standard for TLS encrypted email. So unless you want to find another provider, you may not be able to send email from within Manager. In that case, you will have to generate PDFs and attach them through your regular email client.
I beg to differ there
https://clients.hostgeek.com.au/index.php/knowledgebase/21/What-Email-Settings-Do-I-Use.html
Also Telstra recommends port 465 over 587…
Also worth reading
https://www.bluehost.com/help/article/email-troubleshooting-change-smtp-port-from-25-to-26
@VACUUMDOG, when I wrote “recognized SMTP Port 26,” I meant recognized by IANA. The use of Port 26 has grown in popularity to some degree because so many ISPs block Port 25 due to spammers using it (because it is the default port).
Your links do not support your argument. The first says that Port 26 should only be used if the recommended setup (which is itself the deprecated Port 465) does not work. The second is another example of what I already described: legacy systems using a deprecated port assignment. The third does not indicate Port 26 is sanctioned in any way, but only provides workaround instructions on how to convert to Port 26 in case Port 25 is blocked.
The fact remains, Manager is sticking to officially recognized SMTP ports as assigned by IANA. Occasionally (a few times per year over the past several years) a user experiences a limitation because their existing ISP will not allow Ports 25 or 587. But imagine how many problems there would be worldwide if the program supported unassigned ports.
I wasn’t arguing, but on ports 465 and 587 (from IANA)
submissions 465 tcp Message Submission over TLS protocol
submission 587 tcp Message Submission
So port 465 is for TLS protocol.?.?
And from the Hostgeek link you will see that it does not support Managers settings.
We are really getting down into the weeds here. But here are excerpts from RFC8314 of the Internet Engineering Task Force. The quote describes why Port 465 was deprecated and how/why it has been provisionally resurrected because of widespread established usage:
7.3. Submissions Port Registration
IANA has assigned an alternate usage of TCP port 465 in addition to the current assignment …. This is a one-time procedural exception to the rules in [RFC6335]. This requires explicit IESG approval and does not set a precedent.
Note: Since the purpose of this alternate usage assignment is to align with widespread existing practice and there is no known usage of UDP port 465 for Message Submission over TLS, IANA has not assigned an alternate usage of UDP port 465. Historically, port 465 was briefly registered as the “smtps” port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked [emphasis added] and was subsequently reassigned to a different service. In hindsight, the “smtps” registration should have been renamed or reserved rather than revoked. Unfortunately, some widely deployed mail software interpreted “smtps” as “submissions” [RFC6409] and used that port for email submission by default when an end user requested security during account setup. If a new port is assigned for the submissions service, either (a) email software will continue with unregistered use of port 465 (leaving the port registry inaccurate … and wasting a well-known port) or (b) confusion between the de facto and registered ports will cause harmful interoperability problems that will deter the use of TLS for Message Submission. The authors of this document believe that both of these outcomes are less desirable than a “wart” in the registry documenting real-world usage of a port for two purposes. Although STARTTLS on port 587 has been deployed, it has not replaced the deployed use of Implicit TLS submission on port 465.
In summary, you can see that Manager’s developer has elected to follow officially sanctioned port assignments for SMTP setup. While IETF has—at least temporarily—succumbed to pressure from the installed base and allowed a dual port assignment that partially resurrects Port 465 for SMTP submissions, it did so at the risk of placing SMTP submissions in conflict with another sanctioned use. There is no guarantee that will remain permanently in effect. A more likely scenario is that ISPs will gradually fall in line with the official port assignments.
I suggest you read 1.1 and 3.3 of the document you quoted from
And from another document referencing RFC8314
Port 465
Port 465 was selected for use as the new, secure SMTP port for SSL while port 25 was tasked with relaying. Many platforms quickly migrated to port 465. Not long afterward, though, IANA (Internet Assigned Numbers Authority) reassigned this port for other uses, and recommended using other ports for secure transmission.
Due to this unusual move, many services that had just switched to 465 were left with a deprecated port. Others quickly adapted to use other ports. Even though port 465 was made redundant in 1998, you can still find many services using it today.
This is partly due to the fact that it was reinstated in 2018 [emphasis added] with RFC8314. With this decision, IEFT wanted to “encourage more widespread use of TLS and to also encourage greater consistency regarding how TLS is used”.
Now we’re into the roots of the weeds. Yes, I’ve read all that. The point remains; Port 465 for SMTP submissions is an outlier occupying a slot officially assigned to another service as a result of misinterpretation of the original standard by some ISPs (and their adherence to their mistakes years after they should have moved into compliance). Whether this usage will ever become official again is unknown.
And it is worth noting what the “RFC” prefix on IETF documentation means—Request For Comment. RFCs are not official port assignments, which are issued by IANA, not IETF. They are, in effect, the beginnings of dialogs that can go on for years. Notwithstanding anything in any RFC, Port 465 is not officially designated for SMTP email submissions. Manager follows the official assignments.
Yes it is, IANA document updated 24/03/2021
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465
I surrender! We are into semantics now. Or we are into how to interpret conflicting documentation where even the authors admit the inconsistencies. IANA’s list (which I did consult before writing my earlier posts) lists the primary assignment—what I’ve called the official assignment—of Port 465 first: URL rendezvous directory for SSM. It then lists the reinstated assignment for message submission over TLS protocol. But, for the secondary assignment, it also lists RFC8314, the very document that recommended reinstatement (without the authority to actually reinstate anything) while acknowledging how unusual the situation is. To me, this looks like IANA throwing up its hands in response to pressure from the IESG itself, allowing a duplicate assignment in spite of being opposed to it. So far as I can tell, there was never further official action by IANA. So the reinstatement essentially rests on a recommendation in RFC8314, not on an actual decision. That is why I speculate that order may eventually be restored and Port 465 once again deprecated.
But this is all engineering politics based on who is on what committee. It has nothing to do with Manager, except that Manager’s developer has chosen not to be drawn into the controversy. Possibly, new generations of technology will replace all of this before anything is finally and officially settled. Meanwhile, Manager allows Ports 25 and 587.
SMTP port 465 added to SMTP Settings in the latest version (23.7.27)
3 Likes