# 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
        ------

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.

- 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.

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:`.

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

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.

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

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.

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>

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.

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

(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:

- 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.

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:

        monica@bags.bogs.com
        hanna@moocow.pgh.pa.us
        leslie@no.nrg.com
            ...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:

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

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.