Very Computer

would there be any sane list of where the different lists originate?
some lists just do not seem reliable (at least from my access point).
how can one find out where a list comes from?

No.  I'm definitely not sane, so you wouldn't want to trust any list
I might come up with...

Quote:> some lists just do not seem reliable (at least from my access point).

There are a few possibilities for this:  First, news propagation and
the performance of the machine you read from.  If articles are getting
dropped along the way, there's not much that can happen.

Second, message ID collisions.  Several lists, including private hierarchies
which are not supposed to be leaking out but do so regularly due to config
problems, use the same message ID as in the original post for their
messages, and what happens is that when two messages in different groups
have the same message ID, the first one to arrive is the only one that is
used, as news makes use of the message ID to determine uniqueness.  This
has been a problem recently (and repeatedly in the past) for the muc/mpc
hierarchies.  Further, with the same message going to multiple lists, only
one of the gated groups will actually carry the message.  It's a case of
first-come, first-served.

Third, it can also be that the gateway for a particular hierarchy is
failing to receive all the messages, which naturally results in those
messages going missing.  This is likely the case for hierarchies on the
other end of a poor connection halfway around the world.

Quote:> how can one find out where a list comes from?

The only way you can really do that is to follow the Path: header of
the posts in that newsgroup back to the originating site.  Often,
there will be an Organization: header added to give hints.

