v14 fails with error: postfix/smtp error: <[email protected]>: mail for server1.example.com loops back to myself

[IghuToh0]

Same configuration works in 12.1.0, but in 14 (latest) this error shows up: postfix/smtp error: <[email protected]>: mail for server1.example.com loops back to myself

spf,dkim,letsencrypt are working.

[polarathene]

Did you follow the CHANGELOG.md breaking changes for v13 and v14?

You share no config, it is difficult to assist you in anyway. v14 works fine, it will be a configuration issue on your side that is broken.

Try create a fresh v14 container and compose.yaml. Minimize the configuration so that it's only changes in ENV and config that are still needed to trigger this problem for you. Then share with us that compose.yaml config.

Regarding DNS / LetsEncrypt:

• DMS needs LetsEncrypt for the hostname (FQDN), such as mail.example.com. There is no expectation for example.com (mail account address).
• DNS SPF record for a mail domain (eg: example.com) should authorize DMS (mail.example.com) to send mail on it's behalf.
• DNS MX record for a mail domain (eg: example.com) should point to DMS (mail.example.com) for where mail should be delivered to.

Make sure you understand the above well, since some users mix that up with DNS or certificate management. DMS FQDN and mail domains it manages are intended to be distinct/separate.

postfix/smtp is the Postfix service for sending mail. So from the error it seems that [email protected] is the sender address trying to send mail to server1.example.com, but Postfix is not aware that this should be DMS FQDN, which means you have not configured DMS properly. Hence when it tries to send the mail, it realizes it would go back to itself.

Perhaps this worked for you in v12.1 of DMS, but it was likely a bug that was since fixed. Postfix should be configuring itself to use the same hostname you set in compose.yaml. Many older DMS compose configs have a mistake with a domainname setting, this is an NIS domain, it is not the same, you should only use hostname (hostname: mail.example.com).

[IghuToh0]

btw ~240.000 users are using version 12, neither 13 nor 14 arrive this numbers.

Thus, try a usual version 12 setup and change the container to 14. The described error shows up.

Thank you.

[casperklein]

This is not how it works..

We can guide you to track down the root cause for your issue. But if you are not willing to support/try the things @polarathene mentioned, I am afraid we can't help you.

It's your responsibility to read and understand the changelog, especially the breaking changes.

I would suggest, to upgrade step by step to see, in which version the issue starts happening.

Again, just changing the image from 12 to 14 and expecting everything works out of the box is just wrong! There were a lot of (breaking) changes + an upgraded Debian base image.

When you have identified, when the issue starts happening, open a proper bug report with all necessary information.

Saying "It works before, now it don't" and not providing any useful info (configuration, logs etc.) about your setup makes it almost impossible to help you.

PS:

btw ~240.000 users are using version 12, neither 13 nor 14 arrive this numbers.

Where do have this numbers from?

[polarathene]

btw ~240.000 users are using version 12, neither 13 nor 14 arrive this numbers.

Where do have this numbers from?

They are the pull count for GHCR tagged images: https://github.com/docker-mailserver/docker-mailserver/pkgs/container/docker-mailserver/versions?filters%5Bversion_type%5D=tagged

It does not represent active users, just those that pull from the registry AFAIK. So any CI pulls may count, and anyone who upgrades would still have their previous pull count contribution retained for older images of course.