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.
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.
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.
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
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.
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: projectwould 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.zzzMake the address as complete as you can; it needs to be valid from computers outside your organization, as well as inside.
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 WestThere 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
]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.
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. Userand 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.comThe 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.
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.
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.
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.
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.
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...
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 | fmtI'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 officeHere'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.
[Table of Contents] [Index] [Previous: MH Aliases] [Next: Working with Draft Messages]
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 <jerry@ora.com>
HIVE: All information for read only. Please respect copyright! |
