Header Fields and Addresses

[previous] [next] [table of contents] [index]

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
would send a blind copy of the message to those three users. People listed in the To: and cc: fields will not know that the Bcc: users got a copy because the Bcc: field is removed from the header when the message is sent. This is like forwarding a copy of the message to someone else after sending it -- except that a blind copy lets you do it as you send the original message.

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

If the message has no "sighted" recipients (in other words, if all the recipients are "blind"), the Bcc: recipients will all see the following:
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
would save a copy of the message in your folder named project as you send it. If the folder doesn't exist yet, you'll be asked for confirmation when you send the message with send -- or, if you send with push, the folder will be created automatically.

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: @.
The Section Relative Folder Names explains @..

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
Make the address as complete as you can; it needs to be valid from computers outside your organization, as well as inside.

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>
Now user-b replies to user-a. The reply header looks like:
From: user-b
To: user-a
Subject: Re: something
References: <123@abc.edu>
Message-ID: <246@abc.edu>
The third message in this thread is from user-a to user-b, with a copy to user-c. user-a also decides to change the subject:
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>
The References: field will keep getting longer as this thread goes on. It lets anyone find all the messages in the thread by searching for the message-ids (with pick --message-id, for instance). By default, MH 6.8.3 doesn't handle References:, but you can add that to your replcomps file.

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
There are more serious examples in the Sections picking Miscellaneous Fields, Handing Periodic Mail, and msg: `While You Were Out' Messages with comp. Some non-standard fields have become common, though. One is 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
To omit that field, mhl users can add x-face to the ignores= line in the mhl.format file.

Signature and From:

When you send a mail message, the From: field looks something like:
From: ehuser@bigmachine.xxx.yyy.zzz (E. User)
depending on how your system and your MH programs are set up. You can change this field to something else in (at least) two ways.


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
and your mail messages will have a From: field something like this:
From: "Emma H. User" <ehuser@bigmachine.xxx.yyy.zzz>
This signature needs double quotes (") around it because of the period (.). (This is for the RFC 822 mail standard, not for MH.) Your version of MH may add the double quotes. Check by sending a message to yourself. If the From: name isn't quoted, add quotes to your Signature: entry.

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.


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 & Associates 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>
Any legal RFC 822-style address is okay. When the message is sent, a separate Sender: header field will automatically be added with my "official" address:
Sender: jpeek@jpeek.com
The big advantage of setting From: instead of the signature is that, if you put a fully qualified address in From:, many system MTAs will leave it exactly as you wrote it.

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.


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.


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
(See your online mimencode(1) manual page.) Again, this isn't a good idea unless you're familiar with MIME. In most cases, in my experience, the automatic encoding will do just fine.

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: One common edit is to fix mistakes in the Subject: or email addresses. Another is changing addresses that repl generated.

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:

    ...50 more...
It's easy to use UNIX commands to make that into a legal address list. sed can add a comma (,) after each address. fmt can join the individual addresses into neat lines. The vi command :r ! runs a UNIX command line and reads in the results. So, I can put the cursor on the To: field and type:
:r !sed 's/$/,/' committee | fmt
I'll get a neatly-formatted list of addresses. With two commands -- to join the list to the To: and to take off the last comma -- I've got the address list I need. Of course, if I send many messages like this, it would be easier to use an MH alias that reads from a file.

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
Here's another example. I had a folder full of mail from people who replied to one of my messages on Usenet. I wanted to send a message to all of them. How could I get their addresses from the message headers into the header of a new message? Simple: start comp with my current folder set to the folder full of replies. Then use scan and a format string to extract the From: addresses. The format string looks like this: %{from}. While I was at it, I had scan add a comma (,) after each address. The command below (again, using vi's :r !) would read in the addresses from messages 23-54. The backslash before the percent sign (\%) tells vi not to replace % with the name of the file it's editing:
:r !scan -format '\%{from},' 23-54
That's actually not quite the format string I used. Some messages had Reply-to: addresses. I wanted to use Reply-to:, if any -- otherwise, From:. The scan format string I used (which might be better typed into a file and read with scan -form tempfile) was:
That may look ugly, but it's a lot more accurate and quick than using grep and spending a lot of time editing. One more step you might use is to eliminate duplicate addresses. Pipe the output of scan into sort -u (which is basically sort | uniq):
:r !scan -format '\%<{reply-to}\%{reply-to}\%|\%{from}\%>,' 23-54 | sort -u 
If you know UNIX utilties, you can combine them with scan and MH format strings to build address lists quickly and easily.

[Table of Contents] [Index] [Previous: MH Aliases] [Next: Working with Draft Messages]

Revised by Jerry Peek. Last change $Date: 1999/10/10 05:14:05 $

This file is from the third edition of the book MH & xmh: Email for Users & Programmers, ISBN 1-56592-093-7, by Jerry Peek. Copyright © 1991, 1992, 1995 by O'Reilly & Associates, Inc. This file is freely available; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation. For more information, see the file copying.htm.

Suggestions are welcome: Jerry Peek <jpeek@jpeek.com>