.I annotations
in messages.
Header fields consist of a field name and an optional field body
-as defined by RFC-2822.
+as defined by RFC 2822.
The
.B -component
option specifies the field name, and the
.PP
.I
Standard for the Format of ARPA Internet Text Messages
-(RFC\-822)
+(RFC 822)
.SH DEFAULTS
.PD 0
.TP 20
.B \-nomime
switch will force
.B burst
-to use RFC-934 rules.
+to use RFC 934 rules.
.PP
The
.B \-quiet
.PP
.I
Proposed Standard for Message Encapsulation
-(RFC\-934)
+(RFC 934)
.SH DEFAULTS
.PD 0
.TP 20
.RI \*(lq Distribute\-xxx: \*(rq
instead of
.RI \*(lq Resent\-xxx: \*(rq.
-In order to conform with the ARPA Internet standard, RFC\-822, the
+In order to conform with the ARPA Internet standard, RFC 822, the
.RI \*(lq Resent\-xxx: \*(rq
form is now used.
.B Dist
.IR ap (8),
.PP
.I "Standard for the Format of ARPA Internet Text Messages"
-(RFC\-822)
+(RFC 822)
.SH DEFAULTS
.PD 0
.TP 20
LS_COMP Write component to \fIstr\fR register
LS_LIT Write literal to \fIstr\fR register
LS_GETENV Write environment var to \fIstr\fR register
-LS_DECODECOMP Decode RFC-2047 encoded component to \fIstr\fR register
-LS_DECODE Decode RFC-2047 encoded string to \fIstr\fR register
+LS_DECODECOMP Decode RFC 2047 encoded component to \fIstr\fR register
+LS_DECODE Decode RFC 2047 encoded string to \fIstr\fR register
LS_TRIM Trim trailing whitespace from \fIstr\fR register
LV_COMP Convert component to integer, store in \fInum\fR register
LV_COMPFLAG Set \fInum\fR to 1 if \fBTRUE\fR set in component
LS_ZONE Write time zone offset to \fIstr\fR from date component
LS_DAY Write short name of day of week to \fIstr\fR from date component
LS_WEEKDAY Write long name of day of week to \fIstr\fR from date component
-LS_822DATE Write RFC-822 compatible date to \fIstr\fR from date component
+LS_822DATE Write RFC 822 compatible date to \fIstr\fR from date component
LS_PRETTY Write date with \*(lqpretty\*(rq timezone to \fIstr\fR
LV_SEC Write date component seconds to \fInum\fR
LV_MIN Write date component minutes to \fInum\fR
LS_PATH Write host route of addr component to \fIstr\fR
LS_GNAME Write group name of addr component to \fIstr\fR
LS_NOTE Write note portion of addr component to \fIstr\fR
-LS_822ADDR Write \*(lqproper\*(rq RFC-822 version of addr component to \fIstr\fR
+LS_822ADDR Write \*(lqproper\*(rq RFC 822 version of addr component to \fIstr\fR
LS_FRIENDLY Write friendly (name or note) of address component to \fIstr\fR
-LS_UNQUOTE Remove RFC-2822 quotes from string
+LS_UNQUOTE Remove RFC 2822 quotes from string
LV_HOSTTYPE Set \fInum\fR to type of host (0=local, 1=network)
LV_INGRPF Set \fInum\fR to 1 if address was inside of group
LV_NOHOSTF Set \fInum\fR to 1 of no host was present in address component
will be prepended with `\-\ ' so that when received, the message is
suitable for bursting by
.BR burst .
-This follows the Internet RFC\-934 guidelines. You may use the flag
+This follows the Internet RFC 934 guidelines. You may use the flag
.B \-nodashstuffing
in order
to suppress this form of quoting to the forwarded messages.
.PP
.I
Proposed Standard for Message Encapsulation
-(RFC\-934)
+(RFC 934)
.SH DEFAULTS
.PD 0
.TP 25
sequence has at most just a single message number, not a range.
.PP
Sequence names have a maximum size of 998 characters. Each line is also
-limited to a maximum of 998 characters, but RFC\-822 continuation rules
+limited to a maximum of 998 characters, but RFC 822 continuation rules
apply; sequences can be continued across multiple lines by prefixing
continuation lines with a whitespace character.
.PP
comp comp string Set \fIstr\fR to component text
compval comp integer Set \fInum\fR to \*(lq\fBatoi\fR(\fIcomp\fR\^)\*(rq
.\" compflag comp integer Set \fInum\fR to component flags bits (internal)
-.\" decodecomp comp string Set \fIstr\fR to RFC-2047 decoded component text
-decode expr string decode \fIstr\fR as RFC-2047 (MIME-encoded)
+.\" decodecomp comp string Set \fIstr\fR to RFC 2047 decoded component text
+decode expr string decode \fIstr\fR as RFC 2047 (MIME-encoded)
component
-unquote expr string remove RFC-2822 quotes from \fIstr\fR
+unquote expr string remove RFC 2822 quotes from \fIstr\fR
trim expr trim trailing whitespace from \fIstr\fR
putstr expr print \fIstr\fR
putstrf expr print \fIstr\fR in a fixed width
data are not handled. No data compression is accepted. All text is
clear ASCII 7-bit data.
.PP
-The general \*(lqmemo\*(rq framework of RFC\-822 is used. A message
+The general \*(lqmemo\*(rq 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
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
+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.
.PP
.SH "SEE ALSO"
.I
Standard for the Format of ARPA Internet Text Messages
-(RFC\-822)
+(RFC 822)
.SH CONTEXT
None
and
.B repl
to construct your default \*(lqFrom\*(rq header. The text used here will
-be copied exactly to your From: header, so it should already be RFC-822
+be copied exactly to your From: header, so it should already be RFC 822
compliant. If this is set, the
.B Signature
profile entry is NOT used, so it should include a signature as well. (profile,
the native character set you are using. You must be able to display
this character set on your terminal.
.PP
-This variable is checked to see if a RFC-2047 header field should be
+This variable is checked to see if a RFC 2047 header field should be
decoded (in
.BR inc ,
.BR scan ,
.PP
Although the
.B HELO
-command is required by RFC\-821, many SMTP servers
+command is required by RFC 821, many SMTP servers
do not require it. Early versions of
.I SendMail
will fail if the hostname
a valid MIME message.
.PP
.B mhbuild
-creates multi-media messages as specified in RFC\-2045
-to RFC\-2049. Currently
+creates multi-media messages as specified in RFC 2045
+to RFC 2049. Currently
.B mhbuild
only supports encodings in
message bodies, and does not support the encoding of message headers as
-specified in RFC\-2047.
+specified in RFC 2047.
.PP
If you specify the name of the composition file as \*(lq-\*(rq,
then
.fi
.RE
.PP
-Any long URLs will be wrapped according to RFC\-2017 rules.
+Any long URLs will be wrapped according to RFC 2017 rules.
.PP
The \*(lqmessage\*(rq directive (#forw) is used to specify a message or
group of messages to include. You may optionally specify the name of
is similar to the
.B forw
command, except that the former uses
-the MIME rules for encapsulation rather than those specified in RFC\-934.
+the MIME rules for encapsulation rather than those specified in RFC 934.
For example,
.PP
.RS 5
.B mhbuild
should attempt to utilize the MIME encapsulation rules
in such a way that the \*(lqmultipart/digest\*(rq that is created
-is (mostly) compatible with the encapsulation specified in RFC\-934.
-If given, then RFC\-934 compliant user-agents should be able to burst the
+is (mostly) compatible with the encapsulation specified in RFC 934.
+If given, then RFC 934 compliant user-agents should be able to burst the
message on reception\0--\0providing that the messages being encapsulated
do not contain encapsulated messages themselves. The drawback of this
approach is that the encapsulations are generated by placing an extra
.IR mhstore (1)
.PP
.I "Proposed Standard for Message Encapsulation"
-(RFC\-934),
+(RFC 934),
.PP
.I "The Content-MD5 Header Field"
-(RFC\-1864),
+(RFC 1864),
.PP
.I "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"
-(RFC\-2045),
+(RFC 2045),
.PP
.I "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
-(RFC\-2046),
+(RFC 2046),
.PP
.I "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text"
-(RFC\-2047),
+(RFC 2047),
.PP
.I "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures"
-(RFC\-2048),
+(RFC 2048),
.PP
.I "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"
-(RFC\-2049)
+(RFC 2049)
.I "Definition of the URL MIME External-Body Access-Type"
-(RRC\-2017)
+(RFC 2017)
.SH DEFAULTS
.nf
.RB ` \-headers '
decoding of MIME-encoded message parts and repairing invalid MIME
headers.
.PP
-MIME messages are specified in RFC\-2045 to RFC\-2049
+MIME messages are specified in RFC 2045 to RFC 2049
(see
.IR mhbuild (1)).
The
switch enables a transformation to decode each base64 and
quoted-printable text message part to the selected 8bit or 7bit
encoding. If 7bit is selected for a base64 part but it will only fit
-8bit, as defined by RFC-2045, then it will be decoded to 8bit
+8bit, as defined by RFC 2045, then it will be decoded to 8bit
quoted-printable. Otherwise, if the decoded text would not fit the
selected encoding, the part is not decoded (and a message will be
displayed if
nonewline flag don't print newline at end of components
formatfield string format string for this component
(see below)
-decode flag decode text as RFC-2047 encoded
+decode flag decode text as RFC 2047 encoded
header field
addrfield flag field contains addresses
datefield flag field contains dates
.PP
.B mhlist
manipulates MIME (multi-media messages) as specified
-in RFC\-2045 to RFC\-2049 (See
+in RFC 2045 to RFC 2049 (See
.IR mhbuild (1)).
.PP
The
.PP
A content specification consists of a content type and a subtype.
The initial list of \*(lqstandard\*(rq content types and subtypes can
-be found in RFC\-2046.
+be found in RFC 2046.
.PP
A list of commonly used contents is briefly reproduced here:
.PP
.PP
.B mhshow
manipulates multi-media messages as specified in
-RFC\-2045 to RFC\-2049. Currently
+RFC 2045 to RFC 2049. Currently
.B mhshow
only supports
encodings in message bodies, and does not support the encoding of
-message headers as specified in RFC\-2047.
+message headers as specified in RFC 2047.
.PP
By default
.B mhshow
.PP
A content specification consists of a content type and a subtype.
The initial list of \*(lqstandard\*(rq content types and subtypes can
-be found in RFC\-2046.
+be found in RFC 2046.
.PP
A list of commonly used contents is briefly reproduced here:
.PP
.PP
.B mhstore
manipulates multi-media messages as specified in
-RFC\-2045 to RFC\-2049.
+RFC 2045 to RFC 2049.
.PP
By default,
.B mhstore
.PP
A content specification consists of a content type and a subtype.
The initial list of \*(lqstandard\*(rq content types and subtypes
-can be found in RFC\-2046.
+can be found in RFC 2046.
.PP
A list of commonly used contents is briefly reproduced here:
.PP
.IR mh\-tailor (5)
.PP
.I "Standard for the Format of ARPA Internet Text Messages"
-(RFC\-822)
+(RFC 822)
.SH DEFAULTS
.nf
.RB ` \-alias "' defaults to %etcdir%/MailAliases"
which allows rapid
composition of messages. This program is not normally invoked directly by
users but takes the place of an editor and acts as an editor front\-end.
-It operates on an RFC\-822 style message draft skeleton specified by
+It operates on an RFC 822 style message draft skeleton specified by
.IR file ,
normally provided by the
.B nmh
.PP
By default,
.B scan
-will decode RFC-2047 (MIME) encoding in
+will decode RFC 2047 (MIME) encoding in
these scan listings.
.B Scan
will only decode these fields if your
.IR mh-format (5)
.PP
.I "Proposed Standard for Message Encapsulation"
-(RFC\-934)
+(RFC 934)
.SH DEFAULTS
.nf
.RB ` "\-delay\ 0" '