usefor-article-03 February 2000

9.  Security Considerations

[The following is taken from our previous draft, and is a much cut down
version of material in Son-of-1036. What else should be said, and should
more of the Son-of-1036 material be rescued?]

   There is no security. Don't fool yourself. Usenet is a prime example
   of an Internet Adhocratic-Anarchy; that is, an environment in which
   trust forms the basis of all agreements.  It works.

   Articles which are intended to have restricted distribution are
   dependent on the goodwill of every site receiving them.  The
   "Archive: no" header is available as a signal to automated archivers
   not to file an article, but that cannot be guaranteed.
   The Distribution header makes provisions for articles which should
   not be propagated beyond a cooperating subnet. The key security word
   here is "cooperating". When a machine is not configured properly, it
   may become uncooperative and tend to distribute all articles.

--- ../rfc2822/Security_Considerations.out          April 2001
+++ ../usefor-article-03/Security_Considerations.out          February 2000
@@ -1,43 +1,19 @@
-5. Security Considerations
+9.  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].
+[The following is taken from our previous draft, and is a much cut down
+version of material in Son-of-1036. What else should be said, and should
+more of the Son-of-1036 material be rescued?]
 
-   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.
+   There is no security. Don't fool yourself. Usenet is a prime example
+   of an Internet Adhocratic-Anarchy; that is, an environment in which
+   trust forms the basis of all agreements.  It works.
+
+   Articles which are intended to have restricted distribution are
+   dependent on the goodwill of every site receiving them.  The
+   "Archive: no" header is available as a signal to automated archivers
+   not to file an article, but that cannot be guaranteed.
+   The Distribution header makes provisions for articles which should
+   not be propagated beyond a cooperating subnet. The key security word
+   here is "cooperating". When a machine is not configured properly, it
+   may become uncooperative and tend to distribute all articles.