usefor-article-07 May 2002
[< Prev]
[TOC] [ Next >]
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. 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 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 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.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-06/Duties_of_an_Incoming_Gateway.out November 2001
+++ ../usefor-article-07/Duties_of_an_Incoming_Gateway.out May 2002
@@ -11,48 +11,50 @@
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
+ 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 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.
+ 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 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.
+ 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 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.
+ 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-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.
+ 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
@@ -71,7 +73,7 @@
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
+ 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
@@ -79,19 +81,19 @@
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
+ 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
+ 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
+ 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
+ original message already had a Sender-header, it SHOULD be renamed so
that its contents can be preserved.