These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Run email domain lookup server? on the new forum.
In the Virtualmin Pro post-installation wizard ... on the first screen, there's and option:
Run email domain lookup server?
If I do not use vmin for email accounts (that is users don't get email accounts hosted by vmin, they are hosted by our email service) ... is there any reason to run this?
no, you just need to add the correct mx records in the filezones.
I'd like to know what that question really means. What is the consequence of responding with 'yes'?
Upon receiving an email, Virtualmin determines which Virtual Server the email belongs to.
At that point, the individual Virtual Servers settings are considered when dealing with the email.
The question is asking whether you want to run the daemon process, which uses some RAM, but ultimately saves CPU and disk IO -- or whether you wish to not use the lookup daemon, and launch the command line lookup process each time.
I typically would recommend using the daemon, unless you're really low on RAM.
-Eric
Eric, do I understand it well that when I turn off this daemon process there will not be accidental internal delivery when there is a site configured on the server which is currently not hosted on this server?
I noticed this once when someone moved to another hosting provider but wanted to leave the account on the server in order to be able to switch back easily. If I can save RAM and overcome this problem both I might consider turning off this daemon.
That daemon assists in determining what Virtual Server a given email belongs to.
If it's not running, that information still needs to be figured out... so rather than querying a daemon, a standalone process is temporarily launched for each incoming email that determines that same information.
It can save RAM if you don't receive many incoming emails.
As far as local versus remote delivery issues -- you'll run into a lot of problems there unless "Mail for Domain" is disabled.
So long as Postfix is configured to deliver email for a given domain locally, it'll try to do so, which may not be what you want. The way to resolve that would be to go into the features for the Virtual Server, and uncheck the Mail for Domain feature, which would prevent local delivery if the mailbox is at a remote location.
This also assumes that if there's an MX record setup on your server for that account, that it points to the remote location. If not, you'd either want to configure that.. or if DNS is being managed externally, you'd want to disable the "DNS Domain" feature.
-Eric
Ok, it won't solve the issue then, just a choice between memory and performance.
From a theoretical viewpoint removing the zone would make most sense (because it simply has outdated not to be used information).