perl-nocem
Jeffrey M. Vinocur
jeff at litech.org
Sun May 14 13:56:30 UTC 2006
On Sun, 14 May 2006, Christoph Biedl wrote:
> Looking at perl-nocem I find some thing that deserve improvement:
>
> - "error" priority
Yeah, it would be nice to have a more elegant solution.
> - Doing the cancels
>
> At the moment perl-nocem forks a 'ctlinnd cancel' for each article to be
> cancelled which I consider rather expensive. [...]
Right. From the innd manpage:
CANCEL FEEDS
In order to efficiently apply a large number of local cancels (such as
from processing NoCeMs or from some other external source), INN sup-
ports a special feed mode available only to connections to the local
Unix domain socket (not to connections to any network sockets).
To enter this mode, connect to the Unix domain socket (pathrun/nntpin)
and send the command MODE CANCEL. The response will have code 284.
Every subsequent line sent on that connection should consist of a sin-
gle message ID. An attempt will be made to cancel that message ID, and
the server will reply 289 for success or 484 for failure. (Failure can
occur, for example, if the server is paused or throttled, or the Mes-
sage-ID is corrupt. Failure does not occur if the article to be can-
celled does not exist.)
As for having it accessible from the commandline, from the TODO file:
* A bulk cancel command using the MODE CANCEL interface. Possibly through
ctlinnd, although it may be a bit afield of what ctlinnd is currently
for.
But nobody's implemented it. This might be the time, though.
> - Extensions
>
> Obviously nocem processing may become subject of DoS attacks by flooding
> the accordings groups with forged headers and faked signatures. I'd like
> to propose an extension to counteract that threat by additionally checking
> against headers that cannot set in a POSTed article while the legitimate
> nocem sender can use his IHAVE connection for that.
I don't love this idea...it's awfully hackish, and makes a lot of
assumptions about what an attacker can and can't do. We've gotten along
reasonably well processing signed control messages without such measures,
so perhaps we can just wait and see if there's truly an issue before
worrying about it.
--
Jeffrey M. Vinocur
jeff at litech.org
More information about the inn-workers
mailing list