Header Fields and Addresses

The first part of a mail message -- the To:, Subject:, and so on -- is called the message header. The gory details of mail headers are listed in your online mh(5) manual page.

MH lets you customize the mail message header completely -- to do some worthwhile and time-saving things. Although mhn and mhbuild create MIME header fields automatically, you may want to edit the draft and change some of that automatic editing. This section covers some common changes that you might want to make to the message header.

Fields You Add to a Header

Here are some useful fields you can add to the header of a draft.

To add one or more of these fields to your draft message, use an editor like vi. At the What now? prompt, if you type a command like edit vi, you can add fields to the header of your draft message.

You can also put these fields in template draft files. Then, the fields will go in all the draft messages you compose with a particular MH command. prompter will prompt you for these new fields, like it does for To:, Subject:, and so on. Or, you can fill in values for these fields so that they are always included in mail headers and you never need to fill them in. For details on that, see the Section Draft Message Template Files.

Bcc: Blind Carbon Copies

A header with a Bcc: field, like this:

    To: bigboss
    Bcc: curly, larry, moe
    Subject: I recommend you promote Curly, Larry, and Moe
    ------
    

The blind copies can take several different forms, depending on your system configuration.

• In some cases, the user who gets the blind copy will get a copy dropped in his or her mailbox -- without his or her mail address anywhere in the header or any indication that the message is a blind copy.
• Other times the message will be marked, much like a forwarded message, using the RFC 934 format explained in the Section Leave My Dashes Alone. Here's an example of that -- a message sent by ehuser to bigboss, with a blind copy to the three people she's writing about. Each of the "blind recipients" will get a message like this:

        Received: by bigsun.ncs.xyz.edu (5.54/ACS)
                id AA14322; Mon, 09 Jan 1995 08:24:05 EST
        Message-Id: <9501091224.AB09482@bigsun.ncs.xyz.edu>
        Date: Mon, 09 Jan 1995 08:24:15 -0500
        From: ehuser@bigsun.ncs.xyz.edu (Emma H. User)
        Subject: I recommend you promote Curly, Larry, and Moe
        Apparently-To: <curly@bigsun.ncs.xyz.edu>
  
        ------- Blind-Carbon-Copy
  
        To: bigboss@bigsun.ncs.xyz.edu
        Subject: I recommend you promote Curly, Larry, and Moe
        Date: Mon, 09 Jan 1995 08:24:15 -0500
        From: ehuser@bigsun.ncs.xyz.edu (Emma H. User)
  
        Dear Boss, you may think those three guys are stooges but
        I think they're incredibly talented.  I believe that
        you should promote them right away.
  
                                                Emma
  
        ------- End of Blind-Carbon-Copy
  
        

• MH version 6.8 and above can use MIME format instead. Type send -mime at the What now? prompt. To use MIME format for all blind carbon copies, add -mime to the send: field in your MH profile. If you're sending a blind copy of a MIME message, you must use send -mime; it doesn't use the nice --- Blind-Carbon-Copy marker, but it does preserve the MIME format.

    Bcc: Blind Distribution List: ;
    

NOTE: If you send a blind copy to two or more addresses on the same host (or, possibly, the same mail exchanger host), both users may see each others' names in Apparently-To: fields. If that would be a problem, you might save a copy of your message and use forw or dist to send separate copies to each of those addresses.

There's more about delivering blind copies in the Section Message Transfer; Sighted and Blind Recipients.

Dcc: Distribution Carbon Copies

The almost-undocumented Dcc: header field sends a message to each address listed after it. (Dcc: is mentioned in "The RAND MH Message Handling System: Administrator's Guide, UCI Version.") It's similar to Bcc:, but there's no ------- Blind-Carbon-Copy wrapper around the message. It's good for sending copies to an address which would never reply -- for instance, an automatic archiver or printer. (See the Chapter Processing New Mail Automatically for examples.) It's also good for people who want to send blind copies that aren't encapsulated as Bcc: does. For more details, see the Section Message Transfer; Sighted and Blind Recipients.

Because Dcc: isn't documented, don't depend on it staying in MH forever.

Fcc: Folder Copies

This book doesn't cover folders in detail until the Section Folders. But here's a useful feature of MH that belongs with mail-sending commands: a folder copy. A field like this in your message header:

    Fcc: project
    

If you put more than one folder name here, separated by commas, the message copy will go to all of those folders. Some versions of MH will put a separate copy in each folder; others will use links. If you care whether you get links or copies, see the Section Are These Two Messages Linked? or check with a local expert. If your version gives copies, you can get links by using Fcc: to a single folder, and then by using refile -link on that message after the mail has been sent.

To put a copy into the current folder, no matter what its name is, try:

    Fcc: @.
    

