Description
After looking under the hood of this container for a bit, it seems there are multiple, sometimes competing ways to handle aliases:
1: An (empty) /etc/aliases file gets created inside the Dockerfile
2: The start-mailserver.sh script (that gets run out of supervisord?) overwrites /etc/aliases with one that points root -> postmaster
3: The check-for-changes.sh (that gets run out of supervisord?) also overwrites /etc/aliases. There is a comment here that identfies that as a bug, presumably since it competes with (2).
4: /tmp/docker-mailserver/postfix-aliases.cf (external to the container, making it not a great option to set container defaults).
5: Similar to mechanism (4), /tmp/docker-mailserver/postfix-virtual.cf
I find these multiple options both confusing and somewhat dangerous for unsuspecting users of the package. For example if you do "postfix standard things" to set up aliases then the scripts run out of supervisord will simply blow them away (silently, at that).
Need to brainstorm with somebody on what is a good way to streamline this and hopefully define one "internal" way to create default aliases, while keeping the external post-setup way. I think it makes sense to put the defaults in /etc/aliases and leave the /tmp/docker-mailserver supervisord stuff alone, so that external configs are not hampered/complicated by the process. I guess that implies changing the start-mailserver.sh and then fixing the seemingly documented bug in the check-for-changes.sh script.
Thoughts?
I want to make a PR that adds the following default aliases (or similar) at the time of container image creation or deployment
postmaster -> root
amavis -> root
clamav -> root
Description
After looking under the hood of this container for a bit, it seems there are multiple, sometimes competing ways to handle aliases:
1: An (empty) /etc/aliases file gets created inside the Dockerfile
2: The start-mailserver.sh script (that gets run out of supervisord?) overwrites /etc/aliases with one that points root -> postmaster
3: The check-for-changes.sh (that gets run out of supervisord?) also overwrites /etc/aliases. There is a comment here that identfies that as a bug, presumably since it competes with (2).
4: /tmp/docker-mailserver/postfix-aliases.cf (external to the container, making it not a great option to set container defaults).
5: Similar to mechanism (4), /tmp/docker-mailserver/postfix-virtual.cf
I find these multiple options both confusing and somewhat dangerous for unsuspecting users of the package. For example if you do "postfix standard things" to set up aliases then the scripts run out of supervisord will simply blow them away (silently, at that).
Need to brainstorm with somebody on what is a good way to streamline this and hopefully define one "internal" way to create default aliases, while keeping the external post-setup way. I think it makes sense to put the defaults in /etc/aliases and leave the /tmp/docker-mailserver supervisord stuff alone, so that external configs are not hampered/complicated by the process. I guess that implies changing the start-mailserver.sh and then fixing the seemingly documented bug in the check-for-changes.sh script.
Thoughts?