I am wondering how to get my domain at a registrar to depend on just the DNS on the virtualmin server. Because mac mail is complaining about issues with the ssl and an associate of mine said that it was because I wasn’t using virtualmins internal BIND server.
Set up BIND, point your nameservers (at your domain registrar) to your BIND nameservers; and once you’re sure it’s working, terminate your DNS service with your registrar (or whatever third-party DNS you’re using).
First, however, I’d advise making sure that your friend is right. What kind of issues is Mac mail having? Third-party DNS can coexist quite nicely with Virtualmin.
That was my first thought. A few years ago there was a patch for Qmail specifically to fix TLS handshaking problems that affected only Apple mail transport. @betazedsoftware’s problem could be something like that.
This is not a DNS issue (well, I guess it could be resolving to the wrong IP, which also happens to be setup with mail and, obviously, doesn’t have appropriate certs for your domains).
Are you trying to connect using the domain names themselves? SNI is not widely well supported in mail clients and servers. I’m not even sure if CentOS 8 has a new enough postfix to support it. Regardless, we still recommend you use a single domain for all mail services and use that domain to connect to the server (the username will be sufficient to send and receive mail to/from the right domain).
Yes. I’m using CentOS 8 and it still ships with crusty old Postfix 3.3. For SNI I think it needs to be 3.4 or higher. My domains never needed SNI since each had its own IP. But as soon as I added a sub-server with mail that shares its parent’s IP, client SSL errors like yours started showing up.
One way around it is what Joe recommends and it’s the easiest way: use the same domain for MX and client SMTP across the board. IMO, an improvement on this is to bypass mail.domain.tld and use the server’s hostname instead – that is, if you’re using a hosted domain as the server hostname’s TLD.
An alternative is to get SNI support from a newer Postfix release. There’s a tutorial for that.
Sorry, wrong nightmare. When you said “mac mail” I thought of an ugly experience I had with messages from iCloud and me-dot-com. Apparently I haven’t gotten over it.
For what it’s worth, I’m using Postfix 3.5.3 and SNI on CentOS 7 with no problems whatsoever. I upgraded it manually, which was quite an achievement because what I don’t know about Postfix could fill a large library.
As a side benefit, the automatic configuration in Thunderbird and most other clients I’ve tried (Apple Mail being a notable exception) work fine now. Apple Mail works, too, but PUSH doesn’t. That’s a limitation of the client, not the server.
In my case I should have also paid attention to Dovecot. Postfix SNI behaved fine but when Thunderbird connected to IMAP Android clients didn’t. When Android connected Thunderbird didn’t. It was enough to drive a guy batshit. Long story short, I ended up issuing new certs and that’s when all the pieces fell into place.
Good to know. I didn’t know that because I’ve never used the default Android mail client. I used K9, which had no issues. K9 also works fine on Amazon Fire and on AOSiP (and presumably other AOSP forks).
I’ve since switched to an iPhone as my daily driver, and Canary has no issues. The native Apple Mail client does, but only with PUSH. Everything else works fine.
Of course, the certs have been updated several times since I updated Postfix; so any recent experiences would be after the certs were already updated.
It also helps to know that Dovecot SNI may not be supported by a client (see Dovecot docs)…
“It is important to note that having multiple SSL certificates per IP will not be compatible with all clients, especially mobile ones. It is a TLS SNI limitation. See SSL/SNIClientSupport for list of clients known to (not) support SNI.”