The news server INN

Julien ÉLIE | 7 Mar 2009 20:31

Checkgroups handling

Hi,

There are a few patterns which do not work with INN 2.4 as for
checkgroups processing.

Suppose we have the following newsgroups in a checkgroups:

  comp.binaries
  comp.foo.bar
  news.foo
  news.foo.bar

And now in control.ctl:

1/
  checkgroups:from:comp.*:verify-...
  checkgroups:from:news.*:doit

How should we handle that?  Is it OK to use the most restrictive situation
for the *whole* checkgroups, that is to say "verify" here, for both comp.*
and news.*?
Or, something that would be better, should we process the checkgroups twice?
(One time for comp.* [minus possible dropped newsgroups] and another time
for news.* [minus possible dropped newsgroups] alone?)
Any other suggestions?

With INN 2.4, only the news.* part would be done and comp.* not treated at all.

2/
  checkgroups:same-from:foo.*:verify-key-foo

(Continue reading)

headers

Russ Allbery | 7 Mar 2009 21:02

Re: Checkgroups handling

Julien ÉLIE <julien <at> trigofacile.com> writes:

> Suppose we have the following newsgroups in a checkgroups:
>
>  comp.binaries
>  comp.foo.bar
>  news.foo
>  news.foo.bar
>
> And now in control.ctl:
>
> 1/
>  checkgroups:from:comp.*:verify-...
>  checkgroups:from:news.*:doit
>
> How should we handle that?  Is it OK to use the most restrictive
> situation for the *whole* checkgroups, that is to say "verify" here, for
> both comp.* and news.*?

> Or, something that would be better, should we process the checkgroups
> twice?  (One time for comp.* [minus possible dropped newsgroups] and
> another time for news.* [minus possible dropped newsgroups] alone?)

> Any other suggestions?
>
> With INN 2.4, only the news.* part would be done and comp.* not treated
> at all.

control-archive currently extracts the first group from the checkgroups,
finds the rule in control.ctl that would correspond to that group, and

(Continue reading)

headers

Julien ÉLIE | 7 Mar 2009 22:45

Re: Checkgroups handling

Hi Russ,

> 1. Build a list of applicable rules by suppressing earlier rules that are
>    overridden by later ones.  I think we can do this by saying that if the
>    first three components of the rule are the same, the later rule is
>    taken to be an override of the earlier rule and the earlier rule is
>    deleted.  (However, see below.)
>
> 2. For an incoming checkgroups, find all checkgroups rules that match that
>    from address.  If any of them have verify actions, ensure that the
>    checkgroups is signed by that key and discard all rules where that
>    validation fails.
>
> 3. For each rule remaining, apply the pattern as a filter and act on the
>    checkgroups after non-matching lines have been filtered out.

[...]

> We can't just make drop special since the user may use mail or some other
> action in the override.

Why not something like that:

  foo.bar1
  foo.bar2.first
  foo.bar2.second
  foo.bar3.first
  foo.bar3.second
  foo.bar4
  foo.bar5

(Continue reading)