Using Postfix for Secure SMTP Gateways
As cool as that was, it may not have been enough to get postfix to do what needs to be done for your network. And even if it was, it behooves you to dig a little deeper: ignorance nearly always leads to bad security. Let's take a closer look at what we just did, and then move on to even niftier postfix tricks.
First, why did so little information need to be entered in main.cf? The only thing we added to it was our fully qualified domain name. In fact, depending on how your machine is configured, it may not have even been necessary to supply that!
This is because postfix uses system calls such as gethostname to glean as much information as possible directly from your kernel. If given the fully qualified domain name of your host, it's smart enough to know that everything past the first “.” is your name-domain, and it sets the variable mydomain accordingly.
You may need to add additional names to mydestination if your server has more than one FQDN (that is, multiple “A” records in your domain's DNS). For example, if your SMTP gateway doubles as your public FTP server, and thus has the name “ftp” associated with it in addition to its normal host name, your mydestination declaration might look something like this:
mydestination = $myhostname, localhost.$mydomain, ftp://www.$mydomain, $mydomain
It's important that any name by which your server can be legitimately referred to is contained in this line.
There were two other interesting things we did in the “quick and dirty” procedure. One was to start postfix with the command postfix start. Just as BIND uses ndc to control the various processes that comprise BIND, the postfix command can be used to manage postfix. Like BIND, postfix is actually a suite of commands, dæmons and scripts rather than a single monolithic program.
The most common invocations of the postfix command are postfix start, postfix stop and postfix reload. Start and stop are obvious; reload causes postfix to reload its configuration files without stopping and restarting. Another handy one is postfix flush, which forces postfix to immediately attempt to send all queued messages. This is particularly useful after changing a setting that you think may have been causing problems—in the event that your change worked, all messages delayed by the problem go out immediately. They'd go out regardless, but not as quickly.
The other thing we did was to add a line to /etc/aliases to divert root's e-mail to an unprivileged account. This is good healthy paranoia: we don't want to have to log in as the superuser for mundane activities such as viewing system reports, which are sometimes e-mailed to root. Be careful, however: if your unprivileged account uses a “.forward” file to forward your mail to some other system, you may wind up sending administrative messages over public bandwidth in clear text!
As alluded to in the quick and dirty procedure, aliases are also useful for mapping e-mail addresses for users who don't actually have accounts on the SMTP gateway. This practice has two main benefits. First, most users prefer meaningful e-mail names and short host /domain names, e.g., “firstname.lastname@example.org” rather than “email@example.com”. Second, you probably don't want your users connecting to and storing mail on a publicly accessible server. Again, common sense tells us that any server the unwashed masses can commune with must be kept at arm's length. The greater the separation between public servers and private servers, the better. (And don't forget, POPmail passwords are transmitted in clear text!)
Still another use of aliases is the maintenance of mailing lists. An alias can point to not only an address or comma-separated list of addresses, but also to a mailing list. This is achieved with the :include:tag—without this, postfix will append mail to the file specified rather than using the file to obtain recipients. (This is a feature, not a bug; it's useful sometimes to write certain types of messages to a text file rather than to a mailbox.)
Here's part of an example alias file that contains all of these types of mappings:
postmaster: root mailer-daemon: root hostmaster: root root: bdewinter mailguys: bdewinter,mick.bauer mick.bauer: firstname.lastname@example.org clients: :include:/etc/postfix/clientlist.txt spam-reports: /home/bdewinter/spambucket.txt
One warning: if an alias points to a different mail server, that server must belong to a domain for which the SMTP gateway is configured to relay mail (i.e., either that server's FQDN or its domain must be listed in the mydestination declaration in main.cf).
Don't forget to run either newaliases or, hipper still, postalias /etc/aliases anytime you edit aliases. The postalias command is hipper because it can accept any correctly formatted alias file as its input. Both commands compress the alias file into a database file that can be searched repeatedly and rapidly each time a destination address is parsed; neither postfix nor sendmail directly use the text version of aliases.
If you have a large number of users and/or internal mail servers, alias-file updates lend themselves to automation, especially via Secure Shell (ssh) and Secure Copy (scp). Using scp with null-passphrase RSA (or DSS/El Gamal) keys, your internal mail servers can periodically copy their local alias files to the SMTP gateway, which can then merge them into a new /etc/aliases followed by postalias /etc/aliases. (Unfortunately, telling you exactly how to use scp/ssh is beyond the scope of this article.) This practice is especially useful in large organizations where different people control different mail servers: day-to-day e-mail account administration can be kept decentralized.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Readers' Choice Awards
- BASH script to log IPs on public web server
2 hours 43 min ago
6 hours 19 min ago
- Reply to comment | Linux Journal
6 hours 51 min ago
- All the articles you talked
9 hours 15 min ago
- All the articles you talked
9 hours 18 min ago
- All the articles you talked
9 hours 19 min ago
13 hours 44 min ago
- Keeping track of IP address
15 hours 35 min ago
- Roll your own dynamic dns
20 hours 48 min ago
- Please correct the URL for Salt Stack's web site
1 day 9 sec ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?