usefor-article-12 November 2003

8.8.2.  Duties of an Incoming Gateway

   The incoming gateway has the serious responsibility of ensuring that
   all of the requirements of this standard are met by the articles that
   it forms. In addition to its special duties as a gateway, it bears
   all of the duties and responsibilities of an injecting agent as well,
   and additionally has the same responsibility of a relaying agent to
   reject articles that it has already gatewayed.

   An incoming gateway MUST NOT gate the same message twice. It may not
   be possible to ensure this in the face of mangling or modification of
   the message, but at the very least a gateway, when given a copy of a
   message it has already gated identical except for trace headers (like
   Received in Email or Path in Netnews) MUST NOT gate the message
   again.  An incoming gateway SHOULD take precautions against having
   this rule bypassed by modifications of the message that can be
   anticipated.

   News articles prepared by gateways MUST be legal news articles. In
   particular, they MUST include all of the mandatory headers, MUST
   fully conform to the restrictions on said headers, and SHOULD exclude
   any deprecated headers (4.2.1).  This often requires that a gateway
   function not only as a relaying agent, but also partly as a posting
   agent, aiding in the synthesis of a conforming article from non-
   conforming input.

   Incoming gateways MUST NOT pass control messages (articles containing
   a Control- or Supersedes-header) without removing or renaming that
   header. Gateways MAY, however, generate their own cancel messages,
   under the general allowance for injecting agents to cancel their own
   messages (7.3).  If a gateway receives a message that it can
   determine is a valid equivalent of a cancel message in the medium it
   is gatewaying, it SHOULD discard that message without gatewaying it,
   generate a corresponding cancel message of its own, and inject that
   cancel message.

   Incoming gateways MUST NOT inject control messages other than
   cancels.  Encapsulation SHOULD be used instead of gatewaying, when
   direct posting is not possible or desirable.

        NOTE: It is not unheard of for mail-to-news gateways to be used
        to post control messages, but encapsulation should be used for
        these cases instead. Gateways by their very nature are
        particularly prone to loops. Spews of normal articles are bad
        enough; spews of control messages with special significance to
        the news system, possibly resulting in high processing load or
        even email sent for every message received, are catastrophic. It
        is far preferable to construct a system specifically for posting
        control messages that can do appropriate consistency checks and
        authentication of the originator of the message.

   If there is a message identifier that fills a role similar to that of
   the Message-ID-header in news, it SHOULD be used in the formation of
   the message identifier of the news article, perhaps with
   transformations required to meet the uniqueness requirement of
   Netnews and with the removal of any comments so as to comply with the
   syntax in section 5.3. Such transformations SHOULD be designed so
   that two messages with the same identifier generate the same
   Message-ID-header.

        NOTE: Message identifiers play a central role in the prevention
        of duplicates, and their correct use by gateways will do much to
        prevent loops. Netnews does, however, require that message
        identifiers be unique, and therefore message identifiers from
        other media may not be suitable for use without modification. A
        balance must be struck by the gateway between preserving
        information used to prevent loops and generating unique message
        identifiers.

   Exceptionally, if there are multiple incoming gateways for a
   particular set of messages, each to a different newsgroup(s), each
   one SHOULD generate a message identifier unique to that gateway. Each
   incoming gateway nonetheless MUST ensure that it does not gate the
   same message twice.

        NOTE: Consider the example of two gateways of a given mailing
        list into the world-wide Usenet newsgroups, both of which
        preserve the email message identifier. Each newsgroup may then
        receive a portion of the messages (different sites seeing
        different portions).  In these cases, where there is no one
        "official" gateway, some other method of generating message
        identifiers has to be used to avoid collisions. It would
        obviously be preferable for there to be only one gateway which
        crossposts, but this may not be possible to coordinate.

   If no date information is available, the gateway MAY supply a Date-
   header with the gateway's current date. If only partial information
   is available (e.g.  date but not time), this SHOULD be fleshed out to
   a full Date-header by adding default values rather than discarding
   this information. Only in very exceptional circumstances should Date
   information be discarded, as it plays an important role in preventing
   reinjection of old messages.

   An incoming gateway MUST add a Sender-header to the news article it
   forms containing the mailbox of the administrator of the gateway.
   Problems with the gateway may be reported to this mailbox. The
   display-name portion of this mailbox SHOULD indicate that the entity
   responsible for injection of the message is a gateway. If the
   original message already had a Sender-header, it SHOULD be renamed so
   that its contents can be preserved.

--- ../usefor-article-11/Duties_of_an_Incoming_Gateway.out          June 2003
+++ ../usefor-article-12/Duties_of_an_Incoming_Gateway.out          November 2003