As per Relevance of the word forwarding, we have this rfc below:
Network Working Group Marshall T. Rose (Delaware
Request for Comments: 934 Einar A. Stefferud (NMA
January 1985
Proposed Standard for Message
STATUS OF THIS
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
Introduction, Scope, and
The services that a user agent (UA) can offer are varied.
all outgoing mail may be thought of as going through a single
slot to connect to the message transport system (MTS), it is
to consider a message draft being posted as described by one of
following four types of postings
Originate - a new message is composed from scratch, which, to
knowledge of the UA, is unrelated to any message
handled by the user
Reply - a message is composed as a reply to a message
received by the user. In most circumstances, the UA aids the
in composing the reply by constructing the header portion of
message draft, using components extracted from the
message headers
Forward - one more more messages previously received by the
are formatted by the UA as a part of the body portion of
draft. In this sense, a "digest" for an interest group may
considered as forwarding. Similarly, an argument may be made
"blind-carbon-copies" should also be handled in this fashion
Distribute - a message previously received by the user
re-posted to the MTS. The draft being re-posted is identical
the original message with the exception that certain "ReSent-XXX
headers are appended to the headers portion of the draft, and
"Return-Path" header is reset to reference the re-sender'
address. (See [RFC-821] for a discussion of the Return-
header.)
Most user agents support the first two of these activities,
support the first three, and a few support all four
This memo concerns itself only with the third type, which is
forwarding. (For a brief treatment of the semantics of
components with respect to replies, see [RFC-822].) In many ways
Rose & Stefferud [Page 1]
RFC 934 January 1985
Message
forwarding can be thought of as encapsulating one or more
inside another. Although this is useful for transfer of
correspondence to new recipients, without a decapsulation
(which this memo terms "bursting"), the forwarded messages are
little use to the recipients because they can not be distributed
forwarded, replied-to, or otherwise processed as separate
messages
NOTE: RFC-822 mistakenly refers to distribution as
(section 4.2). This memo suggests below, that these
activities can and should be the same
In the case of an interest group digest, a bursting capability
especially useful. Not only does the ability to burst a
permit a recipient of the digest to reply to an individual
message, but it also allows the recipient to selectively process
other messages encapsulated in the digest. For example, a
digest issue usually contains more than one topic. A subscriber
only be interested in a subset of the topics discussed in
particular issue. With a bursting capability, the subscriber
burst the digest, scan the headers, and process those messages
are of interest. The others can be ignored, if the user so desires
This memo is motivated by three concerns
In order to burst a message it is necessary to know how
component messages were encapsulated in the draft. At
there is no unambiguous standard for interest group digests.
memo proposes such a standard for the ARPA-Internet.
interest group digests may appear to conform to a pseudo-standard
there is a serious ambiguity in the implementations which
digests. By proposing this standard, the authors hope to
this problem by specifically addressing the
ambiguity
Next, there is much confusion as to how "blind-carbon-copies
should be handled by UAs. It appears that each agent in
ARPA-Internet which supports a "bcc:" facility does
differently. Although this memo does not propose a standard
the generation of blind-carbon-copies, it introduces a
which views the "bcc:" facility as a special case of
forwarding activity
Finally, both forwarding and distribution can be accomplished
the same forwarding procedure, if a distributed message can
extracted as a separate individually processable message. With
proper bursting agent, it will be difficult to distinguish
Rose & Stefferud [Page 2]
RFC 934 January 1985
Message
a message which has been distributed and a message which has
extracted from a forwarded message. This memo argues that there
no valuable distinction to be made, between forwarding
distribution, and that in the interests of simplicity
distribution facilities should not be generally available to
ordinary users of a message system. However, this memo
argues that such facilities should be available to certain
entities within the MTS
NOTE: this memo does not propose that the distribution
be abolished. Rather it argues the case forcefully in the
that other interested parties in the ARPA-Internet will
this discussion
Message
This memo proposes the following encapsulation protocol: two
act on behalf of the user, a forwarding agent, which composes
message draft prior to posting, and a bursting agent which
the message after delivery
Definitions: a draft forwarding message consists of a header
and a text portion. If the text portion is present, it is
from the header portion by a blank line. Inside the text portion
certain character string sequence, known as an "
boundary", has special meaning. Currently (in
digestification agents), an encapsulation boundary (EB) is defined
a line in the message which starts with a dash (decimal code 45,
"-"). Initially, no restriction is placed on the length of
encapsulation boundary, or on the characters that follow the dash
1. The Header
This memo makes no restriction on the header portion of the draft
although it should conform to the RFC-822 standard
2. The Text
The text of the draft forwarding message consists of three parts:
initial text section, the encapsulated messages, and the final
section
2.1. The Initial Text
All text (if any) up to the first EB comprises the initial
section of the draft. This memo makes no restrictions on
Rose & Stefferud [Page 3]
RFC 934 January 1985
Message
format of the initial text section of the draft. In the case of
digest, this initial text is usually the "table of contents"
the digest
2.2. The Final Text
All text (if any) after the last EB composes the final
section of the draft. This memo makes no restrictions on
format of the final text section of the draft. In the case of
digest, this final text usually contains the sign-off banner
the digest (e.g., "End of FOO Digest").
2.3. Encapsulated
Each encapsulated message is bounded by two EBs: a pre-EB,
occurs before the message; and, a post-EB, which occurs after
message. For two adjacent encapsulated messages, the post-EB
the first message is also the pre-EB of the second message
Consistent with this, two adjacent EBs with nothing between
should be treated as enclosing a null message, and thus two
more adjacent EBs are equivalent to one EB
Each encapsulated message consists of two parts: a headers
and a text portion. If the text portion is present, it
separated from the header portion by a blank line
2.3.1. The Header
Minimally, there must be two header items in each message
forwarded, a "Date:" field and a "From:" field. This
from RFC-822, which requires at least one destination
(in a "To:" or "cc:" field) or a possibly empty "Bcc:" field
Any addresses occuring in the header items for a message
forwarded must be fully qualified
2.3.2. The Text
This memo makes no restrictions on the format of the
portion of each encapsulated message. (Actually, this
does restrict the format of the text portion of
encapsulated message, but these restrictions are
later.)
Before summarizing the generation/parsing rules for
encapsulation, two issues are addressed
Rose & Stefferud [Page 4]
RFC 934 January 1985
Message
Compatibility with Existing User
The above encapsulation protocol is presently used by many
agents in the ARPA-Internet, and was specifically designed
minimize the amount of changes to existing implementations
forwarding agents in the ARPA-Internet
However, the protocol is not exactly like the pseudo-standard used
those forwarding agents that compose digests. In particular,
post-EB of all messages encapsulated in a digest is preceeded
followed by by a blank line. In addition, the first
encapsulated in a digest has a pre-EB that is followed by a
line, but usually isn't preceeded by a blank line (wonderful).
This memo recommends that implementors of forwarding agents
to remain compatible with existing bursting agents
surrounding each EB with a blank line. It should be noted that
lines following a pre-EB for an encapsulated message must be
by bursting agents. Further, this memo suggests that blank
preceeding a post-EB also be ignored by bursting agents
NOTE: This recommendation is made in the interest
backwards-compatibility. A forwarding agent wishing to
adhere to this memo, should not generate blank lines
EBs
Character-Stuffing the Encapsulation
It should be noted that the protocol is general enough to
both general forwarding of messages and the specific case of digests
Unfortunately, there is one issue of message encapsulation
apparently is not addressed by any forwarding agent (to the authors
knowledge) in the ARPA-Internet: what action does the
agent take when the encapsulation boundary occurs within a the
portion of a message being forwarded? Without exception,
circumstance is ignored by existing forwarding agents
To address this issue, this memo proposes the
character-stuffing scheme: the encapsulation boundary is defined as
line which starts with a dash. A special case is made for
boundaries which start with a dash and are followed by a
(decimal code 32, " ").
During forwarding, if the forwarding agent detects a line in
text portion of a message being forwarded which starts with
encapsulation boundary, the forwarding agent outputs a
followed by a space prior to outputting the line
Rose & Stefferud [Page 5]
RFC 934 January 1985
Message
During bursting, if the bursting agent detects an
boundary which starts with a dash followed by a space, then
bursting agent does not treat the line as an
boundary, and outputs the remainder of the line instead
This simple character-stuffing scheme permits recursive forwardings
Generation/Parsing Rules for Message
The rules for forwarding/bursting are described in terms of
expressions. The first author originally derived simple finite-
automata for the rules, but was unable to legibly represent them
this memo. It is suggested that the implementors sketch the
to understand the grammar
The conventions used for the grammar are simple. Each state
followed by one or more alternatives, which are separated by the "|"
character. Each alternative starts with a character that is
as input. (CRLF, although two characters is treated as one
herein.) The last alternative for a state is the character "c",
which represents any character not specified in the
alternatives. Optionally following the input character is an
string enclosed by curly-braces. Following this is the state
the automata enters. The reader should note that these grammars
extremely simple to implement (and, in most cases, can be
quite efficiently).
When the forwarding agent encapsulates a message, it should apply
following finite-state automaton. The initial state is S1.
S1 :: CRLF {CRLF} S
| "-" {"- -"} S
| c {c} S
S2 :: CRLF {CRLF} S
| c {c} S
This simply says that anytime a "-" is found at the beginning of
line, a "- " is output prior to outputting the line
Rose & Stefferud [Page 6]
RFC 934 January 1985
Message
When the bursting agent decapsulates the text portion of a draft,
should apply the following finite-state automaton. The initial
is S1.
S1 :: "-" S
| CRLF {CRLF} S
| c {c} S
S2 :: CRLF {CRLF} S
| c {c} S
S3 :: " " S
| c S
S4 :: CRLF S
| c S
S5 :: CRLF S
| c {c} S
Although more complicated than the grammar used by the
agent to encapsulate a single message, this grammer is still
simple. Let us make the simplifying assumption that both the
and final text sections of the draft are messages in addition to
encapsulated messages
To begin, the current message being burst is scanned at state S1.
characters are output until the EB is found (state S3). If "- "
found, the automaton enters state S2 and characters from the
message are continued to be output. Finally, a true EB is
(state S4). As the automaton traverses from state S3 to S4,
bursting agent should consider the current message ended.
remainder of the EB is discarded (states S4 and S5). As
automaton traverses from state S5 to S2, the bursting agent
consider a new message started and output the first character.
state S2, all characters are output until the EB is found
Blind Carbon
Many user agents support a blind-carbon-copy facility. With
facility a draft has two types of addressees: visible and
recipients. The visible recipients are listed as addresses in
"To:" and "cc:" fields of the draft, and the blind recipients
listed as addresses in the "Bcc:" fields of the draft. The basis
this facility is that copies of the draft which are delivered to
recipients list the visible recipients only
Rose & Stefferud [Page 7]
RFC 934 January 1985
Message
One method of achieving this is to post a single draft, which
any "Bcc:" fields, and, during posting, to interact with the MTS
such a way that copies are sent to both the visible and
recipients
Unfortunately, a key problem with this arrangement is that the
recipients can accidently reply to the draft in such a way that
visible recipients are included as addressees in the reply. This
socially unacceptable! To avoid this problem, the message which
visible recipients receive must be different than the message
the blind recipients receive
A second method is to post two drafts. The first, which goes to
visible recipients, is simply the draft without any "Bcc:" fields
The second, which goes to the blind recipients, is simply the
with some string prepended to any "To:" and "cc:" field. For example
the user agent might prepend "BCC-" to these fields, so that
blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields
no "To:" or "cc:" fields. Unfortunately, this is often very
to the blind recipients. Although accidental replies are
possible, it is often difficult to tell that the draft received
the result of a blind-carbon-copy
The method which this memo suggests is to post two drafts, a
draft for the visible recipients, and a blind draft for the
recipients. The visible draft consists of the original draft
any "Bcc:" fields. The blind draft contains the visible message as
forwarded message. The headers for the blind draft contain
minimal RFC-822 headers and, if the original draft had a "Subject:"
field, then this header field is also included. In addition,
user agent might explicitly show that the blind draft is the
of a blind-carbon-copy, with a "Bcc" header or prior to the
encapsulating boundary in the body
Message
The main purpose of message distribution (often called
or resending) is to provide to a secondary recipient, perhaps
included among the original addressees, with a "true original"
that can be treated like an original in every respect
Such distribution is most often done by discussion group
who use automated agents to simply repost received messages to
distribution list. The better automatic distribution agents insert
new "Return-Path" header field to direct address failure notices
the discussion group address list maintainer, rather than to
original author. This form of distribution is encouraged because
Rose & Stefferud [Page 8]
RFC 934 January 1985
Message
most simply serves to deliver messages to discussion group
as processable originals. It is performed by trusted pseudo-
agents
A second kind of distribution is that done by individuals who wish
transfer a processable copy of a received message to
recipient. This second form is discouraged in various new
for message transfer. These include the NBS Standard for
Interchange [FIPS-98], and the recent CCITT draft MHS (Mail
Systems) X.400 standards [X.400]. In place of direct reposting
received messages as though they are new drafts, the
is to forward the received message in the body of a new draft
which is can be extracted by its secondary recipient for
processing
It is in support of this recommendation that this standard
encapsulation/decapsulation is proposed
Rose & Stefferud [Page 9]
RFC 934 January 1985
Message
[RFC-822] D.H. Crocker. "Standard for the Format of ARPA-
Text Messages", University of Delaware. (August, 1982)
[RFC-821] J.B. Postel. "Simple Mail Transfer Protocol",
USC/Information Sciences Institute. (August, 1982).
[FIPS-98] National Bureau of Standards. "Specification
Message Format for Computer Based Message Systems."
(January, 1983).
[X.400] Consultative Committee on International Telephone
Telegraph. "DRAFT Recommendation X.400.
Handling Systems: System Model-Service Elements."
Authors'
Marshall T.
Department of Computer and Information
University of
Newark, DE 19716
MRose@UDel.
Einar A.
Network Management Associates, Inc
17301 Drey
Huntington Beach, CA 92647
Stef@UCI.
Rose & Stefferud [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
