polarathene
commented
2 months ago What have I done wrong?
This:
warning: do not list domain xxxxxxxx.com in BOTH mydestination and virtual_mailbox_domains
You have overlapped the mail domain for these two settings.
- One is intended for internal mail only (service notifications to postmaster mostly), this is the DMS FQDN (hostname configured).
- While the other is for your hosted mail domains DMS will manage. The accounts you add.
If you configure the same mail domain on both ends, then Postfix doesn't know where to route the mail (internal doesn't go to Dovecot, but it does deliver into /var/mail in a different format (handled by Postfix directly), unless when it arrives at the local delivery agent (Postfix) it resolves an alias to virtual alias account then it goes to the virtual delivery agent (sent to Dovecot).
Our FAQ should cover that, and if you followed our troubleshooting docs they'd suggest searching issues for such log lines, where you'll find plenty at the main repo.
Likewise the docs should emphasize how you can have mail.example.com as your DMS FQDN, while using any mail domain you like besides the DMS FQDN to avoid conflict. So hello@example.com would be ok.
That said, LDAP presently opts-out of mydestination, preventing any such notification support (internal mail can't be delivered locally as a result, so would go missing). That was someones "fix" long ago, but I doubt many are aware of it.
You'll also find on the docs FAQ an entry about "bare domains", where if you want the DMS FQDN to still be example.com and simultaneously serve mail accounts with the same domain / FQDN, you'll be advised to match LDAP config with mydestination config change. That has no official support/endorsement by DMS as the project still carries some fragile assumptions in config from long ago, it may work well for you, but generally you're advised to stick to the pattern of not overlapping the DMS FQDN.
mail.example.com is usually better to go with as your hostname. The only reason people avoid that tends to be that they mistakenly think the mail accounts need to share this FQDN, or they're trying to use the same example.com certificate because provisioning a separate SAN/cert (or via wildcard) for DMS is awkward for them.
There's the why and several ways you can approach fixing it. Hope that helps.
colindawson
I'm not sure if the problem is with the helm chart, or the software, so I'm starting at the beginning.
I've followed the instructions in the README.md to get the server up and running. As I'm using certmanager for my certificate I've decided to omit the
-nmail parameter from the install, so that the mail server is deployed to the default namespace. This will allow the deployment to access the certificate secret, which is maintained automatically by the cluster.I copied the
values.yamland made the follow modifications.....certificate:tocertificate: xxxxxxxx.com-tlsOVERRIDE_HOSTNAME: xxxxxxxx.comUsing this I've been able to then open a console in the contain and create desired e-mail accounts, I've also setup DKIM correctly. (This isn't my first mailserver, but it is the first time using the helm chart)
I'm even able to use outlook to login perform the send/receive without errors. And can send e-mails out to gmail without any problems.
However, when I try to receive an e-mail on any of the account, the mail does not get through.
here's the output that I get from the pod when I try to send an e-mail to myself, I've changed the domain name in the log, but everything else is left in the clear.
What have I done wrong?