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.
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.
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 email@example.com
Contact: IETF Chair firstname.lastname@example.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
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.
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.