Learning the Mac OS X Terminal, Part 2
Pages: 1, 2

Mail user agents (MUAs) are the kinds of applications that allow you to personally send, receive, and otherwise work with your email messages. Outlook, Eudora, and Mac OS X's Mail application are other familiar examples of MUAs.

Mail transfer agents (MTAs), on the other hand, are the not-so-familiar applications that receive the messages from the MUA and pass them on to other users on the same machine, or to MTAs on other machines for ultimate delivery to users elsewhere. The sendmail MTA included with OS X is one of the most popular, used on servers large and small across the Internet.

Since you are not running your own mail server at this point, you don't need sendmail to be running at all times. Instead, you only need to ensure that sendmail launches when invoked by mail to send the cron reports. Used this way, sendmail quits itself once delivery is made.

For sendmail to successfully launch, however, one issue needs to be "fixed" on your system. As a security measure, sendmail will not run with OS X's default permissions (termed "privileges" in the Finder), namely those for the root directory.

This fix involves one simple change: eliminating write privileges for the group assigned to the root directory. The CLI makes it very easy to view and change the various permission settings for any item, but the procedures are still too involved to detail here. (Of course, Mac OS X: The Missing Manual does include an in-depth look at permissions and the CLI.)

Instead, I'll zero in on the single command line required to get sendmail going:

sudo chmod  g-w /

Since you're modifying the settings for a root-owned directory, the command line starts with sudo. Next comes the chmod command, for "change (file) modes." File modes are the settings that specify whether an item can be read or written to, for example, and by which kind of user -- the owner of the item, its group, or any user of the machine. (These settings correspond, of course, with the Privileges settings that are accessible via Finder's Inspector.)

Following a space are chmod's "arguments," the first of which specifies the modes to be changed (option flags are just another kind of argument, by the way). This argument says to take the group ("g") and remove ("-") its permission to write ("w") to the file or directory specified in the next argument (again followed by a space), which in this case is the root directory, ("/").

Your next step, then, is to run the command line:

[localhost:~] chris% sudo chmod  g-w /

Once you do, sendmail should work fine. However, you should know that Mac OS X upgrade installers and some application installers change the root directory back to group-writable, so you'll need to run the chmod command line whenever this happens.

To test everything so far, try sending mail from the CLI. Use the mail command to send mail to root (which, at this point, will get forwarded on to you) like this:

[localhost:~] chris% mail root
Subject:

You're now working inside the mail CLI application, so you'll see no more tcsh shell prompts until you exit mail. Enter any subject you would like and press return. Type in your message at the cursor. To end your message, send it, and exit mail, press return, type a period, and press return again. You'll then return to your shell prompt:

After a few moments, check your mail by entering the mail command again, but this time with no arguments. Until the message arrives, you'll only see that your box is empty when you run mail:

[localhost:~] chris% mail
No mail for chris

However, once it arrives you'll see something like this:

