Not-so-stupid Postfix tricks

Last time we talked about how to get a simple installation of Postfix up and running. Once your organization becomes relatively complex, you will find yourself wanting to do things with email that may not seem immediately important. The first and most important thing is, of course, that the mail flows and that you can send and receive. I’m willing to bet that the first enhancement that comes to mind for people is spam control, or unsolicited commercial email (UCE). But that, as they say, is just the beginning. On that note, I’m going to save the best for last — or is it the worst?

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:

info@mycompany.dom

info@myseconddomain.dom

info@myinfosite.dom

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:

info: mary@somedomain.dom

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:

username@somedomain.dom realuser@someotherdomain.dom

In the case of my info example, my virtusertable would look like this:

info@mycompany.dom         mary@localdomain.dom
info@myseconddomain.dom    tom@remotedomain.dcom
info@myinfosite.dom        natika@bigschool.edu

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:

postmap hash:/etc/postfix/virtusertable

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 myinfosite.dom to andy@mycompany.dom:

@myinfosite.dom andy@mycompany.dom

Once again, recreate your virtusertable database, and you are on your way.

postmap hash:/etc/postfix/virtusertable

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 postmap command.

postmap hash:/etc/mail/access

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:

always_bcc=adminuser@yourdomain.dom

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.

postfix 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:

http://your_server:10000/postfix/index.cgi