That was the hard part. Now we only need to tell sendmail what to do with incoming mail, what local hostnames are legitimate and which users, networks and domains may use the SMTP gateway to relay mail not destined locally.
The mailertable is used to define delivery rules. It has a simple syntax, which is described in /usr/share/doc/sendmail/README.cf or /usr/share/sendmail/README depending on your distribution. In a nutshell, each line contains two parts: a destination identifier and an action. The destination identifier matches destination addresses or parts thereof; the action tells sendmail what to do with messages whose destinations match the identifier.
If the identifier begins with a “.”, then all e-mail source addresses ending in whatever follows the dot will match. If it doesn't, then everything following the “@” sign must be identical to the identifier. The e-mail address email@example.com won't match the identifier polkatistas.org but will match .polkatistas.org.
The action takes the form agent:action where agent is either a mailer (defined in sendmail.mc/linux.mc in MAILER() statements) or the built-in agents “local” or “error”. The “local” agent, of course, means the mail should be delivered to a local user, specified after the colon (if nothing follows the colon, the user specified in the message itself will be used).
Below is a mailertable with two different actions:
polkatistas.org smtp:internalmail.polkatistas.org mail.polkatistas.org local:postmaster
In addition to delivery rules, sendmail needs to know which e-mail destinations should be considered synonyms of the local (SMTP gateway's) hostname. These are specified in /etc/mail/local-host-names, one per line:
mail.polkatistas.org weird-al.polkatistas.org 220.127.116.11Finally, we need to define allowed relayers by editing /etc/mail/access. The syntax is simple. Each line contains a source name or address, paired with an action (again, see README.cf or its equivalent on your distribution for details). The action can be RELAY, REJECT, DISCARD, OK or ERROR. In practice, the most useful of these actions is RELAY. Because by default relaying is rejected, REJECT and DISCARD are only useful when defining exceptions to explicit RELAY rules.
Here is a simple access file:
localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY 192.168 RELAY
Do you notice the absence of real hostnames in the example above? In this example, the SMTP gateway performs only outbound relays; inbound mail must be addressed to a local e-mail address, and outbound relays must originate from hosts whose IP addresses begin with the octets 192.168 (obviously a noninternet-routable network). I like this technique (using IP addresses) because then I can prevent IP address spoofing with my firewall rules, but I can't prevent forged From: addresses in e-mail (however, your needs may be different of course):
access local-host-names mailertable
SMTP AUTH (in sendmail version 8.10 and later) adds authentication to SMTP transactions, e.g., to determine whether to permit relaying. This is especially useful when systems or users don't run their own MTA but need to send mail, i.e., need to relay outbound mail through a central gateway.
If you're running an SMTP server that relays mail from other domains, you probably want this feature, as it's an important defense against unsolicited commercial e-mail, the perpetrators of which rely heavily on SMTP relays.
There's just one more file that may need tweaking: aliases. This file contains a map of e-mail aliases to user names. Usually an SMTP gateway doesn't need a very granular alias database; to translate entire domains' (or virtual domains') e-mail addresses you're better off using the user database (which, sadly, I don't have space to cover). It's fairly self-explanatory, though, so edit it if you need to.
Now three of the four files we've just discussed, mailertable, access and aliases, actually can't be used by sendmail directly; they must first be converted to databases. The /etc/mail file contains a handy Makefile for this purpose. To use it simply change your working directory to /etc/mail and enter this command:
Make access.db mailertable.db
Note that this won't work for aliases, which has its own utility, newaliases. Run newaliases without any flags to convert your changed /etc/aliases file into a new /etc/aliases.db file automatically.
And that's it for now. There's much I haven't covered, notably the smrsh shell (applicable mainly to local mail delivery, not to gateways). But hopefully I've given you some useful hints and pointers to more complete sources of information. Good luck!
Mick Bauer (firstname.lastname@example.org) is a network security consultant in the Twin Cities area. He's been a Linux devotee since 1995 and an OpenBSD zealot since 1997, and enjoys getting these cutting-edge OSes to run on obsolete junk.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide