Suggestion: an overview/summary in Virtualmin of the full mail settings for each domain


I believe it would help greatly if virtualmin virtual domains owners could have the official list of every entry they must user in mail clients. I'm thinking of: mail server address, list of the usernames, port for IMAP, port for POP3, encryption method, mail server and port for outbound emails.

This "blue skies" suggestion comes as a follow-up to An argument in its favour: when you look at the virtualmin support forums, you'll notice a large number of the cries for help are related to mail problems - clearly, this is a subject in which things don't always work properly. And having an official overview of the basic settings would be a great start to help.

Possible counter-argument (playing devil's advocate): it should be obvious for everyone already, and even if it isn't, mail clients auto-guess the proper settings. My counter to this possible counter-argument: well, yes, but actually, no, the information is only available after a google search, usually. And in every situation when there is a problem with emails, but you cannot tell yet where the problem lies, you end up wondering if you have the proper settings here and there. Having the official go-to overview in virtualmin would allow to either fix the problem, or exclude possible suspects, allowing to solve the problem faster eventually.

I hope my post made sense, Have a good day, Oliver

Fixed (pending)


That's a good suggestion, and not too hard to implement. I'll add this to our TODO list.

Happy to read this.

Another bit of context, just in case.

The actual reason that made me sorely wish for such a summary in virtualmin, was that time I had a problem fetching emails for a domain, and finally, the only way to make it work was when, instead of mail.domain.tld, for the mail server field, it worked when I gave the reverse of the server.

I still have no idea why, to this day, virtualmin wanted me to give the server's reverse instead of the usual mail.domain.tld, and that actual reason is non-important, but it's something I wouldn't have suspected at all. If only Virtualmin had written it in plain text, it would have saved newbie me a lot of time. So, if it saves that amount of time to other people, it will have been absolutely worth it submitting the improvement suggestion :)

A quick thought:

If there are multiple possibly working options (server's reverse, mail.domain.tld) for the mail server, test which of these possesses a valid signed certificate (not self-signed, but with a working certificate like let's encrypt), and make that one the "official" option.

Context: the android gmail phone app's menu to accept to trust self-signed certificates that's been broken for over a week now, tapping to accept to make an exception doesn't work. So, yeah, definitely, vouching for the mail server address that has a fully valid certificate behind it.

Ok, this has been implemented for inclusion in the next Virtualmin release (6.10)