nntp-extensions Anti-spam NNTP extension draft

[Jeff Garzik]

This is available on the Web at

	http://www.spinne.com/usenet/prefilter/

-- 
Jeff Garzik			    Typhoon, Cyclone, Diablo, and INN
Spinne USENET News Service	        Fast and efficient news feeds
http://www.spinne.com/usenet/	           News tuning and consulting
-------------- next part --------------


                             NNTP Pre-filtering

    Provisions for real-time distribution of unwanted article information

In order to keep up with the rising tide of spam, real-time transmission of
spam message ids to downstream sites is needed. To that end, I am designing
anti-spam extensions to NNTP. Here's what I've come up with:

1.1 The MODE FILTER command

     MODE FILTER

     MODE FILTER is used by a peer to indicate to the server that it
     would like to advise the server, using the FILTER command, of
     message ids the peer considered unwanted. This command should
     always be used before FILTER.

1.2 Responses

     203 Filtering is OK
     500 Command not understood

2.1 The FILTER command

     FILTER <message-id> filter-tag

     FILTER is used by a peer to indicate that the peer has processed
     the article identified by <message-id>, and advises the server it
     should consider the article cancelable.

     filter-tag is a short string identifying the process used on the
     peer to filter the article. The set of legal characters in the tag
     is limited to non-whitespace printable ASCII characters. In order
     to reduce conflicts between differing filter standards,
     implementors are encouraged to prepend the organization name to
     the beginning of the filter-tag.

     This command is merely an advisory notice sent from the peer to
     the server. The server is free to take any action upon receipt of
     a FILTER command, including no action at all.

2.2 Responses

     No response is sent back to the peer when a FILTER command is
     received.

----------------------------------------------------------------------------

3.1 Comments

As implemented in INN, the following logic would be applied to each passed
to the server:

     if ( <id>-in-history-database )

          attempt article cancel

     else

          add <id> to history database

Smarter implementations could also optimize by, and for, the presence of
spam cancel messages. If a spam cancel is present in the form of <cancel.id>
in history, further processing could be avoided. And if <id> is not in the
history database, then <cancel.id> can be added to the database as well, to
refuse the spam cancel that's almost certainly to follow.

4.1 INN sample implementation

     PATCH to INN 1.7 (2k text)
     http://www.spinne.com/usenet/prefilter/innd-prefilter.patch

5.1 Diablo sample implementation

     PATCH to Diablo 1.13 (1k text)
     http://www.spinne.com/usenet/prefilter/diablo-prefilter.patch

----------------------------------------------------------------------------

Jeff Garzik
Spinne USENET News Service
November 14, 1997