s-o-1036 June 1994

9.1. Relayer General Issues

Relayers  MUST not alter the content of articles unnecessar-
ily.  Well-intentioned attempts  to  "improve"  headers,  in
particular,  typically do more harm than good.  It is neces-
sary for a relayer to prepend its own name to the Path  con-
tent  (see section 5.6) and permissible for it to rewrite or
delete the Xref header (see  section  6.12).   Relayers  MAY
delete the thoroughly-obsolete headers described in appendix
A.3, although this behavior no longer seems useful enough to
encourage.   Other  alterations  SHOULD  be  avoided  at all
costs, as per the Hippocratic Principle.

     NOTE: As discussed in section 2.3, tidying up  the
     headers  of  a user-prepared article is the job of
     the posting agent, not the relayer.  The relayer's
     purpose  is  to  move  already-compliant  articles
     around efficiently without  damaging  them.   Note
     that  in  existing  implementations, specific pro-
     grams may contain both posting-agent functions and
     relayer  functions.  The distinction is that post-
     ing-agent functions are invoked only  on  articles
     posted   by   local  posters,  never  on  articles
     received from other relayers.

     NOTE: A particular corollary of this rule is  that
     relayers  should not add headers unless truly nec-
     essary.  In particular, this is not SMTP;  do  not
     add Received headers.

Relayers  MUST  not pass non-conforming articles on to other
relayers, except perhaps in a cooperating  subnet  that  has
agreed  to  permit certain kinds of non-conforming behavior.
This is a direct  consequence  of  the  Internet  Robustness
Principle.

The  two  preceding paragraphs may appear to be in conflict.
What  is  to  be  done  when  a  non-conforming  article  is
received?  The Robustness Principle argues that it should be
accepted but must not be passed on to other  relayers  while
still non-conforming, and the Hippocratic Principle strongly
discourages attempts at repair.  The  conclusion  that  this
appears  to lead to is correct: a non-conforming article MAY
be accepted for local filing and processing, or  it  MAY  be
discarded  entirely,  but  it MUST not be passed on to other
relayers.

INTERNET DRAFT to be        NEWS                    sec. 9.1


A relayer MUST not respond to the arrival of an  article  by
sending mail to any destination, other than a local adminis-
trator, except by explicit prearrangement with  the  recipi-
ent.   Neither  posting an article (other than certain types
of control message, see section 7.5) nor being the moderator
of  a  moderated  newsgroup constitutes such prearrangement.
UNDER NO CIRCUMSTANCES WHATSOEVER may a relayer  attempt  to
send  mail to either an article's originator or a moderator.

     NOTE: Reporting apparent errors in message  compo-
     sition  is  the  job  of  a  posting  agent, not a
     relayer.  The same is true of  mailing  moderated-
     newsgroup  postings to moderators.  In networks of
     thousands of cooperating relayers,  it  is  simply
     unacceptable  for  there  to  be  any circumstance
     whatsoever that causes any significant fraction of
     them  to simultaneously send mail to the same des-
     tination.  (Some control messages are  exceptions,
     although  perhaps  ill-advised ones.)  What might,
     in a smaller network, be a useful notification  or
     forwarding becomes a deluge of near-identical mes-
     sages that can bring mail software  to  its  knees
     and  severely  inconvenience  recipients.  Modera-
     tors, in particular,  historically  have  suffered
     grievously from this.

Notification  of  problems  in  incoming  articles MAY go to
local administrators, or at most  (by  prearrangement!)   to
the administrators of the neighboring relayer(s) that passed
on the problematic articles.

     NOTE: It would be desirable to notify  the  author
     that his posting is not propagating as he expects.
     However, there is no known method for  doing  this
     that  will  scale  up gracefully.  (In particular,
     "notify only if within N relayers of the  origina-
     tor" falls down in the presence of commercial news
     services like UUNET:  there  may  be  hundreds  or
     thousands  of  relayers within a couple of hops of
     the originator.)  The best that can be done  right
     now is to notify neighbors, in hopes that the word
     will eventually propagate up the line, or organize
     regional monitoring at major hubs.

If it is necessary to alter an article, e.g. translate it to
another character  set  or  alter  its  EOL  representation,
strenuous  efforts should be made to ensure that such trans-
formations are reversible, and that relayers or other  soft-
ware  that might wish to reverse them know exactly how to do
so.

     NOTE:  For  example,  a  cooperating  subnet  that
     exchanges articles using a non-ASCII character set
     like EBCDIC should define a  standard,  reversible

INTERNET DRAFT to be        NEWS                    sec. 9.1


     ASCII-EBCDIC mapping and take pains to see that it
     is used at all points where the subnet  meets  the
     outside.   If  the only reason for using EBCDIC is
     that the readers typically employ EBCDIC  devices,
     it  would  be  more  robust to employ ASCII as the
     interchange format and do  the  transformation  in
     the reading and posting agents.