Configure local mail delivery

Configure Local Mail Delivery

If your DNS is not set up properly, or you change the hostname after installing Mail Toaster, then local mail delivery may not be set up properly. In this context, we are referring to local mail delivery as mail destined to the hostname the mail toaster is running on. For example, you may have mail.example.com set up to host email for the domain example.com. But example.com is not local, it is virtual. The "local" domain would be mail.example.com.

So where does mail to user@mail.example.com go?

If the hostname and DNS were set up properly when you build your Mail Toaster, then mail.example.com was added to control/locals. Any domain there is considered local. Emails sent to user1 would map to the system user named "user1." Your nightly reports and cron emails are typically sent to root@mail.example.com. If you don't have "mail.example.com" set up in locals, then those messages will doublebounce and be discarded.

The best solution is to tell qmail that mail.example.com is local. You can do this as follows:

 echo "mail.example.com" >> /var/qmail/control/locals

There is one more catch. For security reasons, qmail does not deliver mail to the root account. So, you must set up an alias in ~alias. Mail Toaster does that for you automatically. The contents of ~alias/.qmail-root are kept up-to-date based on the value of the postmaster account set in toaster-watcher.conf.

One Alternative: For Internal Use Only

If for some reason you want to actually use mail.example.com as a virtual domain, then you can add it as you normally would any virtual domain (i.e. vadddomain). The main advantage of this is when you would like to use some special email accounts (although less user-friendly) which could mean something to your organization internally. This is a perfect virtual domain for testing and administration purposes. It is not the type of domain email you would tell your friends about. And remember that DNS is generally already setup for immediate use of this virtual domain.

For example, you could receive root@mail.example.com as the server's administrator, plus send internal-only email to your boss at Big.Kahuna@mail.example.com. Meanwhile, these accounts have no relation to you more standard official emails like webmaster@example.com and Joe.Smith@example.com. You might also get special Toaster mail on this internal virtual domain, like notices from your anti-virus program, etc.

Some strange uses of this test domain? Well, Microsoft used to have a "feature" in Outlook called "Net Folders." This required the use of internal POP accounts, and was solved by using such a virtual domain. This made more sense than using a made-up virtual domain name, or even the literal "example.com" domain.