INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             July 2001

8.8.2. Duties of an Incoming Gateway

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 e-mail 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 and MUST
   fully conform to the restrictions on said headers. 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 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.5).
   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 e-mail 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. This transformation 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 mail 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 address. 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.

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:56:19 2001
+++ {draft-05}	Wed Jul 11 21:56:20 2001
@@ -32,8 +32,6 @@
    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.