4 .TH MH-MAIL %manext5% "%nmhdate%" MH.6.8 [%nmhversion%]
6 mh-mail \- message format for nmh message system
13 processes messages in a particular format. It should be noted
14 that although neither Bell nor Berkeley mailers produce message files
19 can read message files in that antiquated format.
21 Each user possesses a system maildrop box which initially receives all
22 messages delivered by the MTA.
24 will read from that maildrop
25 and incorporate the new messages found there into the user's own
26 mail folders (typically
29 Messages are expected to consist of lines of text. Graphics and binary
30 data are not directly handled. No data compression is accepted. All text is
31 clear ASCII 7-bit data.
33 The general `memo' framework of RFC\-822 is used. A message
34 consists of a block of information in a rigid format, followed by
35 general text with no specified format. The rigidly formatted first
36 part of a message is called the header, and the free-format portion is
37 called the body. The header must always exist, but the body is optional.
38 These parts are separated by an empty line, i.e., two consecutive newline
41 the header and body may be separated by a line consisting of dashes:
49 The header is composed of one or more header items. Each header item can
50 be viewed as a single logical line of ASCII characters. If the text of
51 a header item extends across several real lines, the continuation lines
52 are indicated by leading spaces or tabs.
54 Each header item is called a component and is composed of a keyword or
55 name, along with associated text. The keyword begins at the left margin,
56 may NOT contain spaces or tabs, may not exceed 63 characters (as specified
57 by RFC\-822), and is terminated by a colon (`:'). Certain components
58 (as identified by their keywords) must follow rigidly defined formats
59 in their text portions.
61 The text for most formatted components (e.g., `Date:' and
62 `Message\-Id:') is produced automatically. The only ones entered
63 by the user are address fields such as `To:', `Cc:',
64 etc. Internet addresses are assigned mailbox names and host computer
65 specifications. The rough format is `local@domain', such as
66 `bob@example.org'. Multiple addresses
67 are separated by commas. A missing host/domain is assumed to be the
70 As mentioned above, a blank line (or a line of dashes) signals that all
71 following text up to the end of the file is the body. No formatting is
72 expected or enforced within the body.
74 Following is a list of header components that are considered
83 Contains date and time of the message's entry
84 into the mail transport system.
91 Contains the address of the author or authors
92 (may be more than one if a `Sender:' field is present). For a
95 the reply address is constructed by
96 checking the following headers (in this order): `Mail-Reply\-To:',
97 `Reply\-To:', `From:', `Sender:'.
100 .BR Mail\-Reply\-To :
102 For a standard reply (using
105 constructed by checking the following headers (in this order):
106 `Mail-Reply\-To:', `Reply\-To:', `From:',
110 .BR Mail\-Followup\-To :
112 When making a `group' reply (using
115 any addresses in this field will take precedence, and no other reply address
116 will be added to the draft. If this header is not available, then the
117 return addresses will be constructed from the `Mail-Reply\-To:',
118 or `Reply\-To:', or `From:', along with adding the
119 addresses from the headers `To:', `Cc:', as well as
120 adding your personal address.
125 For a standard reply (using
128 constructed by checking the following headers (in this order):
129 `Mail-Reply\-To:', `Reply\-To:', `From:',
137 in the event that the message already has a
138 `From:' line. This line contains the address of the actual
144 Contains addresses of primary recipients.
149 Contains addresses of secondary recipients.
154 Still more recipients. However, the `Bcc:' line is not
155 copied onto the message as delivered, so these recipients are not
158 uses an encapsulation method for blind copies, see
168 to copy the message into the specified folder for the sender,
169 if the message was successfully given to the transport system.
174 A unique message identifier added by the MTA.
179 Sender's commentary. It is displayed by
185 A commentary line added by
187 when replying to a message.
192 Added when redistributing a message by
198 Added when redistributing a message by
204 New recipients for a message resent by
210 Still more recipients. See `Cc:' and `Resent\-To:'.
215 Even more recipients. See `Bcc:' and `Resent\-To:'.
220 Copy resent message into a folder.
221 See `Fcc:' and `Resent\-To:'.
224 .BR Resent\-Message\-Id :
226 A unique identifier glued on by the MTA.
227 See `Message\-Id:' and `Resent\-To:'.
230 The following non-standard header components are also meaningful to
238 to attach the given file to the message being sent.
271 .ta \w'%etcdir%/ExtraBigFileName 'u
272 ^%mailspool%/$USER~^Location of mail drop
276 .I "Standard for the Format of ARPA Internet Text Messages