Full summary

Mostly useful as a reference for myself, but making it public here to associate it with the relevant PR, and the hopefully unlikely event that some poor maintainer in the future needs to wade through history about these changes/decisions 😅

This PR is an iteration improvement of a recent refactor of the same hostname/domainname handling logic (#2175).

While there was plenty of discussion and iteration in the original version of this PR (#2245), anything relevant to this change is now covered in this PR thread, all other changes in the original have been extracted and reference it as well (thus available at the end of the thread prior to closing), but were catering to unrelated concerns.

Anyone reading this comment should not need to wade through the original thread 🎉 Direct links to comments on it that are potentially worthwhile are linked below, in addition to the commit message history and inline comments of this PR for changes it applies.

I don't consider the following as blocking for merge of this PR (no regressions are introduced AFAIK), but they are relevant context wise, referencing my comments from the original PR discussion thread/review.

Including here for traceability for myself and future maintainers:

• Not handled yet:
  • Bare domains (two DNS labels only, for the FQDN) will still result in misconfiguration with Postfix. This should be handled similar to how LDAP does to avoid issues (More details).
  • --network=host is a case where /etc/hosts may not be configured correctly. Present advice is to use OVERRIDE_HOSTNAME. I don't consider that sufficient as it does not update /etc/hosts, only a workaround for HOSTNAME usage. Needs investigation + documentation (More details).
• Test mail_hostname.bats: Still needs to be extracted from original PR (now closed), it was mostly a refactor (but included some /etc/hosts checks).
  • I have a review comment to go over again relevant to that. I will handle that with a follow-up PR that additionally converts it to using the new common container template approach.
  • Note: This test file was originally two separate tests for OVERRIDE_HOSTNAME and SRS_DOMAINNAME that got merged into a single test file here.
• v11: Should probably deprecate support for domainname, possibly with some related ENV, but more thorough testing is required (More details).
  • SSL_DOMAIN and OVERRIDE_HOSTNAME history detailed here and here (also details SRS_DOMAINNAME, and a 2017 switch for HOSTNAME from using the command hostname, to hostname -f as a workaround fix when using --link..), along with this comment about cert provisioning for a bare domain but configuring a hostname with a subdomain scenario.
  • Reference: HOSTNAME and DOMAINNAME handling in _obtain_hostname_and_domainname, with comparison to before/after changes in original PR, and other insights worth looking over again are detailed here.

Future work:

• DOMAINNAME => DMS_DOMAINNAME (or similar), potentially with deprecation notice for the domainname user config.
• OVERRIDE_HOSTNAME and SSL_DOMAIN => Dropping support with deprecation notice once test matrix is implemented and confirms safe for removal (with original scenarios requiring these better documented). SRS_DOMAINNAME may warrant consideration as well.
• HOSTNAME => DMS_FQDN, after the prior two changes are able to ensure it's safe to make this change. Potentially switching back to hostname instead of hostname -f or considering other alternatives.

When looking into these changes, this comment itself provides ample reference for insights in doing so. In addition, hostname and domainname config options along with command output was tested with a variety of configurations on both Debian and Alpine base images (just the base images, without DMS additions), along with interaction of /etc/hosts content is detailed here (USEFUL REFERENCE TABLE).

That resource can be revised with the next iteration and added to maintainer docs, which in combination with an improved test suite will help avoid this area becoming problematic in future contributions.

Additional note about current behaviour, if you don't use a bare domain (two label FQDN), then we implicitly do remove the 1st (left-most) label from the derived FQDN and use the rest as DOMAINNAME such as for the postmaster address. I don't believe we document that and it can be inconsistent with the bare domain FQDNs.

Not relevant to this PR, open a discussion for personal support requests.

Short answer is you can't do anything about that. The IP provider controls rDNS entries, you need a static IP that they agree to change rDNS entry for.

Changing your hostname to the rDNS record makes no sense when you don't own that domain.

You don't need the rDNS, if you're concerned about delivery reputation / success relay through a service like SendGrid.

You're not getting the point. It's not a Postfix issue; it's a DNS issue. Please use the discussions for this kind of question.

Thank for the reply. I'm sorry to put this question here and was not looking for personal support. But I would like to know if it would be technally wrong if postfix would could somehow be configured to announce itself with the reverse dns name to avoid spam points .... wouldnt' this be possible to automate  during the docker container setup, without breaking anything else?

This is still the kind of support questions that belong in Discussions, not our pull requests.

The check you're referring to varies by MTA AFAIK, with Postfix it is likely reject_unknown_reverse_client_hostname, I have written this comment to explain it better.

It is not as strict of a requirement as you are seeking with rDNS exact match. I don't think that needs to be that strict, so you should be fine.