rfc2822 April 2001

5. Security Considerations

   Care needs to be taken when displaying messages on a terminal or
   terminal emulator.  Powerful terminals may act on escape sequences
   and other combinations of ASCII control characters with a variety of
   consequences.  They can remap the keyboard or permit other
   modifications to the terminal which could lead to denial of service
   or even damaged data.  They can trigger (sometimes programmable)
   answerback messages which can allow a message to cause commands to be
   issued on the recipient's behalf.  They can also effect the operation
   of terminal attached devices such as printers.  Message viewers may
   wish to strip potentially dangerous terminal escape sequences from
   the message prior to display.  However, other escape sequences appear
   in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
   RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
   indiscriminately.
   Transmission of non-text objects in messages raises additional
   security issues.  These issues are discussed in [RFC2045, RFC2046,
   RFC2047, RFC2048, RFC2049].

   Many implementations use the "Bcc:" (blind carbon copy) field
   described in section 3.6.3 to facilitate sending messages to
   recipients without revealing the addresses of one or more of the
   addressees to the other recipients.  Mishandling this use of "Bcc:"
   has implications for confidential information that might be revealed,
   which could eventually lead to security problems through knowledge of
   even the existence of a particular mail address.  For example, if
   using the first method described in section 3.6.3, where the "Bcc:"
   line is removed from the message, blind recipients have no explicit
   indication that they have been sent a blind copy, except insofar as
   their address does not appear in the message header.  Because of
   this, one of the blind addressees could potentially send a reply to
   all of the shown recipients and accidentally reveal that the message
   went to the blind recipient.  When the second method from section
   3.6.3 is used, the blind recipient's address appears in the "Bcc:"
   field of a separate copy of the message. If the "Bcc:" field sent
   contains all of the blind addressees, all of the "Bcc:" recipients
   will be seen by each "Bcc:" recipient.  Even if a separate message is
   sent to each "Bcc:" recipient with only the individual's address,
   implementations still need to be careful to process replies to the
   message as per section 3.6.3 so as not to accidentally reveal the
   blind recipient to other recipients.