Please tell me if I forgot about something crucial.

Nope, just replacing smtps for submissions in the project files should do it AFAIK.

We may want to add a minor test that greps 465 in /etc/services of the container to confirm it is assigned submissions. If the base image changes, that sometimes won't be the case (surprisingly with Fedora), so it'd be good to catch that instead of potential confusion troubleshooting it down to that issue 😅

I did want to get this into v12, but forgot about it. Probably should be considered a breaking change 🤷‍♂️

v13 release after v12.1 maybe?

We may want to add a minor test that greps 465 in /etc/services of the container to confirm it is assigned submissions. If the base image changes, that sometimes won't be the case (surprisingly with Fedora), so it'd be good to catch that instead of potential confusion troubleshooting it down to that issue 😅

👍🏼

I did want to get this into v12, but forgot about it. Probably should be considered a breaking change 🤷‍♂️

v13 release after v12.1 maybe?

I thought this was fine for v12.1.0, because I see no reason that this is a breaking change. Why would you consider this a breaking change?

Why would you consider this a breaking change?

If someone depends on smtps being configured here?:

Some issues that show this could happen:

• Sending emails from within container network when behind "HaProxy" #2929 uses postfix-master.cf with smtps/inet/smtpd_upstream_proxy_protocol = haproxy
• Fetchmail in combination with haproxy #1841 (same as above)
• Mailserver behind HAProxy #1523 (same as above)
• relaying: mails are not relayed with implicit tls (465) / improve scripts & configuration #2601 (comment) (not directly, but semi-related advice)
• Fail2Ban upstream config regex may only recognize smtps, not submissions (I haven't looked into how relevant that is, just another example of where behaviour may change unexpectedly)

Since we provide ways to target configuration for smtps/submissions, and it's used as the syslog name for monitoring logs, I wouldn't be surprised if some users find it a breaking change. @wernerfred usually views this sort of change as breaking as well.

For reference, a comment motivating this smtps => submissions change (since none was provided in the PR description): #3170 (comment)

Squeeze the change into v12 if you'd like? It shouldn't cause any surprises beyond concerns mentioned above, so you can probably avoid further delaying testing / freeze. If you do add it, then it should be part of the notable changes list in the changelog.

Some issues that show this could happen:

Good points. If there isn't a huge benefit, but possible (future) problems with stuff like fail2ban expecting smtps, I think it's not worth and we shouldn't change it.

I think it's not worth and we shouldn't change it.

It's fine for introducing as a breaking change. Users can raise actual bug reports to surface the problems.

Like I said, I am not sure if fail2ban monitoring smtps was relevant, just an example that came to mind. I looked through git blame and realized that the regex still covers submissions, even though it was added back in 2016. So no issue there with this change.

Users may still have their own config / scripts or other tools that are more explicitly expecting smtps, which is my main point of respecting semver by only applying the change for a major release.

I had a glance at our F2B config as well, and it is using submissions, not smtps, as @polarathene said.

I am fine with waiting for the next major with this. It will probably not even take too long for v13.0.0 to come out, due to other changes I have in mind.

INFO: Marked this with meta/feature-freeze now to indicate this PR is not to be merged before v12.1.0 is released.

Documentation preview for this PR is ready! 🎉

Built with commit: c24b24b