macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Configuring sendmail on Jaguar

by James Duncan Davidson, speaker at the O'Reilly Mac OS X Conference
09/10/2002

Sendmail is complicated software, no doubt about it. But sendmail is also the Swiss Army Knife of mail servers, and I don't mean one of those little key-chain trinkets. Instead, it's the monster three-inch wide kind with all the tools, most of which you have never seen before and have no idea what they do. However, with a little time and patience, you too can become proficient enough with sendmail to make it accomplish everything you need.

This article will help you understand the most useful of the tools that sendmail gives you and will serve as a companion to the article titled Setting Up a Site Server with Jaguar by filling in the sendmail configuration issues that we touched on there.

Here's what I'll cover in this article:

  • Dealing with Jaguar's permissions and sendmail
  • Working with Configuration files
  • The LUSER_RELAY
  • How to set up aliases
  • How to allow relaying from certain hosts
  • Running behind a firewall
  • Working with lame ISPs

Be warned, this is not a beginner's article. If you're uncomfortable performing shell commands as root on your system with sudo and editing files with vi, emacs, or pico, then there is a high likelihood that you'll get a bit lost here. However, if you do have a bit of shell experience, and I haven't scared you off by mentioning the word emacs, then this should be just the quick reference guide you need.

On Permissions and Blame

The number one "trick" to setting up sendmail on Mac OS X is dealing with the way that Apple has configured the permissions on the various directories on the filesystem. You see, in its quest to make Unix more "Mac like," Apple decided that it would be best to allow users, at least administrative users, to be able to move files in and out of the root directory with impunity. Apparently Apple doesn't want users to see a "You can't drag that file here!" dialog box.

This clashes heavily with sendmail's built-in paranoia. You see sendmail really wants any directory that it is involved with to be only modifiable by the root user. This includes the '/' and '/Users' directories. It will complain bitterly and refuse to startup with a statement that looks something like the following:

/etc/mail/sendmail.cf: line 93: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory

There are two primary solutions to this problem:

  1. Change the ownership of the '/' and '/Users' directories to something that sendmail prefers (ie, `chmod g-w / /Users').
  2. Configure sendmail to ignore its instincts and to operate even though the permissions on some folders aren't exactly as it likes.

In Setting Up a Site Server with Jaguar, I gave the recommendation to use the first of these solutions. I instructed readers to change the ownership, edit the sendmail startup script to make sure that these permissions are correct on system startup, and even add a cron job that fires every hour to make sure that things stay right even if a system update changes things back.

I'll go on the record right now and confess that this is an extreme solution. It is, as Chuq Von Rospach (who has many moons of experience working with sendmail) wrote to me in an email "Using a machine gun on a mosquito." I wholeheartedly agree with him, but it the absolute safest way to set your server up. It is the correct solution for the paranoid system-administrator who wants to make sure that nobody, not even any of his users, can compromise the system. It does have the side affect that nobody, not even the administrator, will be able to use the Finder to copy files into the '/' and '/Users' directories.

On the other hand, as long as you trust every person you give a user account to (or at least every user that you allow to administer your machine), there is a better way to go about this. This is to use the DontBlameSendmail configuration parameter with sendmail. Think of it as the administration of a small amount of medication to sendmail to reassure it that not everything in the world is a risk.

After debating the point with Chuq (as well as thinking about it a while), I've decided that using DontBlameSendmail is good enough for my server and me. As to which you should do: consider your situation. If you're only going to give people you trust accounts on the machine and you have a reasonable acceptance of risk, then DontBlameSendmail is the way to go. However, if you can't trust your users, or if you are maximally paranoid, then change the permissions on your directories.

If you are going to not blame sendmail, then there are two ways in which we can administer this medication. The first is to edit the /System/Library/StartupItems/Sendmail/Sendmail startup script in order to use the following commands to start up sendmail:

/usr/sbin/sendmail -OdontBlameSendmail=GroupWritableDirPathSafe -bd -q1h
/usr/sbin/sendmail -OdontBlameSendmail=GroupWritableDirPathSafe -C /etc/mail/submit.cf -q1h

This does a pretty good job. However, some of the other commands that you will find yourself working with will still complain about group writable directories if you do this. A better way is to modify the configuration files in the /etc/mail directory that sendmail uses. Before we do that though, we have to take a look at how to work with sendmail's configuration files.

Pages: 1, 2, 3, 4, 5

Next Pagearrow