usefor-usepro-03 February 2005

8.2.1.  Denial of Service

   The proper functioning of individual newsgroups can be disrupted by
   the massive posting of "noise" articles, by the repeated posting of
   identical or near identical articles, by posting followups unrelated
   to their precursors, or which quote their precursors in full with the
   addition of minimal extra material (especially if this process is
   iterated), and by crossposting to, or setting followups to, totally
   unrelated newsgroups.

   Many have argued that "spam", massively multiposted (and to a lesser
   extent massively crossposted) articles, usually for advertising
   purposes, also constitutes a DoS attack in its own regard.  This may
   be so.


   Such articles intended to deny service, or other articles of an
   inflammatory nature, may also have their From or Reply-To addresses
   set to valid but incorrect email addresses, thus causing large
   volumes of email to descend on the true owners of those addresses.

   Similar effects could be caused by any email header which could cause
   every reading agent receiving it to take some externally visible
   action.  For example, the Disposition-Notification-To header defined
   in [RFC 2298] could cause huge numbers of acknowledgements to be
   emailed to an unsuspecting third party (for which reason [RFC 2298]
   declares that that header SHOULD NOT be used in Netnews).

   It is a violation of this standard for a poster to use as his address
   a <mailbox> which he is not entitled to use.  Even addresses with an
   invalid <local-part> but a valid <domain> can cause disruption to the
   administrators of such domains.  Posters who wish to remain anonymous
   or to prevent automated harvesting of their addresses, but who do not
   care to take the additional precautions of using more sophisticated
   anonymity measures, should avoid that violation by the use of
   addresses ending in the ".invalid" top-level-domain (see 7.5).

   A malicious poster may also prevent his article being seen at a
   particular site by preloading that site into the Path header (F-
   3.1.6) and may thus prevent the true owner of a forged From or
   Reply-To address from ever seeing it.

   A malicious complainer may submit a modified copy of an article (e.g.
   with an altered Injection-Info header) to the administrator of an
   injecting agent in an attempt to discredit the author of that article
   and even to have his posting privileges removed. Administrators
   should therefore obtain a genuine copy of the article from their own
   serving agent before taking such precipitate action.

   Administrative agencies with responsibility for establishing policies
   in particular hierarchies can and should set bounds upon the
   behaviour that is considered acceptable within those hierarchies (for
   example by promulgating charters for individual newsgroups, and other
   codes of conduct).

   Whilst this standard places an onus upon injecting agents to bear
   responsibility for the misdemeanours of their posters (which includes
   non-adherence to established policies of the relevant hierarchies as
   provided in section 7.2), and to provide assistance to the rest of
   the network by making proper use of the Injection-Info (F-3.2.13) and
   Complaints-To (a-6.20) headers, it makes no provision for
   enforcement, which may in consequence be patchy. Nevertheless,
   injecting sites which persistently fail to honour their
   responsibilities or to comply with generally accepted standards of
   behaviour are likely to find themselves blacklisted, with their
   articles refused propagation and even subject to cancellation, and
   other relaying sites would be well advised to withdraw peering
   arrangements from them.

--- ../usefor-usepro-02/Denial_of_Service.out          December 2004
+++ ../usefor-usepro-03/Denial_of_Service.out          February 2005
@@ -13,6 +13,7 @@
    purposes, also constitutes a DoS attack in its own regard.  This may
    be so.
 
+
    Such articles intended to deny service, or other articles of an
    inflammatory nature, may also have their From or Reply-To addresses
    set to valid but incorrect email addresses, thus causing large
@@ -20,14 +21,14 @@
 
    Similar effects could be caused by any email header which could cause
    every reading agent receiving it to take some externally visible
-   action.  For example, the Disposition-Notification-To-header defined
+   action.  For example, the Disposition-Notification-To header defined
    in [RFC 2298] could cause huge numbers of acknowledgements to be
    emailed to an unsuspecting third party (for which reason [RFC 2298]
    declares that that header SHOULD NOT be used in Netnews).
 
    It is a violation of this standard for a poster to use as his address
-   a mailbox which he is not entitled to use.  Even addresses with an
-   invalid local-part but a valid domain can cause disruption to the
+   a <mailbox> which he is not entitled to use.  Even addresses with an
+   invalid <local-part> but a valid <domain> can cause disruption to the
    administrators of such domains.  Posters who wish to remain anonymous
    or to prevent automated harvesting of their addresses, but who do not
    care to take the additional precautions of using more sophisticated
@@ -35,12 +36,12 @@
    addresses ending in the ".invalid" top-level-domain (see 7.5).
 
    A malicious poster may also prevent his article being seen at a
-   particular site by preloading that site into the Path-header (a-
-   5.6.1) and may thus prevent the true owner of a forged From or
+   particular site by preloading that site into the Path header (F-
+   3.1.6) and may thus prevent the true owner of a forged From or
    Reply-To address from ever seeing it.
 
    A malicious complainer may submit a modified copy of an article (e.g.
-   with an altered Injection-Info-header) to the administrator of an
+   with an altered Injection-Info header) to the administrator of an
    injecting agent in an attempt to discredit the author of that article
    and even to have his posting privileges removed. Administrators
    should therefore obtain a genuine copy of the article from their own
@@ -56,8 +57,8 @@
    responsibility for the misdemeanours of their posters (which includes
    non-adherence to established policies of the relevant hierarchies as
    provided in section 7.2), and to provide assistance to the rest of
-   the network by making proper use of the Injection-Info- (a-6.19) and
-   Complaints-To- (a-6.20) headers, it makes no provision for
+   the network by making proper use of the Injection-Info (F-3.2.13) and
+   Complaints-To (a-6.20) headers, it makes no provision for
    enforcement, which may in consequence be patchy. Nevertheless,
    injecting sites which persistently fail to honour their
    responsibilities or to comply with generally accepted standards of