nntpProxy拡張プロトコルの仕様

この文書は開発者向けのもので、エンドユーザ向けのものではありません
This document is not for end-user.

nntpProxy v1.3.0以降は、対応ニュースリーダがフィルタ状況を把握し、 XOVERのフィルタリングに起因するタイムアウトが発生しないよう、拡張プロトコルを実装しています。

この文書は、nntpProxy経由での接続方法と、拡張プロトコルに関する仕様を公開するものです。
なお、この仕様書はNNTP(NetNews Transfer Protocol , RFC977を参照)およびXOVER、AUTHINFO等のRFCに記述がないが一般的に使用されている拡張コマンドについて最低限の知識がある開発者を対象としています。

nntpProxy経由での接続方法

nntpProxyは、自身を経由して接続するクライアントに、AUTHINFOコマンドによる認証を要求します。

クライアントは、nntpProxy経由で接続したいサーバのアドレスおよびポート番号、必要ならばユーザIDとパスワードを用いて、認証します。

その書式と認証の手順は

(Client)	: AUTHINFO USER [userid@]address[:port]
(Server)	: 381 PASS required
(Client)	: AUTHINFO PASS [password]
(Server)	: 281 (server banner)

のように、一般的に使われているAUTHINFOコマンドを使用したものです。

異なる点は、本来ユーザ認証を必要としないサーバでも、サーバアドレスの指定のために、AUTHINFOコマンドによる認証を行わなければならない点です。

また、ユーザ認証を必要とするサーバに接続する場合は、「AUTHINFO USER」コマンドにおいて、サーバアドレスの直前に「ユーザID@」を挿入し、「AUTHINFO PASS」コマンドに、本来のパスワードを渡します。
nntpProxyは、必要ならばユーザ認証をクライアントに代わって行い、認証後の結果を「AUTHINFO PASS」コマンドの結果として返します。

nntpProxyは、「AUTHINFO PASS」コマンドが送信された時点で初めてリクエストされたサーバに接続を試みます。
サーバへの接続に失敗した場合は、「AUTHINFO PASS」コマンドの失敗という形でクライアントに応答します。

この手順で認証を行い、成功すればサーバへの接続も成功したことになります。

nntpProxy拡張プロトコル

先に述べた手順で接続を確立した場合、XOVERコマンドがフィルタされる点、 nntproxy.filteredというローカルグループが増える点を除けば通常の接続と同じです。

しかし、XOVERのフィルタリングは、しばしばクライアント側をタイムアウトさせる原因になります。
たとえば、100通の記事があり1通目と100通目以外はすべてnntpProxyによってフィルタされたとしましょう。すると、クライアント側からは、たった２通の記事の取り寄せに100通の記事を取り寄せる時間がかかっていることになります。
これは極端な例ですが、フィルタ対象（多くの場合SPAM）が多いグループをユーザが購読している場合は、これに近い現象が発生する場合がままあります。

nntpProxyは、このフィルタによるタイムアウトを防止するために、拡張モードを用意しています。
拡張モードに切り替えるためには、MODEコマンドを利用します。

(Client)	: MODE FILTER
(Server)	: 200 MODE is FILTER

もしユーザがnntpProxy v1.3.0より古いバージョンを使用している場合は、この拡張プロトコルに対応していないので、エラーコード「500」が返されます。

拡張モードに切り替わると、XOVERコマンドを発行した場合のレスポンスが変更され、通常のXOVERデータに混じって「filtered」という行が含まれてきます。
これは記事がnntpProxyによってフィルタリングされたことを示し、フィルタされた記事の位置にフィルタされた数だけ「filtered」行が返されます。
すなわち、行数という観点からのみ見た場合、本来返されるXOVERの行数とフィルタ後の行数は一致することになります。
対応クライアントは、filtered行を受け取ったら無視しなければなりません。

これにより、クライアントはサーバから実際に受け取った記事数とそのタイミングを把握でき、フィルタによるタイムアウトを防止できます。

ローカルグループについて

nntpProxyは、フィルタ対象になった記事を「nntpproxy.filtered」というローカルグループに移動します。
クライアントからは見かけ上、サーバに上記グループが存在するように見えますが、実際はnntpProxyがフィルタした記事の一覧を元に、架空のグループとして再構成しているだけです。
クライアントからこのローカルグループ上の記事に対するリクエストを受け取ると、nntpProxyはMessage-IDを利用してサーバに要求をします。
現在わかっている問題点は、Message-IDでの記事取得を制限しているサーバが少数ながら存在し、それらのサーバではローカルグループでの記事の取得ができないことです。

なお、ローカルグループへの記事の返信は、通常と同じ手順、すなわち

followup-to:ヘッダがあれば、そのグループ
なければNewsgroups:ヘッダのグループ

に返信すれば、通常どおりのやり取りができます。
注意しなければならないのは、実際の投稿先がローカルグループではないため、投稿した記事は必ずしもローカルグループに現れるとは限らないということです。
また、ローカルグループへの新規記事の投稿はできません。