RFC 934                                                     January 1985
Message Encapsulation


   One method of achieving this is to post a single draft, which lacks
   any "Bcc:" fields, and, during posting, to interact with the MTS in
   such a way that copies are sent to both the visible and blind
   recipients.

   Unfortunately, a key problem with this arrangement is that the blind
   recipients can accidently reply to the draft in such a way that the
   visible recipients are included as addressees in the reply. This is
   socially unacceptable!  To avoid this problem, the message which the
   visible recipients receive must be different than the message which
   the blind recipients receive.

   A second method is to post two drafts.  The first, which goes to the
   visible recipients, is simply the draft without any "Bcc:" fields.
   The second, which goes to the blind recipients, is simply the draft
   with some string prepended to any "To:" and "cc:" field. For example,
   the user agent might prepend "BCC-" to these fields, so that the
   blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields and
   no "To:" or "cc:" fields. Unfortunately, this is often very confusing
   to the blind recipients.  Although accidental replies are not
   possible, it is often difficult to tell that the draft received is
   the result of a blind-carbon-copy.

   The method which this memo suggests is to post two drafts, a visible
   draft for the visible recipients, and a blind draft for the blind
   recipients.  The visible draft consists of the original draft without
   any "Bcc:" fields.  The blind draft contains the visible message as a
   forwarded message.  The headers for the blind draft contain the
   minimal RFC-822 headers and, if the original draft had a "Subject:"
   field, then this header field is also included.  In addition, the
   user agent might explicitly show that the blind draft is the result
   of a blind-carbon-copy, with a "Bcc" header or prior to the first
   encapsulating boundary in the body.

Message Distribution

   The main purpose of message distribution (often called redistribution
   or resending) is to provide to a secondary recipient, perhaps not
   included among the original addressees, with a "true original" copy
   that can be treated like an original in every respect.

   Such distribution is most often done by discussion group moderators
   who use automated agents to simply repost received messages to a
   distribution list.  The better automatic distribution agents insert a
   new "Return-Path" header field to direct address failure notices to
   the discussion group address list maintainer, rather than to the
   original author.  This form of distribution is encouraged because it



 


RFC 934                                                     January 1985
Message Encapsulation


   most simply serves to deliver messages to discussion group recipients
   as processable originals.  It is performed by trusted pseudo-MTS
   agents.

   A second kind of distribution is that done by individuals who wish to
   transfer a processable copy of a received message to another
   recipient. This second form is discouraged in various new standards
   for message transfer.  These include the NBS Standard for Mail
   Interchange [FIPS-98], and the recent CCITT draft MHS (Mail Handling
   Systems) X.400 standards [X.400]. In place of direct reposting of
   received messages as though they are new drafts, the recommendation
   is to forward the received message in the body of a new draft from
   which is can be extracted by its secondary recipient for further
   processing.

   It is in support of this recommendation that this standard for
   encapsulation/decapsulation is proposed.