I have MIAB installed on Ubuntu 22, and occasionally (a few minutes a day) sending emails via SMTP fails:
Connection could not be established with host “ssl://mail.[…].com:465”: stream_socket_client(): Unable to connect to ssl://mail.[…].com:465 (Connection refused)
How can this be resolved?
Is it some time in the 03:00 hour? The server will refuse email delivery whilst performing the daily backup.
Why are you using port 465?
Port 465 was originally registered for SMTPS (SMTP over SSL). After a brief stint in that function, port 465 was reassigned for a different use and deprecated.
Port 465 is recommended on the “Instructions” page:
I’ll try with 587.
It doesn’t happen always at the same time, it looks random, in the last 24 hours I have 7 emails lost, at 04:01, 07:26, 21:07, 21:09, 00:10, 21:19, 21:24
In mail.log I see nothing at those hours, I don’t know where to check…
Hi,
Re ports - both 465 and 587 are used by MIAB, you’ll need them both open.
The instructions say that 22 (SSH), 25 (SMTP), 53 (DNS tcp & udp), 80 (HTTP), 443 (HTTPS), 465 (SMTP submission), 993 (IMAP), 995 (POP) and 4190 (Sieve) are needed.
Re sending failures - your server will handle connection problems gracefully and retry multiple times at increasing intervals. While failures might delay email, they shouldn’t cause it to fail, and you shouldn’t have to do anything about them. If you’re the sender, then intermittent connection problems are likely at the recipient end - not much you can do but retry.
This is only half of the story.
Historically port 465 was briefly registered for “smtps” (sever to server), which didn’t make much sense, as SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a protocol called “urd”. So far so good…
However, as widely used email software began to use port 465 for “Submission over TLS” (client to server with Implicit TLS), the port became a de-facto standard for this use case which then led to RFC 8314, a one-time procedural exception, that assigned “Submission over TLS” to Port 465, even though the port was already assigned to another protocol.
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Ports
465 This port was deprecated after RFC 2487, until the issue of RFC 8314.
https://datatracker.ietf.org/doc/html/rfc8314#section-7.3
IANA has assigned an alternate usage of TCP port 465 in addition to the current assignment using the following template [RFC6335]:
Service Name: submissions
Transport Protocol: TCP
Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org
Description: Message Submission over TLS protocol Reference: RFC 8314
Port Number: 465
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 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 relative to
https://datatracker.ietf.org/doc/html/rfc8314#appendix-A
Port 465 is presently used for two purposes: for submissions by a large number of clients and service providers and for the “urd” protocol by one vendor. Actually documenting this current state is controversial, as discussed in the IANA Considerations section. However, there is no good alternative. Registering a new port for submissions when port 465 is already widely used for that purpose will just create interoperability problems. Registering a port that’s only used if advertised by an SRV record (RFC 6186) would not create interoperability problems but would require all client deployments, server deployments, and software to change significantly, which is contrary to the goal of promoting the increased use of TLS. Encouraging the use of STARTTLS on port 587 would not create interoperability problems, but it is unlikely to have any impact on the current undocumented use of port 465 and makes the guidance in this document less consistent. The remaining option is to document the current state of the world and support future use of port 465 for submission, as this increases consistency and ease of deployment for TLS email submission.
Sorry, but that’s not true. It depends on how you need or want to connect your email clients to your box.
587 is used for “Submission” (PLAIN / STARTTLS)
465 is used for “Submission over TLS” (implicit TLS)
If you only use one or the other, you don’t need both ports open
My web app (in PHP) tries to send an email by connecting to my box over SMTP. If my box is down, nobody will retry anything, I’d need to implement a custom logic with cronjobs etc. to attempt to resend failed emails, but in most cases this will not happen.
I found this using journaltcl:
Oct 29 03:24:06 [hostname] systemd[1]: postfix.service: Deactivated successfully.
Oct 29 03:24:06 [hostname] systemd[1]: Stopped Postfix Mail Transport Agent.
Oct 29 03:29:07 [hostname] systemd[1]: Starting Postfix Mail Transport Agent…
Oct 29 03:29:07 [hostname] systemd[1]: Finished Postfix Mail Transport Agent.
why it stops and stays down for 3 minutes?
EDIT: found, it’s the backup…
