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 creates MIME header fields automatically, you may want
to edit the draft and change some of what mhn does.
This section covers some common changes that you might want to make to
the message 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 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,
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.
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.
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 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 @..
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.
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.
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 & 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: jerry@ora.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.
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 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.
(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 1521, 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.
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.
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 mhn uses (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
How mhn Chooses Encoding,
mhn doesn't let you choose the
Content-Transfer-Encoding:.
For example, mhn might choose quoted-printable 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, mhn's automatic encoding will do
just fine.
Other MIME Fields
mhn knows what version of the MIME spec it's using, so you shouldn't
change the MIME-Version: field.
mhn will choose a Content-ID: value that 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.
prompter doesn't give you much flexibility as you enter the header.
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:
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.
|
