When I look at the logs from the server using docker logs mail -f I see this pattern for every email sent:
Jan 25 07:54:09 mail postfix/submission/smtpd[1893]: warning: hostname mail.qag.me does not resolve to address 106.51.128.78
Jan 25 07:54:09 mail postfix/submission/smtpd[1893]: connect from unknown[106.51.128.78]
Jan 25 07:54:09 mail postfix/submission/smtpd[1893]: Anonymous TLS connection established from unknown[106.51.128.78]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Jan 25 07:54:10 mail postfix/submission/smtpd[1893]: D21ADA41740: client=unknown[106.51.128.78], sasl_method=PLAIN, sasl_username=redacted
Jan 25 07:54:11 mail postfix/sender-cleanup/cleanup[1898]: D21ADA41740: replace: header Mime-Version: 1.0 from unknown[106.51.128.78]; from=<redacted> to=<redacted> proto=ESMTP helo=<mail.qag.me>: Mime-Version: 1.0
Jan 25 07:54:11 mail postfix/sender-cleanup/cleanup[1898]: D21ADA41740: message-id=<[email protected]>
The IP address above is static AND the reverse PTR for the domain mail.qag.me is set to the static IP above.
I'm unable to figure out where this setting has to be configured. I have set the static IP and hostname in my host's /etc/hosts file like below:
106.51.128.78 mail.qag.me artemis
I do notice that the hosts file inside the container says the following:
172.18.0.2 mail.qag.me mail
Postfix however does not seem to use this since smtp_host_lookup = dns is what is set in postconf.
Installing dnsutils in the container and running a dig +x 106.51.128.78 from inside the container resolves to the correct domain name.
What am I missing here? This Unknown is ensuring all the emails from my domain above land in spam.
Is it still an issue?
I am running into the exact same issue. Has anyone found a solution?
I running into the same problem so it's still an issue. Any solutions?
Same problem here. Is there any solution progress?
This was a long time ago. I am not sure what I did to resolve, however. I can tell you my compose file has the following:
Environment Variable -- "OVERRIDE_HOSTNAME=your-fqdn-here.com"
and these declarations right under the image tag:
hostname: machine-name
domainname: domain-name-here.com
Hm i have configured it the same way but the error still occured.
So i dived deeper into that problem and found the content of /etc/hosts inside the docker container:
root@mail:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.144.2 mail.my.domain mail
So a lookup in the hosts file will return the internal 192.168.144.2 and not the external address
I added another line to the end:
XXX.my.public.ip mail.my.domain mail
and from this point on the error is gone.
One drawback is that a restart of the container will change that file back to its origin content but as long as it keeps running it will not complain anymore.
Maybe this can be adapted in the container?
Having issues with DNS setup as well. Editing the /etc/resolv.conf manually solves issues, but how to make it persistent?
You can control the hosts file from your docker-compose script: https://docs.docker.com/compose/compose-file/compose-file-v2/#extra_hosts-1. That makes it persistent.
With the solution above (control hosts file with docker-compose), can we close this? If not, what is needed?
I recently moved the project to another host (and kind of cleaned up parts of the configuration) and now the error is gone.
I am not sure which setting caused the issue but it works now. Inside the /etc/hosts in the container:
172.18.0.2 mail.my.domain mail
but no warning in the logs that the address can not be resolved.
I think i tried different combinations of hostname, domainname and overwrite_hostname as well as the dns entry in the docker-compose.yaml
From my side the issue can be closed. @cruisemaniac are you still facing the issue?
Besides from that thank you @erik-wramner for the time you invest in the project and the new and helpful informations you contribute!
This issue was closed due to one or more of the following reasons:
If you think this happened by accident, or feel like this issue was not actually resolved, please feel free to re-open it. If there is an issue you could resolve in the meantime, please open a PR based on the current master branch so we can review it.