If you're a Red Hat user, you have only one step prior to configuring sendmail: edit /etc/sysconfig/sendmail so that the variable DAEMON is set to “yes”. This will tell the startup script /etc/init.d/sendmail to start sendmail as a dæmon at boot time.
And now, at last, we configure sendmail to act as our domain's SMTP gateway. What follows applies to any installation of sendmail 8.9 or higher (you shouldn't in any circumstances run 8.8).
The simplified method of generating sendmail configurations (sendmail.cf and accompanying files) consists of these steps:
Enable needed features in sendmail.mc.
Set up domain-name masquerading, if needed, in sendmail.mc.
Run m4 to generate sendmail.cf from sendmail.mc.
Configure delivery rules by editing mailertable.
Configure relaying rules by editing access.
Configure local user-aliases in aliases.
Convert mailertable, access and aliases to databases.
Define all local hostnames in local-host-names.
The first and probably longest task in setting up an SMTP gateway is generating /etc/sendmail.cf. This is done most easily by editing /etc/mail/sendmail.mc (or on SuSE systems, /etc/mail/linux.mc—it may be different on other distributions).
Depending on which Linux distribution you use, configuration information for sendmail.mc can be found in /usr/share/doc/sendmail/README.cf (Red Hat and its derivatives), /usr/share/sendmail/README (SuSE) or some variant thereof. I don't have enough space to describe the syntax of the many settings in this file in detail. We will, however, look at some that are useful for security and for modularizing our configuration a bit.
In addition to sendmail.cf itself, we can configure sendmail to read several other files for configuration information. This is useful for two reasons. First, editing sendmail.cf directly is unpleasant and even regenerating it from sendmail.mc isn't always desirable. Second, if your SMTP gateway has multiple administrators with varying privileges, you may wish to keep sendmail.mc and sendmail.cf locked down but allow other administrators to edit user aliases or mail delivery rules (i.e., /etc/mail/access and /etc/mail/mailertable, respectively).
The most useful external configuration files to enable are mailertable, which defines local mail-delivery rules; virtusertable, which defines virtual domain mappings on a per-user and per-domain level; and access, which defines which hosts may use the server as an SMTP relay.
The sendmail.mc directives for enabling these files are shown below:
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(`access_db',`hash -o /etc/mail/access.db')dnl
(Note that the mailertable and access_db features are enabled by default under Red Hat, but that virtusertable must be added manually.)
Each of these lines tells sendmail to reference the specified file (although the access database is called access, not access_db), to use a hash database and the path of the respective file. We'll see how to use these files shortly, but first we've got a few more things to attend to in sendmail.mc.
If your users' e-mail addresses are generic to your domain rather than specific to the hosts they log on to, for example, email@example.com rather than firstname.lastname@example.org, you probably want the From: fields of their outbound e-mail to reflect this. (Receiving e-mail addressed to those generic names requires user aliases—see below.)
Following are some sendmail.mc lines that tell our example SMTP gateway to rewrite the From: fields of polkatistas.org's users in this manner. All the lines in the example below must be added (or uncommented):
MASQUERADE_AS(`polkatistas.org')dnl MASQUERADE_DOMAIN(`.polkatistas.org')dnl EXPOSED_USER(`root')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl
The MASQUERADE_AS directive specifies the fully qualified domain name you wish to appear in applicable From: addresses. The MASQUERADE_DOMAIN directive specifies the hosts to which MASQUERADE_AS is applicable. Note that the “.” preceding polkatistas.org indicates that all hostnames with this domain name are to be masqueraded.
EXPOSED_USER specifies a user name for whom the From: address should not be masqueraded. root is a popular candidate for this because e-mail from root often contains alerts and warnings; if you receive one, you generally want to know which host sent it.
The feature masquerade_entire_domain causes MASQUERADE_DOMAIN to be interpreted as an entire domain rather than a hostname; masquerade_envelope applies the masquerading not only to the SMTP header but to the envelope as well.
Four other directives, one logistical and the other three security-related, are shown in Listing 1. The always_add_domain feature is enabled by default under Red Hat and SuSE; use_cw_file and smrsh are enabled in Red Hat but not SuSE; confSAFE_FILE_ENV always must be defined manually.
The always_add_domain feature simply forces the local host's domain name to be appended to any e-mail originating from a host that identifies itself without a domain. For example, if the SMTP gateway receives mail from the user “bobo” on a host identified only as “whoopeejohn”, sendmail will rewrite the From: field to read email@example.com rather than bobo@whoopeejohn (but of course masquerading directives still apply).
The use_cw_file feature tells sendmail to refer to the file /etc/mail/local-host-names for a list of hostnames sendmail should consider local. The file /etc/mail/local-host-names is a text file containing hostnames listed one per line. Suppose our example SMTP gateway receives e-mail not only for the domain polkatistas.org, but also tubascoundrels.net. If our gateway's hostname is “mail”, then its local-host-names file will look like this:
localhost.localdomain mail.polkatistas.org mail.tubascoundrels.net
The third feature enabled in Listing 1 is smrsh, the sendmail restricted shell. This is an important security control that restricts the commands that may be executed from a user's .forward file.
The fourth line in Listing 1 tells sendmail to set sendmail.cf's SafeFileEnvironment variable to, you guessed it, some subdirectory of / that sendmail will chroot to (sort of). Actually, this only will happen when sendmail writes files. If you think about it, though, this 50% chroot makes sense: file-writes are what we're probably most worried about, and creating this sort of chroot environment is a lot simpler than your typical chroot jail (which must contain copies of every file hierarchy, file, executable and device your chroot-ed program needs).
Listing 2 shows a recursive listing (ls -lR) of my example SafeFileEnvironment /var/mailjail.
Sendmail created the files /var/mailjail/var/spool/mqueue/bobo and .../root. Beforehand, I had created the entire chroot jail with only four commands:
mkdir -p /var/mailjail/var/spool/mail /var/mailjail/var/spool/mqueue cd /var/mailjail chown -R mail:mail * chmod -R 700 *
If you're concerned about unsolicited commercial e-mail, there's some good news. By default, sendmail doesn't allow SMTP relaying, a common technique of spammers. This can be disabled in sendmail.mc, but you won't find out how from me. Leave this alone. In addition, you can direct sendmail to reject mail from known sources of spam, per the Realtime Blackhole List (RBL), by adding or uncommenting this line:
FEATURE(`dnsbl')For this to work, however, you need to subscribe to the RBL. See Resources for a link to its home page, where you'll find subscription and use instructions and some important disclaimers. (Note that while RBL subscriptions are free for “Individual/Hobby Sites”, there is a fee-schedule associated with this service.) Using the RBL can block e-mail from some legitimate users as well as from spammers, so proceed with caution.
If you run Red Hat 7.1 or 7.2, there's one more sendmail.mc parameter to check, this time one that needs to be commented out. If your /etc/mail/sendmail.mc contains a line like this:
Then you need to comment it out by appending the string dnl to the beginning of the line. If active, this line will cause sendmail to accept only connections on the loopback interface and not from external hosts. Needless to say, for an SMTP gateway this is undesirable (though it unquestionably enhances security).
Those are the most important sendmail.mc settings for our purposes. There are others relevant to security, especially for nongateway roles (local delivery, etc.). For more information see the README.cf or README file I alluded to at the beginning of this section.
To compile our macro-configuration file into sendmail.cf, we use this command:
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
If your macro-configuration file's name isn't sendmail.mc, substitute it with linux.mc or whatever your macro-configuration file is called. Sendmail expects its configuration file to be named sendmail.cf; however, it looks for it in /etc, so that part of the command is the same regardless of your distribution or even your version of sendmail.
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!
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader 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