This article is excerpted from the newly published book Moving to the Linux Business Desktop.
The multiple domain, similar address dilemma
Imagine for a moment that you have decided to register several domains, all of which reside on the same machine. After all, your Linux system is more than capable of handling the load and you don't want to bother starting from scratch for what might be low-traffic domains anyway. What you do want, though, is a standard method of getting information-only mail to your virtual companies. You might even want that mail to go to different places. Here's what you want in a nutshell:
Now, you can have only one info login on your system. If info is not a user on your system, you could add an info alias to direct info mail to a real user, rather than creating the pseudo-user. For instance, if mary was to get info's mail, you would have an
aliases entry like this:
The problem comes when you want all of these different info addresses to go to different people. You can't have two
alias entries for info. The way to get around this is to use the
virtusertable feature. Look for this line in your main.cf configuration file:
virtual_maps = hash:/etc/postfix/virtusertable
This will give you the path to the virtual user table and the means to set up these different domains with equivalent users. The format of the file is simple:
In the case of my info example, my virtusertable would look like this:
firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com
Finally, you need to get Postfix to start using the new database. From the /etc/postfix directory or wherever you have decided to configure the table, run this command:
The multidrop domain
Here's another scenario. Pretend that mail bound for myinfosite.org was all to go to one user because there is only one user at myinfosite.org. You don't want to lose important mail if people send to that address, but use Webmaster when you have only info set up as an alias. Generally, mail that is improperly addressed is probably not mail you want, but if you want to play it safe, how do you make sure that all mail gets through no matter whom it is addressed to within that domain?
Strangely enough, the answer is the same as in the previous section -- namely, your old friend
virtusertable. Here's an entry that directs all mail for
Once again, recreate your
virtusertable database, and you are on your way.
Stop the spam!
Here's a great tip for getting rid of some of the spam that keeps pounding your mail server. In case you've been away for a while, spam is a euphemism for unwanted email. The sheer bulk of spam directed at your server can slow things down to a crawl. When you run your own server, you aren't completely powerless. Start by adding the following to your main.cf configuration file:
smtpd_helo_required = yes
disable_vrfy_command = yes
The first of these two settings, smtpd_helo_required, specifies that any incoming server must identify itself with the HELO command. Failure to do so means that the email is dropped. While it shouldn't be a problem, you should consider that it is possible that emails from friends whose clients don't properly identify themselves might also get dropped. The second variable,
disable_vrfy_command, refuses VRFY queries, which a potential cracker might use to locate valid user names on your system.
Of course, spammers use a large number of annoying techniques to get past your system, including sending out email to thousands of people on your server and just hoping that some of the email addresses are valid. Because they are already relaying through a site other than their own anyway, they don't care if some of it bounces. It doesn't affect them. The problem is that it affects you. Many spammers also don't provide proper hostnames or return addresses, and sometimes the header information is completely invented. To reduce some of the traffic that falls into these categories, the following additions to main.cf might also be in order:
smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_unauth_pipelining permit_mynetworks, reject_non_fqdn_hostname
Another trick is to block access to email from particularly annoying domains. Here's an example: some time ago, I dealt with an incident of bulk emails being sent through a relay. The format of the spam was hundreds of email addresses to the same domain, mostly to users that did not exist on that system anyhow. Presumably, the spammers were looking to hit at least some legitimate email addresses.
The solution is to block all access from a particular domain in the
access database. You'll recognize this somewhat from our discussion of hash maps. The location of this file is defined by this variable:
smtpd_sender_restrictions = hash:/etc/postfix/access
Start by editing your
access file, and add the name of the domain you want to reject with the word "REJECT" separated by white space.
spammer.dom REJECT anotherspammer.dom REJECT
To activate the new
access database, use the
Track those emails
Sometimes, it may be necessary to track the email messages that make their way across your system. What are those reasons? You may have noticed an increase in email abuse, either internal or external, where forwarding a copy of each message to an administrator would be desirable. By using the
always_bcc parameter, a blind carbon copy of each message will be delivered to an administrative user of your choice. Since that person will be getting a lot of messages, it makes sense to create a temporary user account. Tracking and logging messages in this way can be quite a daunting task.
Here's how you do it. Edit your main.cf file and add the following line:
The adminuser is the one you created to receive a copy of all this email. Reload
postfix and that username will start receiving a copy of every email that goes across the system. To activate the feature, reload
Postfix via Webmin
Webmin provides extensive configuration options for Postfix, and you should certainly familiarize yourself with it. Webmin provides multiple modules to administer everything, including dealing with messages in the current mail queue, client and server restrictions, logging, and a whole lot more. You'll find Postfix configuration under Servers in Webmin, or you can just jump to it by entering the URL in your browser's location bar like this: