I just installed a server with the new installer. Nothing to report on Debian 12, it still runs smoothly (I’m running Apache).
Still, I noticed that the installation now includes a Let’s Encrypt Certificate and that there is an Apache VirtualHost named after the server’s hostname. This is pretty cool, thanks … but it also raises some questions:
Is the default certificate copied to all services (I used to manually create a Virtual Server and to use the “Set as Default Services Certificate button”).
Where is it managed? Just in case there is a problem with Let’s Encrypt in the future…
Can I still create a Virtual Server with the same name of the default VirtualHost?
You should not! That should never have been a thing you were going to do, regardless of the default host domain.
It makes no sense to virtually host a name when it’s the name of the system itself. You’ll confuse Postfix (and possibly some other services, but definitely Postfix).
@Joe, do you mind if we completely remove the mail feature for the host default domain, making it impossible for users to enable it and potentially break things?
I mean, I guess if we have to have a host default domain, then it should protect users from doing things that can’t work right. (I still don’t love the idea.)
I think there has been a misunderstanding here, probably due to my poor English/explanations. I was just talking about the Virtualmin’s Virtual Server wearing the system’s FQDN (like “host1.example.com”). Until recently, the Install Wizard asked (at the very end of the process) if we wanted (or not) to automatically create it. Personally, I always answered “no” to that question and created it manually afterwards … and that explains why I was not familiar with the “Virtualmin Configuration → SSL settings” option. Note however that the default domain that I created thus only had 3 features activated: “Apache”, “apache SSL” and “MariaDB”. Was I really wrong to do so?
Anyway, from now on it looks like the question is not asked anymore during the Install Wizard process and it is automatically created.
I’m not sure I quite understand this sentence, isn’t it the exact purpose of the “Virtualmin Configuration → SSL settings” option?
Yes, we’ve changed it to happen during the Virtualmin installation time. The goal was to pre-create an SSL certificate for the hostname and provide users with a better initial experience on the first login, avoiding errors related to self-signed SSL certificate. It might sound simple, but it’s quite complex to get everything right.
Additionally, the latest changes can prevent users from easily enabling mail-related features for a domain name that matches the hostname within certain configurations, regardless of whether the domain was created automatically during installation time or manually later.
@Joe, is this what we wanted in terms of hosting a default hostname virtual domain, right? I mean, having an ability to disable mail-related features for host default domain (i.e. domain that matches the hostname) on certain systems?
I’ve been reflecting on it (again), and it may be confusing for some users why the mail for their host10.example.com domain has to be disabled? We can give them a million reasons, but I doubt anyone would listen, and practice has made it very clear.
I wouldn’t be surprised if some admins wanted mail work (in a straightforward way) for addresses like dns@host10.example.com.
Why not?
What stops us from leaving things as is, i.e. allowing mail-related features to be enabled for host default domain?
If we don’t:
What exactly is going to break?
Which exact Postfix and/or network configuration would cause mail delivery issues with host default domain (i.e. hostname placed in virtual map)?
I myself never faced any issues when having a hostname placed into /etc/postfix/virtual map file, i.e. the following works just fine across numerous systems:
The same configuration I have on another Ubuntu 22.04 system, which also work just fine.
With all the recent Virtualmin patches, we now have an API to control when the mail feature for the default domain (i.e., the hostname) should be allowed or disallowed. To be honest, I prefer to keep it always enabled unless it’s specifically disabled in the Virtualmin Config during installation.
So, what specific configurations should be considered risky enough to disable the mail feature for the default domain?
Thank you @Ilia for this extensive post. I personally never use any address like mail@host.example.com … but I am also very interested in knowing what could be broken in doing so.
We can have a more in-depth discussion with Joe and @Jamie about this. It’s been an ongoing topic for decades and has confused many people.
While Joe has been incredibly patient, I worry he might lose his patience if he has to answer these questions again. He did answer them before, but in a more tech-savvy way.
My aim, though, is to compile all the ideas into a single, simple and more comprehensive post.
This is my take on it.
Long story short:
We are simply trapped when it comes to having mail enabled (using virtual maps) with the host default domain (matching hostname) and keeping Postfix happy!
Even though the configuration examples I provided in previous comment will work most of the time in practice, it will always be against what the Postfix documentation recommends, which clearly states:
NEVER list a virtual alias domain name as a mydestination domain!
Additionally, even though mail delivery might work correctly, including forwarding to local and remote email addresses, Postfix will always generate a warning with this type of configuration:
postfix/trivial-rewrite: warning: do not list domain host.example.com in BOTH mydestination and virtual_alias_domains
Though, it isn’t clear to me personally why Postfix developers made this configuration work almost flawlessly, yet generate so much noise and confusion.
The idea of having the hostname in mydestination is to make the current machine consider itself the final destination; yet, configuring the same hostname as a virtual domain without using aliases is not extreme; on the contrary, it’s straightforward. Practices prove it, as thousands of people intuitively want this functionality to work. But we are where we are.
Summary:
Can you enable mail for the default domain that matches the hostname? Potentially, yes, but it depends on the configuration. The default configuration, closest to what Virtualmin sets as default, has worked with no issues every time;
Will forwarding to local and remote email addresses work with such a configuration? Yes, it should;
Is there a way to make this same configuration work without Postfix logging a warning every time? No, there is no way to do it. The only “solution” I’ve found is to set myhostname to localhost. However, this isn’t recommended for a production mail server. Although delivery works fine and no warnings are produced (logged), it does not uniquely identify the server on the network and can be a red flag for spam filters.
All that said, I don’t think we should limit users from enabling mail for the host default domain.
P.S. The tests were run on Postfix versions 3.5.9 ↔ 3.6.4.
Hmm, seems like we shouldn’t allow the default domain which matches the myhostname line in the Postfix config to be used for a Virtualmin domain with email then. We shouldn’t just check against the hostname though, because myhostname might be set to something else…
Sadly, it isn’t possible to do in a straightforward way, which means configuring the system as Postfix expects. This might involve using an additional name like mail.host.example.com or using boring and generic hostname like ns100.example.com, which shouldn’t be used for anything else.
Then again, we’re back to square one. What if a user wants their hostname to have a nice webpage or at least a redirect to some website? Ideally, users shouldn’t want any of this. But users did and most probably will always want it, because it’s pretty natural I’ve got to admit – here is why – if a user has 10 pretty hosts named host1.example.com, host2.example.com, etc. Each host has a service associated with an email like dns@host2.example.com or webmin@host2.example.com, and all these hosts could after all forward emails to lets say root@mail.masterhost.example.com.
Postfix doesn’t want us to have such a configuration, we all get it. Yet, it still delivers mail just fine in 99% of cases. This is bonkers!
That said, currently all the latest patches merged in my latest PRs do things the right way, even though I don’t find it neither intuitive nor user-friendly! I think some users will complain still.
Therefore, I wanted to discuss the possibility:
Of checking during Virtualmin installation if mail delivery support works on a system where the mail is enabled and the default host domain exists and matches the myhostname line in the Postfix config — if not supported, then we would disable it during installation time using nocheck_forbidden_domain_features option.
How can this be checked anyway?
Update the installation documentation for Virtualmin, suggesting that if a user intend to use the Virtualmin system for mail, and using hostname for mail with virtual domains map as well, they should also pre-create an additional DNS record for mail, such as mail.hostname. During installation, we would check if a DNS record like mail.hostname exists. If it does, and it points to the same system as hostname, then we set the myhostname option in Postfix to that.
For example, the Virtualmin installer asks the user to enter a hostname as an FQDN. The user enters host10.example.com. We then automatically check (actually we’d check either way) if mail.host10.example.com exists and if it points to the same system as host10.example.com. If it does, we set myhostname = mail.host10.example.com. Later, the installer will add host10.example.com as the default domain, where mail delivery works fine without Postfix complaining, and first experience of Virtualmin being smooth without having SSL certificate errors when visiting host10.example.com:10000 for the first time.
Could that be a solution?
Or just duck it and let users do their thing!? After all, you and @Joe always said this warning is as harmless as a kitten in a mitten in here and here.
Though seriously, for the moment, I’m gravitating towards 2. option!
When I said it was harmless, I also said, “Don’t do that.” And, I still say “Don’t do that.”
If you just don’t do that, you won’t have this problem. Name your server literally anything else. The world is wide and possibilities are endless, there is no reason to name your server the same thing as virtually hosted domains. None.
It isn’t a problem unless you make it a problem. I’d rather we do something to discourage people from making it a problem, rather than working around the problem.
Every possible reason people think they have for naming their server the same as something virtually hosted on the server is a misunderstanding. (Most often something misunderstood about PTRs and spam filters, but there are others.)
It is true. There isn’t for you, and there isn’t for me. Though people still do, and most probably will.
This discussion I brought up is more about what we can do to save users from falling into this trap.
We could keep saying “don’t do it,” or we can try to find a solution that makes it harder for users to misconfigure things while still allowing them to do what they think is right, even if it’s based on a misunderstanding.
