I’m trying to find the origin of an issue I have with a domain and its mails, and that made me realize something. But please, correct me if I’m wrong, it’s the precise reason I’m posting to ask.
It’s not just me, right, Virtualmin REALLY doesn’t keep anywhere a list of the entries we must give our mail clients?
Such as:
mail server
login
port to mention
encryption to mention
Context:
You could say “the fields and their contents are totally obvious, duh, no need to mention it”. I’d have said you were right-ish until a short while ago.
But today, among my experiments to figure out why thunderbird tells a website’s certificate is invalid and doesn’t match the website, and it tells me the certificate it finds doesn’t match the start/end of the current actual certificate, I’ve had this weird issue.
I created a new username @ the website having the issue, and for that username, for the first time since I’ve used virtualmin, thunderbird auto-guessed a working username… but that username was username@domain.tld, instead of the “usual” username.domain_without_tld
And that made me reconsider, maybe some other fields I consider as obvious, really, aren’t so obvious. For instance, the mail server field. Instead of mail.domain.tld, which doesn’t work, it works with the reverse of the server hosting the domain, as long as it’s allowed as a self-signed certificate (and yet, it’s let’s encrypt, clean and all, recognized in web browsers).
I’ve also made various tests with newly created accounts, seeing thunderbird “guessed” different settings…
I’ve also had a still unsolved case in which thunderbird will accept to make an exception for the certificate, but android’s gmail app won’t…
All the more reason to really wish to know what the “official” values for the mail fields in a client ought to be.
You can disregard the “context” part, really, my post boils down to that, I’d welcome with open arms and a choir of singing angels the information that, yes, virtualmin has such as list, and here’s where it can be found
In my present context, mail works only when the reverse is provided instead of mail.domain.tld, for some reason.
But again, scratch my present context, what I’m after is the bigger picture, that would help every time.
it’s why I’m after this kind of information, not what it is supposed to be, by the books, but what it IS - according to the virtualmin internals of each precise server causing problems.
If it is, or if it were, gathered in a determined location that the admin could read, it is, or it would be, the solution to all those email problems.
In that case it seems to be a DNS issue or similar.
You can get the information I provided from different places of the CP, so its not an assumption.
Still, I am not sure if there is a genera overview of all of them in one place. If not, then it might be worth requesting it.
There isn’t, but probably should be. But, also it sounds like there’s a little something wrong with your configuration making it harder than usual to just figure it out.
We usually recommend having one central domain for mail, since Postfix (until very recently) cannot have multiple certificates. So, the best way to handle it is have a “main” domain that is used for all mail clients server settings, and the cert for that domain would be the certificate you’d use for Postfix.
