10.4.1 Profile Components

The following are short descriptions about profile components that are either necessary to using Hemlock's interface to MH or convenient for using MH in general: [annotate]

Path:

This specifies the user's mail directory. It can be either a full pathname or a pathname relative to the user's home directory. This component is necessary for using MH. [annotate]

MailDrop:

This is used to specify one's remote mail-drop. It is necessary for Hemlock only when using a mail-drop other than "/usr/spool/mail/<user>" on the local machine. [annotate]

Folder-Protect:, Msg-Protect:

These are set to 700 and 600 respectively to keep others from reading one's mail. At one time the default values were set for public visibility of mail folders. Though this is no longer true, these can be set for certainty. The 700 protection allows only user read, write, and execute (list access for directories), and 600 allows only user read and write. These are not necessary for either MH or the Hemlock interface. [annotate]

Unseen-Sequence:

When mail is incorporated, new messages are added to this sequence, and as these messages are read they are removed from it. This allows the user at any time to invoke an MH program on all the unseen messges of a folder easily. An example definition is: Unseen-Sequence: unseen Specifying an unseen-sequence is necessary to use Hemlock's interface to MH. [annotate]

Alternate-Mailboxes:

This is not necessary for either MH or the Hemlock interface. This component tells MH which addresses that it should recognize as the user. This is used for scan output formatting when the mail was sent by the user. It is also used by repl when it sets up headers to know who the user is for inclusion or exclusion from cc: lists. This is case sensitive and takes wildcards. One example is: Alternate-Mailboxes: *FRED*, *Fred*, *fred* [annotate]

Draft-Folder:

This makes multiple draft creation possible and trivial to use. Just supply a folder name (for example, "drafts"). Specifying a draft-folder is necessary to use Hemlock's interface to MH. [annotate]

repl: -cc all -nocc me -fcc out-copy

This tells the repl utility to include everyone but the user in the cc: list when replying to mail. It also makes repl keep an copy of the message the user sends. This is mentioned because one probably wants to reply to everyone receiving a piece of mail except oneself. Unlike other utilities that send mail, repl stores personal copies of outgoing mail based on a command line switch. Other MH utilities use different mechanisms. This line is not necessary to use either MH or the Hemlock interface. [annotate]

rmmproc: /usr/cs/bin/rm

This is not necessary to use Hemlock's interface to MH, but due to Hemlock's virtual message deletion feature, this causes messages to be deleted from folder directories in a cleaner fashion when they actually get removed. Note that setting this makes rmm more treacherous if used in the Unix shell. [annotate]

10.4.2 Components Files

Components files are templates for outgoing mail header fields that specify position and sometimes values for specified fields. Example files are shown for each one discussed here. These should exist in the user's mail directory. [annotate]

For originating mail there is a components file named "components", and it is used by the MH utility comp. An example follows: To: cc: fcc: out-copy Subject: -------- This example file differs from the default by including the fcc: line. This causes MH to keep a copy of the outgoing draft message. Also, though it isn't visible here, the To:, cc:, and Subject: lines have a space at the end. [annotate]

The "forwcomps" components file is a template for the header fields of any forwarded message. Though it may be different, our example is the same as the previous one. These are distinct files for MH's purposes, and it is more flexible since the user might not want to keep copies of forwarded messages. [annotate]

The "replcomps" components file is a template for the header fields of any draft message composed when replying to a message. An example follows: %(lit)%(formataddr %<{reply-to}%|%<{from}%|%{sender}%>%>)\ %<(nonnull)%(void(width))%(putaddr To: )\n%>\ %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\ %(formataddr{resent-to})\ %<(nonnull)%(void(width))%(putaddr cc: )\n%>\ %<{fcc}Fcc: %{fcc}\n%>\ %<{subject}Subject: Re: %{subject}\n%>\ %<{date}In-reply-to: Your message of \ %<(nodate{date})%{date}%|%(tws{date})%>.%<{message-id} %{message-id}%>\n%>\ -------- This example file differs from the default by including the resent-to: field (in addition to the to: and cc: fields) of the message being replied to in the cc: field of the draft. This is necessary for replying to all recipients of a distributed message. Keeping a copy of the outgoing draft message works a little differently with reply components. MH expects a switch which the user can put in his profile (see section 10.4.1 of this chapter), and using the MH formatting language, this file tests for the fcc value as does the standard file. [annotate]