[[localhost:~] chris% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/mail/chris": 1 message 1 new
>N  1 chris                 Sat Jan  5 15:30  13/374   "Test"
&

You're back in the mail application, but this time to view your new message. Press return at the "&" prompt to have a look:

Message 1:
From chris  Sat Jan  5 15:30:01 2002
Date: Sat, 5 Jan 2002 15:30:00 -0800 (PST)
From: Chris Stone <chris>
To: root
Subject: Test

This is only a test.

& q
Saved 1 message in mbox
[localhost:~] chris%

As you can see, the test message stays in your local Unix mailbox when you quit mail. Note that this and any other messages there will disappear as a result of the following procedure. However, if this tutorial is new to you, it's very unlikely that you have other messages there anyway. (Of course, your POP and IMAP mail will stay safe and sound.)

You're now ready to set up your GUI Mail application so it can access your local Unix mailbox. Since you will be modifying the folder in which Mail stores its mail, ~/Library/Mail, you should first make a backup of it to, say, your Documents folder:

[localhost:~] chris% cp -R Library/Mail/ Documents/Mail

Here are some important points about this command line:

• Because you are copying a directory, cp requires you to use its -R option flag (for "recursive").


• The pathnames are not absolute, but "relative" to your working directory. Instead of including the entire pathname from the root directory down, with relative pathnames you can specify a shorter path that begins from the end of your working directory. (Always remember to omit a leading / in relative pathnames.)


• The target pathname, Documents/Mail, doesn't specify the directory in which you would like Library/Mail/ to go, but the desired new relative pathname of the copied directory.


• If this command line could talk, then, it would be telling the shell, "Please make a copy, including all contents, of the directory indicated by the first pathname. When you're done, the pathname of the new directory is to be the same as this line's second pathname."

Something else you should know about cp is that it does not properly copy files with resource forks, so you should never use it for that. You'll never have a problem copying Unix and Cocoa applications and related files, which don't contain resource forks, but if you are unsure, use the Finder to copy (or have a look at Mac OS X: The Missing Manual for an explanation of using CpMac, which does handle resource forks reliably).

The next step is to make the directory that Mail requires before it can create a Unix mail account. The directory must exist in ~/Library/Mail/ and be named "UNIX:@". To create a directory from the command line, use the mkdir command, followed by a space and the name of the new directory.

However, if there is no Mail directory already inside ~/Library, the command will return an error. To prevent this possibility, use mkdir's -p option flag, which will create any intermediate directories for you if they are missing.

[localhost:~] chris% mkdir  -p Library/Mail/UNIX:@

Next you'll need to open Mail and create a Unix mail account, which requires just a few simple steps:

1. Open the Mail application, found in /Applications.
   

   Sure, you can just double-click its icon to open it in the Finder, but since you're in Terminal anyway, how about opening it from there? To do so, just use the open command (don't forget to include the normally-hidden extension at the end):

   [localhost:~] chris% open /Applications/Mail.app
   

   Mail launches immediately, just as if you had opened it from the Finder.

   If you've never used Mail before and have no email account info entered in your System Preferences, you'll be prompted to set up an initial account. At a minimum, you'll need to enter an email address, so enter anything you would like; it won't affect the setup of your Unix mail account.

   You can safely click through the other prompts for server and other info, and to import mail from other applications. None of this is needed for the task at hand.

2. Create a new Unix mail account.

   From Mail's Mail menu, select Preferences, and then click the Accounts icon. In the Accounts pane, click Create Account. To configure the account, you'll at least need to select the account type (Unix Account), enter a description (Local), and enter something -- anything, really -- in the SMTP Host field.

   Of course, if you need to set up a bona fide Unix account, all of these fields mean a great deal. However, for the purpose of only accessing your local Unix mail, this is all you need to configure:

   
   

3. Click OK, close the Preferences window, and you're all set.

   If you are already using Mail to check your regular POP and IMAP accounts, this additional account will not affect those in any way, except that new mail from your Unix account will show up in your default inbox. Of course, if you would like, you could create a new mailbox and a rule to have the incoming cron reports be placed there instead.

Now that everything's in place, you can perform a test. Send a new mail message to root:

[localhost:~] chris% mail root
Subject: Test 2
This is only a test, again.
.
EOT
[localhost:~] chris%

Switch to Mail, and then click Get Mail until you see the message has arrived in your Inbox:

If you see the test message in your inbox, then you're done. The next time cron runs one of the maintenance jobs, you'll see the report in your inbox as well. For example, the daily cron job report will look something like this:

Now that these regular reports will be coming in, you'll probably want to be able to understand them. In Part 3, you'll get a closer look at the scripts themselves to learn how to read the reports they generate.

Also in Part 3, I'll show how a Macintosh with a persistent Internet connection can send its reports to any email address. Until then, keep checking to see that you're receiving the reports as expected, and always feel free to submit your comments or questions to our TalkBack section.

I'd like to thank Scott Gever for his techincal help with this series.

Chris Stone is a Senior Macintosh Systems Administrator for O'Reilly, coauthor of Mac OS X in a Nutshell and contributing author to Mac OS X: The Missing Manual, which provides over 40 pages about the Mac OS X Terminal.

---

Return to the Mac DevCenter.