Description
This defaults to the assumption that a hostname mail.example.com will use mail accounts @example.com and thus creates an implicit postmaster address to use within our scripts for that mail domain.
We've had several users in the past report deployments where this was not the case, thus the postmaster address was invalid.
They also need to add postmaster address for other mail domains they manage (some have used a regexp alias on the local-part to handle all postmaster@ redirects to a preferred address, but this appears to also affect foreign / remote postmaster@ recipient domains too which would not be desired).
Reference topic
I recently responded to a discussion on this topic: https://github.com/orgs/docker-mailserver/discussions/3758#discussioncomment-8075486
It's a bit messy / disorganized, but is a public source of insights / notes from me 😅 This issue is to document the concern as it's not just the POSTMASTER_ADDRESS ENV default to consider, and our docs perhaps could also better cover this too.
postfix "warning: required alias not found: postmaster"
mydestination
Partly related to mydestination investigation from 2023:
|
# Take the following concerns into consideration if adjusting `mydestination`: |
|
# https://github.com/docker-mailserver/docker-mailserver/pull/3264#pullrequestreview-1396816109 |
|
# https://github.com/docker-mailserver/docker-mailserver/pull/3264#issuecomment-1518993555 |
|
mydestination = $myhostname, localhost.$mydomain, localhost |
Postfix does not require a local delivery agent configured. The mail.example.com hostname was intended to distinguish the MTA itself from the hosted mail domains DMS manages, along with system related mail. It still is technically reachable to send mail to, or for it to send mail externally from, and itself would be expected to have a postmaster address.
It is not a change that we've been too eager to make, as my prior input expressed 😓
I don't have time to dig through all that again to gain the confidence in adjusting that part of config.
Related to such a change is concerns with aliasing (catchall address and it's gotchas), which can be partly related to postmaster advice. Like this regexp alias in our tests which would not be wise for production deployments AFAIK:
If changes were done to this config, be aware of a misleading dovecot: auth: log that's actually checking Dovecot UserDB of a recipient for their quota rather than checking for a valid user.
Additional resources
- Postfix basic setup docs - "What trouble to report to the
postmaster"
- Encourages
/etc/aliases (local alias) configured for both postmaster and root to admin email.
- Mentions types of system notification reports Postfix will send to the postmaster address (local-part, but may append
$myhostname / $myorigin but /etc/aliases for the postmaster local-part should be sufficient to redirect to a virtual alias / mailbox address)
- One of the Postfix devs shared in 2007 that they have an empty
mydestination (no local domains)
- Links to Postfix docs for a standard configuration example of using Postfix as an email firewall/gateway with related configuration.
postmaster moved to virtual alias at /etc/postfix/virtual (virtual_alias_maps). Other examples also provide additional context on the subject that is useful.
Description
This defaults to the assumption that a hostname
mail.example.comwill use mail accounts@example.comand thus creates an implicit postmaster address to use within our scripts for that mail domain.We've had several users in the past report deployments where this was not the case, thus the postmaster address was invalid.
They also need to add postmaster address for other mail domains they manage (some have used a regexp alias on the local-part to handle all
postmaster@redirects to a preferred address, but this appears to also affect foreign / remotepostmaster@recipient domains too which would not be desired).Reference topic
I recently responded to a discussion on this topic: https://github.com/orgs/docker-mailserver/discussions/3758#discussioncomment-8075486
It's a bit messy / disorganized, but is a public source of insights / notes from me 😅 This issue is to document the concern as it's not just the
POSTMASTER_ADDRESSENV default to consider, and our docs perhaps could also better cover this too.mydestinationPartly related to
mydestinationinvestigation from 2023:docker-mailserver/target/postfix/main.cf
Lines 15 to 18 in aba218e
Postfix does not require a
localdelivery agent configured. Themail.example.comhostname was intended to distinguish the MTA itself from the hosted mail domains DMS manages, along with system related mail. It still is technically reachable to send mail to, or for it to send mail externally from, and itself would be expected to have a postmaster address.It is not a change that we've been too eager to make, as my prior input expressed 😓
mydestinationinpostfix/main.cf#3264 (review)mydestinationinpostfix/main.cf#3264 (comment)I don't have time to dig through all that again to gain the confidence in adjusting that part of config.
Related to such a change is concerns with aliasing (catchall address and it's gotchas), which can be partly related to postmaster advice. Like this regexp alias in our tests which would not be wise for production deployments AFAIK:
docker-mailserver/test/config/postfix-regexp.cf
Line 5 in aba218e
If changes were done to this config, be aware of a misleading
dovecot: auth:log that's actually checking Dovecot UserDB of a recipient for their quota rather than checking for a valid user.Additional resources
postmaster"/etc/aliases(local alias) configured for bothpostmasterandrootto admin email.$myhostname/$myoriginbut/etc/aliasesfor thepostmasterlocal-part should be sufficient to redirect to a virtual alias / mailbox address)mydestination(nolocaldomains)postmastermoved to virtual alias at/etc/postfix/virtual(virtual_alias_maps). Other examples also provide additional context on the subject that is useful.