Not all groups with `freebsd' in the name carry traffic, as many of
them are from sites which normally do not intend their groups to be
propagated.  The active hierarchies I know of include
 sol.lists.freebsd.*  (message IDs massaged)
 muc.lists.freebsd.*  (message IDs left alone, crossposted to mpc.*)
 mpc.lists.freebsd.*  (see above)
 mailing.freebsd.*  (message IDs massaged)
 list.freebsd.*  (I'll have to look at this one)

Groups which are presently inactive, but have leaked traffic at some
time in the past, so should not be used, or are too slow to offer any
real competition to the above most of the time as seen here, include:
 ukr.comp.freebsd.*
 apana.lists.os.freebsd.*
 list.freebsd-*
 lists.freebsd.*
 hanse-ml.freebsd.*
 cs-monolit.gated.lists.freebsd.*
 mgate.freebsd.*
 clinet.lists.freebsd-*
 freebsd.*
 local.freebsd.*
 mgate.freebsd.*
Many of these lists will have traffic when read in their local area
(for example, apana.*) but should not have traffic outside.  There
are also further local hierarchies which have never leaked or which
I've rmgrouped after helping the admin plug the leak, which may show
up in the 90-thousand-group active file any competitive ISP will have,
like absnet.lists.freebsd.* .

Gack, looks like there are some new ones out there that I've gotta
track down...
64 newsgroup anarch.lists.freebsd.questions
6 newsgroup atom.list.freebsd.users
Sigh, a newsbastard's job never ends

meow,
barry bouwsma, tele danmark 'nternet, an 'meritech comp'ny

:Second, message ID collisions.  Several lists, including private hierarchies
:which are not supposed to be leaking out but do so regularly due to config
:problems, use the same message ID as in the original post for their
:messages, and what happens is that when two messages in different groups
:have the same message ID, the first one to arrive is the only one that is
:used, as news makes use of the message ID to determine uniqueness.  This
:has been a problem recently (and repeatedly in the past) for the muc/mpc
:hierarchies.

Yes.

:Further, with the same message going to multiple lists, only
:one of the gated groups will actually carry the message.  It's a case of
:first-come, first-served.

Yes.  :-(

:Third, it can also be that the gateway for a particular hierarchy is
:failing to receive all the messages, which naturally results in those
:messages going missing.  This is likely the case for hierarchies on the
:other end of a poor connection halfway around the world.

Yes.

Well, anyways:

: sol.lists.freebsd.*  (message IDs massaged)

This hierarchy is an open hierarchy that exports the FreeBSD lists.  It
is a one-way gateway:  the groups are moderated, and posts are not sent
back into the FreeBSD mailing lists.

As far as Barry's Point #2, I am working on that problem in my voluminous
spare time.

Point #3 shouldn't be too much of an issue, as I'm one of the US FreeBSD
mailing list exploder sites.

Apologies for the disruption in service over the last few days.  I had
some major network restructuring to do.

... JG

 [injected into news.admin.hierarchies for no particular reason other
 than for anyone who might be curious about adding this hierarchy,
 so shoot me]

And I've done the research I threatened to do.  It turns out that the
two hierarchies with significant traffic I noted, list.freebsd.* and
anarch.lists.freebsd.* , are using the same message IDs as the original
e-mail posts, causing problems with muc/mpc.

The originating gateway for the anarch.* hierarchy appears to be
news.nrw-online.de!anarch and when I stop being lazy, I'll get off my
bum and toss them a message inquiring about their hierarchy, but with
a name like anarch.* I can imagine their response to artificial imposition
of unwanted authority and organization.

Similarly, list.freebsd.* is coming from newsfeed.concentric.net!\
corp.g2networks.com and I'll think about doing the same thing with them.

Another thing for people running such gateways but trying to keep them
local to your organization, and similarly not mangling the message IDs
appropriately so as to guarantee uniqueness, is that if you fail to
receive the post to be gated in time by mail and it instead arrives by
news in your incoming feeds, and you either have the other hierarchies
created or are configured to remember all unwanted message IDs, you too
will be missing out on articles.

Yet Another Argument in favour of a common well-known well-managled
hierarchy to cover gated mailing lists to replace the chaos that exists
at present, with too many people needlessly duplicating the work of
others and making things worse in the process.

Quote:> : sol.lists.freebsd.*  (message IDs massaged)

> This hierarchy is an open hierarchy that exports the FreeBSD lists.  It
> is a one-way gateway:  the groups are moderated, and posts are not sent
> back into the FreeBSD mailing lists.

Sounds like a good place to apply my hackery for an additional group
status flag which both rejects unwanted posts (without moderation set)
and prevents local lusers from trying to post to the hierarchy and then
mailbombing UUnet or ISC or whoever gets moderated groups by default...

Say, um, Joe, you wouldn't want to send out some checkgroups every now
and then, since I seem to be seeing some traffic in my unwanted.log,
although I'm configured to act on all your newgroups, and created all
them when your messages arrived, unless I'm failing to get all the
traffic which shouldn't be since I've got idle time and I'm turning down
a full feed some 20 times over...

Maybe I need to arrange to guarantee that all your articles do go out,
as I'm rebuilding one of my machines at the moment to guarantee its
stability, so...  You'll get that info in private mail.

barry ``e-mail'aren\'t'us'' bouwsma

On Tue, 6 Oct 1998 11:29:53 +0200, Fluffy -- The Other White Meat
muc and mpc are two different hierarchies. The X-Posting in
*.lists.freebsd.* is just for nope-avoiding.

If there are other hierarchies gating the freebsd-list (without an
canonical group) it should be very easy to X-Post to other hierarchies
too.

Is it correct that there are freebsd-Groups in
{anarch,muc,mpc,}.lists.freebsd.* ?

Andi
--

======PGP-Fingerabdruck  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C======
   Aber die Halbwertszeit der Planungen der Stadtwerke werden wohl
    auch immer kuerzer ...                        Lucas Neubauer

: [injected into news.admin.hierarchies for no particular reason other
: than for anyone who might be curious about adding this hierarchy,
: so shoot me]

*BLAM*

:Yet Another Argument in favour of a common well-known well-managled
:hierarchy to cover gated mailing lists to replace the chaos that exists
:at present, with too many people needlessly duplicating the work of
:others and making things worse in the process.

Yeah.  :-/

:> : sol.lists.freebsd.*  (message IDs massaged)
:>
:> This hierarchy is an open hierarchy that exports the FreeBSD lists.  It
:> is a one-way gateway:  the groups are moderated, and posts are not sent
:> back into the FreeBSD mailing lists.
:
:Sounds like a good place to apply my hackery for an additional group
:status flag which both rejects unwanted posts (without moderation set)
:and prevents local lusers from trying to post to the hierarchy and then
:mailbombing UUnet or ISC or whoever gets moderated groups by default...

Your what?  I don't wanna know.  :-)

:Say, um, Joe, you wouldn't want to send out some checkgroups every now
:and then, since I seem to be seeing some traffic in my unwanted.log,
:although I'm configured to act on all your newgroups, and created all
:them when your messages arrived, unless I'm failing to get all the
:traffic which shouldn't be since I've got idle time and I'm turning down
:a full feed some 20 times over...

I'm also gatewaying some other stuff to help me test some code.  When I
get things working properly, I'll issue newgroup's for them, and also
checkgroups.  Yours isn't the only request I got for gatewaying...

My real problem right now is finding a way to decently handle crossposts.

... JG

Quote:>And I've done the research I threatened to do.  It turns out that the
>two hierarchies with significant traffic I noted, list.freebsd.* and
>anarch.lists.freebsd.* , are using the same message IDs as the original
>e-mail posts, causing problems with muc/mpc.
>The originating gateway for the anarch.* hierarchy appears to be
>news.nrw-online.de!anarch and when I stop being lazy, I'll get off my
>bum and toss them a message inquiring about their hierarchy, but with
>a name like anarch.* I can imagine their response to artificial imposition
>of unwanted authority and organization.

(Frank Ellert) who sends out the cancels for
 Crosspost between cl.* and not cl.* groups.
and gets his news-connectivity via anarch. I'm sure he'd hate anarch
being passively UDPed. Also try a traceroute and contact me if they
still get their IP-connectivity via ping.de ... :-)
--
"This is Jabbar," said Carrot. "He's sort of not the leader."
  -- Terry Pratchett, Jingo

Actually, I'm holding off on doing anything until I can arrange a
permanent e-mail address to receive responses of perplexed consternation
(perhaps I need to make a form letter, or give up this hobby entirely).

Quote:> and gets his news-connectivity via anarch. I'm sure he'd hate anarch
> being passively UDPed. Also try a traceroute and contact me if they

Actually, the biggest threat now to the continuity of threads appears to
be from list.freebsd.wozzis, rivalling the propagation speed from
muc.lists.freebsd.whozit.  No real punishment is particularly applicable,
as often the groups aren't supposed to be configured into outgoing feeds,
or if they are, the gator is quite willing to cooperate with others who
are doing the same thing, and nobody can be completely blameless in
situations like this.

On the other hand, I'm still seeing significant gaps in the
sol.lists.freebsd.wuzdat groups, which are filled by combining the two
other mentioned hierarchies, so I'm going to have to get on Joe's case as
threatened, since I should be losing articles equally if at all.  I mean,
taking a full feed some 20 times over each day should mean that someone is
keeping a few articles worth of backlog for us...

Barry Bouwsma