What happens if you give the name of a folder that doesn't exist -- possibly a typo (like inbxo instead of inbox)? If you send the message with send at the What now? prompt, you'll be prompted whether you want to create the folder. If you send with push, the folder will be created automatically. If you use fcc: and push, take a look at the script in the Section Check for Folder Changes; it'll catch these accidentally-made folders.

Note that, because Fcc: is processed before the message goes through the mail transport system, the folder copy won't have header fields like Received: and Message-ID:. If you want to see them, send yourself a copy with Dcc: or cc:.

Reply-to: Give a Different Address for Replies

If you're sending a message from some computer but you don't read mail on that same computer, you can add a field to the header of your message that tells where reply messages should be sent. There are quite a few other reasons to do this. For example, if you send mail to a distribution list which has many addresses, you can use this to request that replies automatically to go to you or some other address.

Not all mail agents pay attention to this, but a lot (like MH repl) do -- they'll see this special field in the header and automatically address replies to it instead of the From: address. (To:s and cc:s are replied to as always.) Put a field like this in the message header:

    Reply-to: yourname@yourmachine.xxx.yyy.zzz
    

References: Message Threading

(Note that you usually won't add a References: field by hand. It's maintained automatically -- for instance, by Jerry's updated replcomps file.)

USENET news articles have had a References: field for a long time. In email, though, it's only been popular for a few years. References: describes the thread (chain, series) of messages that "came before" the one you're reading. Each message on the Internet has a unique identification number that's kept in the Message-ID: field. References: is a list of the message-ids from previous messages in this thread. When you compose a new message and send it, MH (or the MTA) adds the Message-ID: field. When someone replies to that message, the user's MUA will create a References: field and copy the original message-id into it. If someone else replies to that reply, this References: field gets the previous references, plus the previous message-id. And so on.

An example should make this easier to see. Let's look at a thread with three messages. user-a sends a message to user-b. This original message header might have:

    From: user-a
    To: user-b
    Subject: something
    Message-ID: <123@abc.edu>
    

    From: user-b
    To: user-a
    Subject: Re: something
    References: <123@abc.edu>
    Message-ID: <246@abc.edu>
    

    From: user-a
    To: user-b
    cc: user-c
    Subject: Another thing (was: Re: something)
    References: <123@abc.edu> <246@abc.edu>
    Message-ID: <789@abc.edu>
    

X-: Your Own Header Fields

The RFC 822 transport standard -- and others since it -- carefully specifies what header fields are legal in mail messages. Any field name starting with the characters X- (the letter X followed by a dash) won't be adopted by a new message header standard. According to RFC 822, "any field which is defined in a document published as a formal extension to this specification [will not] will have names beginning with the string `X-'." For example:

    X-fortune: Too much of a good thing is WONDERFUL.  -- Mae West
    

X-Face:

If you have a user agent like exmh that understands X-Face:, this field (if it's included) will display a small picture of the sender's face. The Figure exmh display has an example, and the Section X-Face Header Fields explains the setup. The field is ugly if you aren't set up to view it:

    X-Face: 4'>h,#cS;REmrM.0o;MLO(rQ\6!tC3|K"`%_&L/5r'?`z?YFA'^?O_2;uhDj}[Ezd'KN;UN
     ]JY>}7NI!3#)pemuo^HLsy?e&d;~eMDvq{tVqg<Dj,:;J_+=`G9:Av(qc1~%PPox??]:2o`7kWKem,
     99A>_JaK.QQ>aXK,)ruQhThx8,.X|_@Foa75CW:E[=@U@5dA'(H`V>Vm{d[)S8AcVpGs1Jw,p6w{LF
     c?o(}7$@3ani]G[joNpQsJ%^kZhox%7\gVhT%uu|8"WXlT=U1:opS-:9hL{kZgxhGvUf?bJ4E
    

Signature and From:

When you send a mail message, the From: field looks something like:

    From: ehuser@bigmachine.xxx.yyy.zzz (E. User)
    

Signature

If you define your signature, it replaces the text in the From: field (although your system may add more text at the end of your signature).

For example, you can put the following entry in your MH profile:

    Signature: Emma H. User
    

    From: "Emma H. User" <ehuser@bigmachine.xxx.yyy.zzz>
    

You can also set a SIGNATURE environment variable in your shell startup file (.login or .profile):

$ SIGNATURE='Emma H. User'; export SIGNATURE   ...sh/ksh shells
% setenv SIGNATURE 'Emma H. User'   ...csh shell

If your name has an apostrophe in it, like O'Reilly, use double quotes instead of single quotes around the SIGNATURE variable definition. If your version of MH doesn't add a pair of double quotes (") around the From: name, add them to the environment variable definition inside the pair of single quotes. If your name has an apostrophe and your MH doesn't supply double quotes in the From: name, it'll be easier to use a Signature: profile entry.

Some people like to add a standard signature of one or more lines to the end of a message. An easy way to do that is by editing your draft template file. For more ideas, see the Sections Automatic Signature on End of Messages, Add Text to Drafts: mysend, and Add Files to Your Drafts: append.

From:

Instead of defining your signature, you can use a completely different From: header field. I've done that on my job. I was one of the people at O'Reilly Media who gets mail from system aliases like bookquestions (technical questions about books) and book-info-request (to join our mailing list). When I replied to messages, I wanted the reply to have the same address in the header. I added a header field like this:

    From: Jerry Peek <bookquestions@ora.com>
    

    Sender: jpeek@jpeek.com
    

I made my From: field with the command version called replb. It's simpler just to add it to your draft message template files or to edit the message header.

MIME Fields in a Header

After you compose a draft with the directives you want to use, mhn automatically adds the correct header fields (if your MH system is configured for MIME, that is). In some cases, mhn (or mhbuild, under nmh) may not do what you want. Unless you understand MIME pretty well, you should probably leave the header as it is -- recover the original draft, fix the directives, and rerun mhn or mhbuild. (The script named original makes this a lot easier.)

You can also edit the MIME header fields if you need to. Just be sure that you don't create an invalid MIME message; the recipient may not be able to read it! The Section MIME Header Fields has an introduction. The complete story is in RFC 2045-2049, the MIME specifications.

Content-Type:

This field describes the kind of data in the message. Here's one situation where you might want to edit the Content-type:. You've made a complicated message and fed the directives to mhn or mhbuild. You notice that the filename in an external body part has a mistake. It's easier to edit the header field than it would be to recover the original directives, edit the filename there, and rerun mhn or mhbuild.

Here's another case. You're sending a multipart message to a group of people; some of them might not have a MIME-capable mail program. The default boundaries that are used (like =_aaaaaaaaaa0) are unique, but they're hard for humans to tell apart. You could change the main boundary to a string like part-boundary and the subpart boundaries to subpart-boundary-1 (and so on). Use a text editor's query-and-replace function to be sure you get them all -- and to be sure that the boundary string doesn't already exist somewhere in the body. But this isn't a good idea unless you're familiar with MIME; you could corrupt the multipart message.

Content-Transfer-Encoding:

As explained in the Section Choosing MIME Encodings, MH and nmh generally don't let you choose the Content-Transfer-Encoding:. For example, quoted-printable might be chosen for a PostScript illustration. Because most of that PostScript file isn't human-readable, you might want to change its encoding to base64. In that case, you could edit the header field. Then delete the quoted-printable body text and read in a base64 version of the PostScript file with a command like this (in the vi editor):

    :r !mimencode somefile.ps
    

Other MIME Fields

mhn and mhbuild know what version of the MIME spec they're using, so you shouldn't change the MIME-Version: field.

The chosen Content-ID: value should always be unique. If you're making a message with an external body part, feel free to change the Content-ID: to something you like better. Just be sure that your recipient's mail program couldn't confuse that body part with an external part from another message. The value must be in the style of an RFC 822 message-ID, like <something@somewhere>.

If you didn't add a Content-Description: when you wrote a directive, or if you think of a better description, feel free to edit that field.

Editing the Header

prompter doesn't give you much flexibility as you enter the header. You can use an automated editor like forwedit to change part of the header for you. MH lets you use an editor like emacs or vi to change the header in any way you want: add, edit, or delete fields. There are three important rules to remember:

• Don't put blank lines in the header.
• The header should end with a blank line. You can also use a row of dashes (------); the MH send command will convert them into a blank line.
• Make legal fields. They should follow the rules in RFC 822 -- and later specs, like the MIME RFC 2045. If you continue a field onto a second line, indent continuation lines.

  Of course, you don't need to read through hundreds of pages of specs before you edit a header. It's easier to follow examples. But it isn't a bad idea to get a copy of the specs and skim through them. The Reference List lists important RFCs.

If I'm sending a message to a long list of people, I like to make the address list with the help of a text editor and external programs or files. For instance, I might have a file named committee full of names and email addresses, one per line, like this:

    monica@bags.bogs.com
    hanna@moocow.pgh.pa.us
    leslie@no.nrg.com
        ...50 more...
    

    :r !sed 's/$/,/' committee | fmt
    

MH utilities like scan and ali can come in handy here, too. If you have an MH alias with all 30 members of your office, and you want to announce a surprise party for one person, how can you get 29 addresses without the 30th? Read the output of the ali command into the header, then delete the address you don't want:

    :r !ali office
    

    :r !scan -format '\%{from},' 23-54
    

    %<{reply-to}%{reply-to}%|%{from}%>,
    

    :r !scan -format '\%<{reply-to}\%{reply-to}\%|\%{from}\%>,' 23-54 | sort -u