Using Postfix for Secure SMTP Gateways
E-mail is easily the most popular and important Internet service today, which has made it a popular target of cyber-criminals and spam-happy miscreants. Adding to the problem is the inescapable reality that configuring sendmail, the most commonly used Mail Transfer Agent (MTA), is complicated, nonintuitive and easy to get wrong.
Wietse Venema, intrepid developer of TCP wrappers and co-creator of SATAN, has come through for us again: his program, postfix, provides an alternative to sendmail that is simpler in design, more modular, easier to configure and less work to administer. Equally important, it's been designed with scalability, reliability and sound security as fundamental requirements.
This article is intended to bring you up to speed quickly on how to use postfix on your network as a secure means of receiving e-mail from and delivering it to Internet hosts. In particular we'll focus on deploying postfix on firewalls, in DMZs and in other settings in which it will be exposed to contact with untrusted systems.
Is sendmail really that bad? That depends on what you need it to do—the learning curve may not be justified if your e-mail architecture is simple. But sendmail is unquestionably an extremely powerful, stable and widely deployed application that isn't going away anytime soon, nor should it. In fact, The Paranoid Penguin will probably feature a sendmail article some time in the next few months.
Both sendmail and postfix are Mail Transfer Agents. MTAs move e-mail from one host or network to another. These are in contrast to Mail Delivery Agents, which move mail within a system (i.e., from an MTA to a local user's mailbox, or from a mailbox to a file or directory). In other words, MTAs are like the mail trucks (and airplanes, trains, etc.) that move mail between post offices; Mail Delivery Agents are like the letter-carriers who distribute the mail to their destination mail boxes.
In addition to MTAs and MDAs, there are also various kinds of e-mail readers, including POP, POP3, and IMAP clients for retrieving e-mail from remote systems. These are also known as Mail User Agents, or MUAs. (There is no real-life simile for these, unless your mail is handed to you each day by a minion whose sole duty is to check your mail box now and then!) But we're not concerned with these or with MDAs, except to mention how they relate to MTAs.
By the way, if you still use UUCP, it's supported in postfix (and continues to be in sendmail, too); most MTAs support a variety of delivery “agents”, almost always UUCP and SMTP at the very least. Still, for the remainder of this article we'll assume you're interested in using postfix for SMTP (Simple Mail Transfer Protocol) transfers.
One very common use of SMTP, especially in organizations which use other e-mail protocols internally, is on an Internet e-mail gateway. Since SMTP is the lingua franca for Internet e-mail, there must be at least one SMTP host on any network that needs to exchange e-mail over the Internet. In such a network, the SMTP gateway acts as a liason between non-SMTP mail servers on the inside and SMTP hosts on the outside.
This “liason” functionality in and of itself isn't as important as it once was; the current versions of Microsoft Exchange, Lotus Notes, and many other non-SMTP-based e-mail server products have no problem communicating with SMTP servers directly. But there are still reasons to have all inbound (and even outbound) e-mail arrive at a single point, the chief reason being security.
There are two main security benefits to using an SMTP gateway. First, it's much easier to secure a single SMTP gateway from external threats than it is to secure multiple internal e-mail servers. Second, separating Internet mail from internal mail allows one to move Internet mail transactions off the internal network entirely. The logical place for an SMTP gateway is in a DMZ (“Demilitarized Zone”) network, separated from both the Internet and the internal network by a firewall.
As with DNS, FTP, WWW and any other publicly accessible service, the more protection you can place between potential hackertargets and your internal network, the better. Adding an extra NIC to your firewall, keeping public services in a separate network, is one of the cheapest and most effective ways of doing this—as long as you configure the firewall to carefully restrict traffic to/from the DMZ). It's also good risk management; in the (hopefully) unlikely event that your web server, for example, is compromised, it won't become nearly as convenient a launch pad for attacks on the rest of your network.
(For additional information on the DMZ technique of firewalling, see the article </#147>Securing DNS and BIND</#148>, page 92 of this issue.)
Thus, even organizations with only one e-mail server should still consider adding an SMTP gateway, even if that e-mail server already has SMTP functionality.
But what if your firewall is your FTP server, e-mail server, etc.? Although the use of firewalls for any service hosting is scowled upon by the truly paranoid, this is common practice for very small networks (e.g., home users with broadband Internet connections). And, in this foul-weather paranoiac's opinion, BIND and postfix pose much less of an exposure for a firewall than other service applications.
For starters, DNS and SMTP potentially involve less direct contact between untrusted users and the server's file system. (I say “potentially” because it's certainly possible, with badly written or sloppily configured software, to create extremely insecure DNS and SMTP services.) In addition, both BIND and postfix have “chroot” options and run as unprivileged users, two features that help reduce the danger of either service being used to somehow gain root access (we'll discuss both of these options in depth shortly.)
|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|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Home, My Backup Data Center
- Android is Linux -- why no better inter-operation
1 hour 45 min ago
- Connecting Android device to desktop Linux via USB
2 hours 13 min ago
- Find new cell phone and tablet pc
3 hours 12 min ago
4 hours 40 min ago
- Automatically updating Guest Additions
5 hours 49 min ago
- I like your topic on android
6 hours 35 min ago
- Reply to comment | Linux Journal
6 hours 57 min ago
- This is the easiest tutorial
13 hours 11 min ago
- Ahh, the Koolaid.
18 hours 50 min ago
- git-annex assistant
1 day 49 min 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?