Provided by: mmh_0.4-2_amd64 
NAME
mh-mail - message format for mh message system
DESCRIPTION
mmh processes messages in a particular format. It should be noted that although neither
Bell nor Berkeley mailers produce message files in the format that mmh prefers, mmh can
read message files in that antiquated format.
Each user possesses a system maildrop box which initially receives all messages delivered
by the MTA. Inc will read from that maildrop and incorporate the new messages found there
into the user's own mail folders (typically `+inbox').
Messages are expected to consist of lines of text. Graphics and binary data are not
directly handled. No data compression is accepted. All text is clear ASCII 7-bit data.
The general `memo' framework of RFC-822 is used. A message consists of a block of
information in a rigid format, followed by general text with no specified format. The
rigidly formatted first part of a message is called the header, and the free-format
portion is called the body. The header must always exist, but the body is optional.
These parts are separated by an empty line, i.e., two consecutive newline characters.
Within mmh , the header and body may be separated by a line consisting of dashes:
To:
Cc:
Fcc: +sent
Subject:
--------
The header is composed of one or more header items. Each header item can be viewed as a
single logical line of ASCII characters. If the text of a header item extends across
several real lines, the continuation lines are indicated by leading spaces or tabs.
Each header item is called a component and is composed of a keyword or name, along with
associated text. The keyword begins at the left margin, may NOT contain spaces or tabs,
may not exceed 63 characters (as specified by RFC-822), and is terminated by a colon
(`:'). Certain components (as identified by their keywords) must follow rigidly defined
formats in their text portions.
The text for most formatted components (e.g., `Date:' and `Message-Id:') is produced
automatically. The only ones entered by the user are address fields such as `To:', `Cc:',
etc. Internet addresses are assigned mailbox names and host computer specifications. The
rough format is `local@domain', such as `bob@example.org'. Multiple addresses are
separated by commas. A missing host/domain is assumed to be the local host/domain.
As mentioned above, a blank line (or a line of dashes) signals that all following text up
to the end of the file is the body. No formatting is expected or enforced within the
body.
Following is a list of header components that are considered meaningful to various mmh
programs.
Date:
Added by spost. Contains date and time of the message's entry into the mail
transport system.
From:
Added by spost. Contains the address of the author or authors (may be more than one
if a `Sender:' field is present). For a standard reply (using repl, the reply
address is constructed by checking the following headers (in this order): `Mail-
Reply-To:', `Reply-To:', `From:', `Sender:'.
Mail-Reply-To:
For a standard reply (using repl), the reply address is constructed by checking the
following headers (in this order): `Mail-Reply-To:', `Reply-To:', `From:', `Sender:'.
Mail-Followup-To:
When making a `group' reply (using repl -group), any addresses in this field will
take precedence, and no other reply address will be added to the draft. If this
header is not available, then the return addresses will be constructed from the
`Mail-Reply-To:', or `Reply-To:', or `From:', along with adding the addresses from
the headers `To:', `Cc:', as well as adding your personal address.
Reply-To:
For a standard reply (using repl), the reply address is constructed by checking the
following headers (in this order): `Mail-Reply-To:', `Reply-To:', `From:', `Sender:'.
Sender:
Added by spost in the event that the message already has a `From:' line. This line
contains the address of the actual sender.
To:
Contains addresses of primary recipients.
Cc:
Contains addresses of secondary recipients.
Bcc:
Still more recipients. However, the `Bcc:' line is not copied onto the message as
delivered, so these recipients are not listed. mmh uses an encapsulation method for
blind copies, see send(1) or spost(8).
Fcc:
Causes spost to copy the message into the specified folder for the sender, if the
message was successfully given to the transport system.
Message-ID:
A unique message identifier added by the MTA.
Subject:
Sender's commentary. It is displayed by scan.
In-Reply-To:
A commentary line added by repl when replying to a message.
Resent-Date:
Added when redistributing a message by spost.
Resent-From:
Added when redistributing a message by spost.
Resent-To:
New recipients for a message resent by dist.
Resent-Cc:
Still more recipients. See `Cc:' and `Resent-To:'.
Resent-Bcc:
Even more recipients. See `Bcc:' and `Resent-To:'.
Resent-Fcc:
Copy resent message into a folder. See `Fcc:' and `Resent-To:'.
Resent-Message-Id:
A unique identifier glued on by the MTA. See `Message-Id:' and `Resent-To:'.
The following non-standard header components are also meaningful to mmh tools:
Attach:
Annotation for send to attach the given file to the message being sent.
Replied:
Annotation for repl under the -annotate option.
Forwarded:
Annotation for forw under the -annotate option.
Resent:
Annotation for dist under the -annotate option.
FILES
/var/mail/$USER Location of mail drop
SEE ALSO
Standard for the Format of ARPA Internet Text Messages (RFC-822)
CONTEXT
None