ietf-nntp LIST ACTIVE issues

Charles Lindsey chl at clw.cs.man.ac.uk
Mon Mar 24 02:35:45 PST 2003


In <yl8yv863i0.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:

>Charles Lindsey <chl at clw.cs.man.ac.uk> writes:
>> Russ Allbery <rra at stanford.edu> writes:

>>>      y         Local postings are allowed
>>>      n         No local postings are allowed, only remote ones
>>>      m         The group is moderated and all postings must be approved
>>>      j         Articles in this group are not kept, but only passed on
>>>      x         Articles cannot be posted to this newsgroup
>>>      =foo.bar  Articles are locally filed into the "foo.bar" group

>To rephrase all of these:

>A mode of y means that all messages are accepted.

>A mode of n means that messages from peers are accepted as normal, but
>messages posted by local readers are rejected.

Yes, but what is the definition of "peers" and "local"?

ITYM that, under 'n', articles arriving via IHAVE are accepted, but
articles arriving via POST are not (alternatively, articles are not
accepted under mode READER).

>A mode of m means that messages from peers are accepted iff they contain
>an Approved header, and local messages are forwarded to the moderator.

No, I don't think that is right. Why do "peers" and "local" come into it?
Surely if Approved is present it is accepted regardless, whether from
IHAVE or POST. How else do moderators themselves inject articles into the
system? But if Approved is absent, then articles from IHAVE are silently
dropped, and those from POST are sent to the moderator. At least, that is
what Usefor says.

>A mode of j means ...

OK

>A mode of x means that no messages are accepted for the group at all.
>This was a simple way of implementing crosspost filtering at the server
>level before embedded filters were common.  If you wanted to reject all
>messages to a particular group, even if they were crossposted to other
>groups you normally carried, you could add the group with mode x to reject
>all those messages.  This is mostly obsolete these days; it's better to do
>that sort of filtering in an embedded filter so that the groups don't show
>up in the active file.  (Although mode x groups do have the somewhat nice
>property of exposing some of your filtering rules to the clients
>directly.)

But that doesn't sound right to me. If an article is crossposted to comp.a
and comp.b, and comp.a is 'y' and comp.b is 'x', then I would expect it to
be stored under comp.a, but not under comp.b. At least, I think that is
what CNews does.

I would expect to set a group to 'x' if it was rmgrouped, but I wanted to
keep it around until the existing articles had expired. Similarly if I
intended to remove the group from my server for local policy reasons.

>A mode of = with an associated group means that articles from peers that
>would go into that group are instead filed into the associated group
>instead, and local reader attempts to read or post to the group tend to
>fail in bizarre and interesting ways.  Group aliasing isn't particularly
>well-supported by INN right now.

It's alive and well and living in CNews, but probably only because nobody
has tinkered with it for a while. It makes a nice feature for implementing
mvgroup properly (but Usefor did agree that "properly" was only a MAY, so
that INN could get away with a minimal implementation).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



More information about the ietf-nntp mailing list