EDITED
The root of this problem has a lot less to do with the mydestinations in the main.cf file and more to do with finding the letsencrypt certificate in the proper path. So I've changed the title and amended this on to the original report.
Context
In the process of setting up my mail server, I am setting my environment variables to
HOSTNAME=mail
DOMAINNAME=abc.com
CONTAINER_NAME=mail
OVERRIDE_HOSTNAME=abc.com
The override hostname is intentionally set because the letsencrypt certificate will only work for the base of the domain (abc.com) and not (mail.abc.com) and are stored in the abc.com folder when letsencrypt is mounted in the container. In order for the container to automatically find the correct certificate, the hostname can only be of the domain.com format.
This is all fine with the exception of the virtual tables created when I add an e-mail to the database. If I add an e-mail for '[email protected]' to the container (using the setup.sh script) it will add a virtual domain and address for this. The postfix main.cf file has the line:
mydestination = $myhostname, localhost.$mydomain, localhost
Because $myhostname has been overridden (instead of using the output of 'hostname') to get lets encrypt to work, the mydestination contains abc.com and the virtual domain tables contain abc.com. This obviously creates a conflict and as such mail will not be delivered (in my setup anyhow). I don't remember if this was an ERROR or a WARNING, but either way the end result is that mail is not delivered.
Expected Behavior
I would expect there to be no conflict between 'mydestination' and the 'vritual' tables used for other domains.
Actual Behavior
Mail is not delivered because there is a conflict between the same hostname in 'mydestination' and the 'virtual' mail tables.
Possible Fix
Every time I download a new image of the container, I stand it up as is. After that I log into the container and edit the main.cf in the postfix directory and remove the $myhostname from the 'mydestination=' line in the file. I then just commit my own image and stand up containers from that.
I propose that the $myhostname be removed from the 'mydestination' configuration item. Correct me if I am wrong, but should all email accounts exist exclusively in the virtual tables?
Steps to Reproduce
- set OVERRIDE_HOSTNAME=abc.com in the environment
- add an e-mail address for the same domain as the OVERRIDE_HOSTNAME is set to
- conflict will then exist between mydestinations and virtual tables
Your Environment
- Amount of RAM available: 1G total for virtual server I'm running this on
- Mailserver version used: Image ID 8ae795dc146c
- Docker version used: 18.09.7, build 2d0083d
- Environment settings relevant to the config: OVERRIDE_HOSTNAME
- Any relevant stack traces ("Full trace" preferred): N/A
EDITED
The root of this problem has a lot less to do with the mydestinations in the main.cf file and more to do with finding the letsencrypt certificate in the proper path. So I've changed the title and amended this on to the original report.
Context
In the process of setting up my mail server, I am setting my environment variables to
The override hostname is intentionally set because the letsencrypt certificate will only work for the base of the domain (abc.com) and not (mail.abc.com) and are stored in the abc.com folder when letsencrypt is mounted in the container. In order for the container to automatically find the correct certificate, the hostname can only be of the domain.com format.
This is all fine with the exception of the virtual tables created when I add an e-mail to the database. If I add an e-mail for '[email protected]' to the container (using the setup.sh script) it will add a virtual domain and address for this. The postfix main.cf file has the line:
Because $myhostname has been overridden (instead of using the output of 'hostname') to get lets encrypt to work, the mydestination contains abc.com and the virtual domain tables contain abc.com. This obviously creates a conflict and as such mail will not be delivered (in my setup anyhow). I don't remember if this was an ERROR or a WARNING, but either way the end result is that mail is not delivered.
Expected Behavior
I would expect there to be no conflict between 'mydestination' and the 'vritual' tables used for other domains.
Actual Behavior
Mail is not delivered because there is a conflict between the same hostname in 'mydestination' and the 'virtual' mail tables.
Possible Fix
Every time I download a new image of the container, I stand it up as is. After that I log into the container and edit the main.cf in the postfix directory and remove the $myhostname from the 'mydestination=' line in the file. I then just commit my own image and stand up containers from that.
I propose that the $myhostname be removed from the 'mydestination' configuration item. Correct me if I am wrong, but should all email accounts exist exclusively in the virtual tables?
Steps to Reproduce
Your Environment