s-o-1036 June 1994

10.1. General Gatewaying Issues

This section will primarily address the problems of gateway-
ing traffic INTO news networks.  Little can  be  said  about
the  other  direction without some specific knowledge of the
network(s)  involved.   However,  the  two  issues  are  not
entirely  independent:  if  a  non-news network is gatewayed
into a news network at more than one point, traffic injected
into  the  non-news  network  by  one  gateway may appear at
another as a candidate for injection back into the news net-
work.

This raises a more general principle, the single most impor-
tant issue for gatewaying:

     Above all, prevent loops.

The normal loop prevention of news transmission  is  vitally
dependent on the Message-ID header.  Any gateway which finds
it necessary to remove this header, alter it,  or  supersede
it (by moving it into the body), MUST take equally effective
precautions against looping.

     NOTE: There are few things more effective at turn-
     ing  news readers into a lynch mob than a malfunc-
     tioning gateway, or pair of gateways,  that  takes
     in news articles, mangles them just enough to pre-
     vent news relayers from recognizing them as dupli-
     cates,  and  regurgitates  them back into the news
     stream.  This happens rather too often.

Gateway implementors should realize that gateways  have  all
the  responsibilities  of relayers, plus the added complica-
tions introduced by transformations between different infor-
mation  formats.   Much of section 9's discussion of relayer
issues is relevant to  gateways  as  well.   In  particular,
gateways SHOULD keep a history of recently-seen articles, as
described in section 9.2, and not assume that articles  will
never reappear.  This is particularly important for networks
that have their own concept  analogous  to  message  IDs:  a

INTERNET DRAFT to be        NEWS                   sec. 10.1


gateway  should  keep  a  history  of traffic seen from BOTH
directions.

If at all possible, articles entering the  non-news  network
SHOULD  be  marked  in some way so that they will NOT be re-
gatewayed back into news.  Multiple gateways obviously  must
agree  on  the  marking method used; if it is done by having
them know each others' names, name changes MUST  be  coordi-
nated  with  great  care.   If  marking  cannot be done, all
transformations MUST be reversible so  that  a  re-gatewayed
article  is  identical to the original (except perhaps for a
longer Path header).

Gateways MUST not pass control messages (articles containing
Control, Also-Control, or Supersedes headers) without remov-
ing the headers that  make  them  control  messages,  unless
there  are compelling reasons to believe that they are rele-
vant to both sides and that conventions are compatible.   If
it  is truly desirable to pass them unaltered, suitable pre-
cautions MUST be taken to ensure that there is NO  POSSIBIL-
ITY of a looping control message.

     NOTE:  The damage done by looping articles is mul-
     tiplied a thousandfold  if  one  of  the  affected
     articles  is something like a sendsys message (see
     section  7.3)  that  requests  multiple  automatic
     replies.   Most  gateways  simply  should not pass
     control messages at all.  If some  unusual  reason
     dictates doing so, gateway implementors and admin-
     istrators are urged to consider bulletproof  rate-
     limiting  measures  for  the more destructive ones
     like sendsys, e.g. passing only one  per  hour  no
     matter how many are offered.

Gateways,  like  relayers, SHOULD make determined efforts to
avoid mangling articles unnecessarily.  In the case of gate-
ways,  some  transformations  may be inevitable, but keeping
them to a minimum and ensuring that they are  reversible  is
still highly desirable.

Gateways  MUST avoid destroying information.  In particular,
the restrictions of section 4.2.2  are  best  taken  with  a
grain  of salt in the context of gateways.  Information that
does not translate directly  into  news  headers  SHOULD  be
retained, perhaps in "X-" headers, both because it may be of
interest to sophisticated readers and because it may be cru-
cial to tracing propagation problems.

Gateway implementors should take particular note of the dis-
cussion of mailed replies, or  more  precisely  the  ban  on
same,  in section 9.1.  Gateway problems MUST be reported to
the local administration, not to the innocent originator  of
traffic.   "Gateway  problems"  here  includes  all forms of
propagation anomaly on the non-news  side  of  the  gateway,

INTERNET DRAFT to be        NEWS                   sec. 10.1


e.g.  unreachable  addresses  on  a mailing list.  Note that
this  requires  consideration  of  possible  misbehavior  of
"downstream" hosts, not just the gateway host.