INTERNET-DRAFT Brian Court Expires: September 3, 1998 California State University NNTP Extensions for Dynamic Feed Adjustments draft-court-dynfeed-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document describes a set of extensions to the Network News Transport Protocol[RFC977] that allow NNTP peers to dynamically adjust their criteria for sending network news articles to one another. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 4. Introduction The Network News Transport Protocol [RFC977] defines a mechanism (IHAVE) that allows news peers to determine that a particular article has already been sent to a particular peer, so there is no need to send it again. However, this is the only defined mechanism for restricting which news articles go to a particular peer. In practice, it is valuable to make many such restrictions, based on the size of the news article or the values of its various headers (Newsgroups:, Distribution:, etc.) A site wishing to implement restrictions on which news articles may be sent to it must request each of its (potentially many) news peers to make the appropriate adjustments to its feed, a request that typically requires manual configuration. If even one sending site fails to make the needed change, then the receiving site, in order to implement the desired restriction, is forced to receive and immediately discard the unwanted articles, of which there may be a great many. This results in a substantial waste of network bandwidth and local computing power. The extensions specified in this document are intended to allow a sending site to learn of such restrictions from information sent to it by the receiving site. While it may still be desireable for a sending site to be pre-configured with its peers' restrictions, these extensions provide a means by which the restrictions may, entirely or in part, be learned even if no such configuration is done. 5. New and Enhanced NNTP Commands This document defines a new NNTP command (DONTSEND) with several verbs: * DONTSEND DIST * DONTSEND GROUP * DONTSEND XPOSTGROUP * DONTSEND MAXARTSIZE * DONTSEND MINARTSIZE * DONTSEND MAXGROUPS * DONTSEND MAXHOPS * DONTSEND PATHHOST and a new verb of the existing LIST command: * LIST DONTSEND The DONTSEND DIST command allows a site to inform its peers that it wishes not to be sent articles with a specified Distribution: header. The DONTSEND GROUP and DONTSEND XPOSTGROUP commands allow a site to inform its peers that it wishes not to be sent articles posted to a specified newsgroup. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment The DONTSEND MAXARTSIZE command allows a site to inform its peers that it wishes not to be sent articles containing more than a specified number of octets. The DONTSEND MINARTSIZE command allows a site to inform its peers that it wishes not to be sent articles containing fewer than a specified number of octets. The DONTSEND MAXGROUPS command allows a site to inform its peers that it wishes not to be sent articles posted to more than a specified number of newsgroups. The DONTSEND MAXHOPS command allows a site to inform its peers that it wishes not to be sent articles whose Path: header indicates that they have traversed more than a specified number of sites. The DONTSEND PATHHOST command allows a site to inform its peers that it wishes not to be sent articles whose Path: header contains a specified host. The LIST DONTSEND command allows a site to ask its peers what feed restrictions, if any, are desired. 6. Use of NNTP Extension Mechanism The availability of the extensions described in this document are advertised by the mechanism described in [NNTP-NEW]. 7. The DONTSEND command The DONTSEND command is defined to support several verbs. 7.1. The DONTSEND DIST command Syntax: DONTSEND DIST string[,string][...] Argument: A comma-delimited group of strings specifying one or more distributions this site wishes not to receive. The DONTSEND DIST command allows one peer to inform another that it wishes not to be sent articles whose Distribution: header matches the specified pattern. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 7.2. The DONTSEND GROUP command Syntax: DONTSEND GROUP wildmat[,wildmat][...] Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns specifying one or more newsgroups this site wishes not to receive. The DONTSEND GROUP command allows one peer to inform another that it wishes not to be sent articles that are posted to newsgroups matching the specified pattern. If an article is cross-posted, a server implementing this restriction SHOULD send the article to the requesting site if at least one newsgroup to which the article is posted is not subject to a DONTSEND GROUP restriction or a restriction from the GROUP response to LIST DONTSEND. 7.3. The DONTSEND XPOSTGROUP command Syntax: DONTSEND XPOSTGROUP wildmat[,wildmat][...] Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns specifying one or more newsgroups this site wishes not to receive. The DONTSEND XPOSTGROUP command allows one peer to inform another that it wishes not to be sent articles that are posted to newsgroups matching the specified pattern. This command differs from DONTSEND GROUP in that it requests that the article not be sent even if it is cross-posted to an unrestricted newsgroup. 7.4. The DONTSEND MAXARTSIZE command Syntax: DONTSEND MAXARTSIZE nnn Argument: A positive integer specifying the largest article size (in octets) this site is willing to receive. The DONTSEND MAXARTSIZE command allows one peer to inform another that it wishes not to be sent articles larger than the specified number of octets. This command should not be relied upon to precisely control the news flow, as feeding sites may modify articles in transit and thereby change the articles' size. 7.5. The DONTSEND MINARTSIZE command Syntax: DONTSEND MINARTSIZE nnn Argument: A positive integer specifying the smallest article size (in octets) this site wishes to receive. The DONTSEND MINARTSIZE command allows one peer to inform another that it wishes not to be sent articles smaller than the specified number of octets. This command should not be relied upon to precisely control the news flow, as feeding sites may modify articles in transit and thereby change the articles' size. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 7.6. The DONTSEND MAXGROUPS command Syntax: DONTSEND MAXGROUPS nnn Argument: A positive integer specifying the maximum number of newsgroups to which an article may be posted for the site to be willing to receive it. The DONTSEND MAXGROUPS command allows one peer to inform another that it wishes not to be sent articles that are posted to more than the specified number of newsgroups. 7.7. The DONTSEND MAXHOPS command Syntax: DONTSEND MAXHOPS nnn Argument: A positive integer specifying the largest number of sites, as indicated in the Path: header, that an article may have traversed for the site to be willing to receive it. The DONTSEND MAXHOPS command allows one peer to inform another that it wishes not to be sent articles that have traversed more than the specified number of sites. This command should not be relied upon to precisely control the news flow, as the number of sites in the Path: header may not accurately reflect the number of hops the article has traversed. 7.8. The DONTSEND PATHHOST command Syntax: DONTSEND PATHHOST string[,string][...] Argument: A comma-delimited list of strings specifying one or more Path: values that, if found in the Path: header of a given article, indicate that the site does not wish to receive that article. The DONTSEND PATHHOST command allows one peer to inform another that it wishes not to be sent articles that have traversed a specified site or sites. The argument string may take the form site1!site2!site3 to indicate a particular route that an article may have traversed. This is different from site1,site2,site3 which would place a restriction on articles that had traversed any or all of the sites in any order. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 7.9. LIST DONTSEND Command The LIST DONTSEND command returns response code 230, followed by zero or more lines of the following form: # Comments MAXARTSIZE nnn MINARTSIZE nnn MAXGROUPS nnn GROUP wildmat[,wildmat][...] XPOSTGROUP wildmat[,wildmat][...] DIST string[,string][...] PATHHOST string[,string][...] followed by a period on a line by itself. The lines may occur in any order, and each keyword (MAXARTSIZE, GROUP, etc.) may occur on multiple lines. The interpretation of a response with multiple MAXARTSIZE, MINARTSIZE, or MAXGROUPS keywords is implementation-dependent. The values associated with the keywords are as described under the corresponding DONTSEND verb. Other possible response codes to LIST DONTSEND include 480 Authentication required 502 No permission 503 No restrictions 8. DONTSEND response codes Responses to all verbs of the DONTSEND command include the following codes: 230 Distribution restriction implemented. 430 Distribution restriction cannot be implemented. 480 Authentication required. 501 Command syntax error. 502 No permission. A response of 230 indicates that the peer has understood and implemented the requested restriction. A response of 430 indicates that the peer understands the request but is unable or unwilling to implement it. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 9. Implementation Notes Implementations responding to a DONTSEND command with 230 MUST refrain from sending to the requesting peer articles that do not satisfy the desired restriction. Implementations MAY elect not to honor a particular DONTSEND request but MUST respond with 430 to any DONTSEND command it does not intend to honor. If an implementation has responded with 230 to a DONTSEND request and subsequently discovers it is unable to honor that request, it MUST reset the NNTP session with the requesting peer. Implementations MUST treat the restrictions requested by DONTSEND commands, as well as the response to the LIST DONTSEND command, as valid only for the duration of the NNTP session in which they were issued. Implementations SHOULD make use of the globbing capability of wildmat[NNTP-NEW] to send the smallest number of DONTSEND commands that will describe the desired restriction. Implementations SHOULD issue a LIST DONTSEND near the beginning of an NNTP session with a peer, and MAY issue the LIST DONTSEND command at other times during that session. Implementations MAY issue DONTSEND commands that place additional restrictions (not listed in response to an earlier LIST DONTSEND) on a feed. Implementations issuing a LIST DONTSEND command MAY choose not to implement the restriction(s) described in the response to that command, unless they have responded with 230 to a DONTSEND command requesting the same restriction(s). 10. Example sessions In these examples NNTP peers itchy and scratchy have already established an NNTP session and determined that each supports the DONTSEND extensions. Example 1: In this example itchy and scratchy are exchanging their restriction lists: itchy: LIST DONTSEND scratchy: 503 No restrictions. LIST DONTSEND INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment itchy: 230 "Don't Send" information follows: # # We don't want articles greater than 250K # MAXARTSIZE 250000 # # We don't carry Clarinet groups # DONTSEND DIST clari DONTSEND GROUP clari.* # # Other hierarchies we don't carry # DONTSEND GROUP tw.*,japan.*,de.*,uk.*,fido.*,net.*,talk.* # # We don't want these groups at all, even via crossposts # DONTSEND XPOSTGROUP alt.binaries* # # Articles crossposted this many times are probably spam # DONTSEND MAXGROUPS 20 # # Don't want articles that have hit certain sites # DONTSEND PATHHOST cyberpromo . Example 2: In this example no LIST DONTSEND is issued, but a DONTSEND is issued when itchy "notices" that scratchy is sending articles with an unwanted distribution: scratchy: IHAVE <6aaq84$1ft31@burnsco.com> itchy: 335 Send article to be transferred. End with scratchy: (contents of article) itchy: 437 Article rejected. DONTSEND DIST shelbyville scratchy: 230 Distribution restriction implemented. INTERNET-DRAFT NNTP Extensions for Dynamic Feed Adjustment 11. Security Considerations The commands defined in this document allow the set of articles to be sent from one peer to another to be decreased but not increased. Therefore these commands cannot be used to cause leakage of articles to a site that would otherwise not receive them. A denial of service attack is possible if an attacker exploits existing weaknesses in the TCP/IP protocol suite to send unauthorized DONTSEND commands. 12. References [RFC977], Kantor, B., Lapsley, P., Network News Transfer Protocol, Request for Comments (RFC) 977, February 1986. [RFC2119], Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, Request for Comments (RFC) 2119, March 1997 [NNTP-NEW], Barber, S., Network News Transfer Protocol, Internet-Draft draft-ietf-nntpext-base-03.txt, December 1997. 12. Author's Address Brian Court California State University Office of the Chancellor 4665 Lampson Ave. Los Alamitos, CA 90720 Phone: 562-985-9441 Email: bac@csu.net