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