"Neither rain, nor sleet, nor snow. ..." SMTP (Simple Mail Transfer Protocol) gateways are the ubiquitous workhorses of the Internet today. People expect e-mail to be reliable and quick, so SMTP gateways always have to be highly available and work under a heavy-duty cycle. And now, with the growing crush of spam showing no signs of abating, SMTP gateways are asked to be secure, as well as perform a host of other functions beyond basic...
"store-and-forward" mail relaying.
Using Linux as the platform for this part of your network infrastructure makes good sense. The Linux kernel and file system can run unattended for years. Linux can easily be locked down to serve this single purpose and, because the tradition of SMTP mail is deeply rooted in open systems, there are several freely available, high-quality mail transfer agents (MTAs) available for your Linux boxes.
It doesn't hurt that a decent Linux-based MTA is inexpensive. For such an important part of your network, you definitely want redundancy. Think about it: Ever had to explain to your C-levels why they're not receiving their e-mail? You don't want to end up there, so implement those SMTP gateways with care. Fortunately, SMTP mail has been going strong for more than a decade, and there is a lot of know-how out there in the Linux community. Here are some tips for making this workhorse work well.
Do strongly consider using Linux-based SMTP gateways between the Internet and your primary internal mail server(s). Have you ever seen what a malformed SMTP header can do the SMTP connector on an Exchange server? Even if you have a high level of confidence in your e-mail server's security and capabilities, gateways provide another layer of redundancy and protection and can be useful for filtering and redirection in topologies that are growing and changing.
Do erect a test domain that is almost precisely the same as your production domain, save for the different name. You can use this test domain to experiment with new features and topologies before you implement them in your production environment.
Do configure monitors for system resources like memory, CPU, inode usage and file descriptor usage. Your MTA is not going to be happy if it can't open a socket or get a file descriptor, and SMTP relaying can use far more of these resources than other server applications.
Don't get caught in a situation where you have to maintain SMTP gateways but don't have administrative access to DNS. No name resolution means no mail delivery.Do use the Linux kernel's firewall features to enhance the security of your SMTP gateway by preventing access from unnecessary subnets. You may find Netfilter's "limit" target extremely useful in preventing denial-of-service attacks, in addition to limiting exposure to mailing loops and other non-malicious malconfigured topologies.
Don't try this at home. Several years back, another admin and I got our signals crossed and ended up creating a very tight mailing loop. Our primary SMTP gateway dutifully did what it had been configured to do, and pretty soon we had an exponentially increasing flurry of e-mails going through the system. By the time we figured out what was going on and reconfigured to prevent the loop, the box was out of file descriptors. I thought for sure that our only option was to reboot it, probably "forcefully" through a hardware reset. However, after a well-targeted "kill" of the appropriate PID and a restart of sendmail, the box picked up where it left off and went along its merry way.
About the author: Tony Mancill is author of "Linux Routers: A Primer for Network Administrators" from Prentice Hall PTR.
FOR MORE INFORMATION:
FEEDBACK: What Linux-based e-mail success stories or failures have you experienced?
Send your feedback to the SearchEnterpriseLinux.com news team.