Andrew,
You're bincancelling messages in linux.kernel, a newsgroup fed by a
mail2news gateway. The gated list is [email protected] (Cc), a
list to which sometimes binary patches are posted.
IMHO binaries are acceptable in linux.kernel. Could you consider stopping
bincancels in linux.kernel or even linux.*? Thanks,
--
Erik Hensema ([email protected])
Erik Hensema wrote:
> Andrew,
>
> You're bincancelling messages in linux.kernel, a newsgroup fed by a
> mail2news gateway. The gated list is [email protected] (Cc), a
> list to which sometimes binary patches are posted.
> IMHO binaries are acceptable in linux.kernel. Could you consider stopping
> bincancels in linux.kernel or even linux.*? Thanks,
Why bother? I thought use of Usenet was deprecated...
Jeff
> Why bother? I thought use of Usenet was deprecated...
groups.google.com is absolutely the most useful source of "how do I get
this to work" information in the world. I sure hope that never goes
away, it's how I find out if your drivers are working :)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
In newsgroup: linux.dev.kernel
>
> Erik Hensema wrote:
> > Andrew,
> >
> > You're bincancelling messages in linux.kernel, a newsgroup fed by a
> > mail2news gateway. The gated list is [email protected] (Cc), a
> > list to which sometimes binary patches are posted.
> > IMHO binaries are acceptable in linux.kernel. Could you consider stopping
> > bincancels in linux.kernel or even linux.*? Thanks,
>
>
> Why bother? I thought use of Usenet was deprecated...
>
Well, the official gateway linux.dev.kernel was closed a long time ago
because it was seen as the Sole Reason For Spam On Linux-Kernel. IIRC
it didn't change the spam volumes significantly, and really just
resulted in more gateways and more mail loops, but...
I also don't really think I have the energy to restart everything I
once set up, although I guess you never know. For now, though, too
many other things to do...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
>>>>> "Erik" == Erik Hensema <[email protected]> writes:
Erik> Andrew,
Erik> You're bincancelling messages in linux.kernel,
am I? hmm, that isn't intentional; looks like someone started feeding
me linux.* traffic without telling me. I've suspended bincancels there
for now, until I can sort that out.
Erik> a newsgroup fed by a mail2news gateway.
I don't personally consider that the fact that a group is gatewayed
from a mailing list to be significant when deciding how to apply Usenet
policies to it.
Erik> The gated list is [email protected] (Cc), a list to
Erik> which sometimes binary patches are posted. IMHO binaries are
Erik> acceptable in linux.kernel.
well, I would have to disagree (even if you don't think that binaries
coming via the mailing list would be a problem, there is still the
question of binaries posted via news - and the recent levels of abuse
in comp.binaries.*.d, rec.*, vmsnet.* etc. suggests that there are
plenty of people who are happy to post binaries anywhere they can
regardless of the real purpose of a group)
[copied to Marco in case he wishes to clarify matters]
--
Andrew.
On Tuesday 03 December 2002 02:49, Andrew Gierth wrote:
> I don't personally consider that the fact that a group is gatewayed
> from a mailing list to be significant when deciding how to apply Usenet
> policies to it.
Andrew, please note that I as a user of linux.kernel do actually consider it
significant. LKML (the gated list) is not part of Usenet and the mere fact
that at some point it is gated to a newsgroup and transported further via
NNTP doesn't make it a part. It's merely a service to people (like me) who
find a news interface more convenient and/or have trouble dealing with the
large volume of messages via mail.
Furthermore (or "that aside", if you want ... ), although I guess I could
conceivably be sympathetic to your cause of ridding Usenet from as much
in-appropriate content as possible, linux kernel patches, including binary
encoded ones, are not in fact in-appropriate content for linux.kernel, either
the list or the newsgroup.
Even on the mailing-list plain text patches are preffered, but when the patch
is large gzipping it is actually recommended:
http://www.tux.org/lkml/#s4-1
You for example today cancelled a completely appropriate post from Art Haas
(http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.0/0302.html) and I will
admit that actually annoys me quite a bit.
> Erik> The gated list is [email protected] (Cc), a list to
> Erik> which sometimes binary patches are posted. IMHO binaries are
> Erik> acceptable in linux.kernel.
>
> well, I would have to disagree (even if you don't think that binaries
> coming via the mailing list would be a problem, there is still the
> question of binaries posted via news
Fortunately, linux-kernel (the list) has active filtering itself, so anything
in-appropriate comming in through news will be filtered out in the same way
as the ones comming in through mail. Of course that doesn't help us NNTP
readers, but I guess we'll just have to deal with that. LKML is not strictly
non-binary-only, so cancelling simply on the criterium of binary attachments
is very inappropriate.
Might I therefore respectfully suggest you keep the bin-cancelling suspended?
Rene.
P.S. offline for a while, so will not be able to reply quickly.
Andrew Gierth <[email protected]> writes:
>>>>>> "Erik" == Erik Hensema <[email protected]> writes:
> Erik> a newsgroup fed by a mail2news gateway.
> I don't personally consider that the fact that a group is gatewayed
> from a mailing list to be significant when deciding how to apply Usenet
> policies to it.
Maybe think of the mailing list as a moderator that's permitted to approve
binaries and only cancel binaries that were posted directly to the group
rather than going through the list? That would seem to avoid any problems
with deleting legitimate traffic.
If people start flooding the list with binaries, I'm sure that will be
dealt with quite promptly, before Usenet even notices.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Jeff Garzik wrote:
>
>
> Why bother? I thought use of Usenet was deprecated...
>
> Jeff
>
I read the LKML at news:fa.linux.kernel since4 years, without problems
(no full mailbox box during vacations :-), and the headers are unchanged,
so the private reply are allowed)
ciao
giacomo
PS: fa 'domain' is USENET?
In article <[email protected]>,
Giacomo Catenazzi <[email protected]> wrote:
>I read the LKML at news:fa.linux.kernel since4 years, without problems
>(no full mailbox box during vacations :-), and the headers are unchanged,
>so the private reply are allowed)
The big problem is when multiple gateways to news exist in multiple
hierarchies. News servers accept a certain message only once - and
the only thing that is looked at is the message-id.
So if your news server gets fa.linux.kernel and linux.kernel, half
of the articles will end up in the first group and half of the
articles in the second.
That's why it's not a good idea anymore to read linux-kernel etc
mailinglists through news, you'll miss a lot of articles. Unless
you do the gatewaying yourself and have enough of a clue to
prevent the above scenario.
Mike (reading this with 'trn' in the /local/ lists.linux.kernel group).
--
They all laughed when I said I wanted to build a joke-telling machine.
Well, I showed them! Nobody's laughing *now*! -- [email protected]
On Dec 03, Andrew Gierth <[email protected]> wrote:
>I don't personally consider that the fact that a group is gatewayed
>from a mailing list to be significant when deciding how to apply Usenet
>policies to it.
Agreed.
>[copied to Marco in case he wishes to clarify matters]
(I'm the linux.* gateway operator.)
I'm not sure if there is a consensus about binaries in linux.* groups
which do not match *.binar*. OTOH last year I added linux.* to the
default cleanfeed configuration linux.* in the list of groups where
binaries are permitted and nobody ever complained.
If you want to be sure that the hierarchy is not hijacked by warez
kiddies you can just cancel everything not posted from /\.bofh\.it$/.
The real problem with linux.* is that when I started maintaining it I
only had the time to write the mail->news part, and never finished the
mail->news side, which has to be authenticated to avoid spam.
The plan is to have moderated groups where all articles are either
directly gated from the mailing list or first checked by my
robomoderation software, but I don't know when I'll find the time to
implement this.
--
ciao,
Marco
In article <[email protected]>,
Russ Allbery <[email protected]> wrote:
| Andrew Gierth <[email protected]> writes:
| > I don't personally consider that the fact that a group is gatewayed
| > from a mailing list to be significant when deciding how to apply Usenet
| > policies to it.
|
| Maybe think of the mailing list as a moderator that's permitted to approve
| binaries and only cancel binaries that were posted directly to the group
| rather than going through the list? That would seem to avoid any problems
| with deleting legitimate traffic.
|
| If people start flooding the list with binaries, I'm sure that will be
| dealt with quite promptly, before Usenet even notices.
Agreed. I gateway the list to an internal group just because the news
tools seem to be better than the mail tools for this. The filters in the
m/l should keep out problems.
I have no idea what the news2mail gateway is on the open net, I have
marked it moderated and ship everything back to the list address.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
>well, I would have to disagree (even if you don't think that binaries
>coming via the mailing list would be a problem, there is still the
>question of binaries posted via news - and the recent levels of abuse
>in comp.binaries.*.d, rec.*, vmsnet.* etc. suggests that there are
>plenty of people who are happy to post binaries anywhere they can
>regardless of the real purpose of a group)
>Andrew.
IMO, the person who makes the decision to cancel automatically takes the
responsibility for ensuring the cancellation doesn't suppress legitimate
content. If you don't have the time and energy to do it right, then don't do
it.
Spam is bad, but suppressing useful legitimate content because of
unsophisticated spam-checking algorithms is worse. Especially in this case
where it's not difficult to develop a more sophisticated algorithm, for
example, one that exempts posts that started on the mailing list.
DS
Miquel van Smoorenburg <[email protected]> writes:
> The big problem is when multiple gateways to news exist in multiple
> hierarchies. News servers accept a certain message only once - and the
> only thing that is looked at is the message-id.
> So if your news server gets fa.linux.kernel and linux.kernel, half of
> the articles will end up in the first group and half of the articles in
> the second.
fa.linux.kernel rewrites the message IDs. I believe that linux.kernel
does as well.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
>>>>> "David" == David Schwartz <[email protected]> writes:
David> Spam is bad, but suppressing useful legitimate content
David> because of unsophisticated spam-checking algorithms
this is nothing to do with spam; that's not the only form of abuse that
exists.
Perhaps you also missed the point from my first message that a) I don't
intentionally receive the linux.* groups and therefore had not previously
needed to consider whether they were getting binaries and b) that I stopped
as soon as this was drawn to my attention. (I did already have in place
exemptions for all the generally-known binaries hierarchies.)
--
Andrew.
On 04 Dec 2002 04:52:24 +0000, Andrew Gierth wrote:
>>>>>> "David" == David Schwartz <[email protected]> writes:
>David> Spam is bad, but suppressing useful legitimate content
>David> because of unsophisticated spam-checking algorithms
>this is nothing to do with spam; that's not the only form of abuse that
>exists.
My arguments apply equal well to all forms of abuse.
>Perhaps you also missed the point from my first message that a) I don't
>intentionally receive the linux.* groups and therefore had not previously
>needed to consider whether they were getting binaries and b) that I stopped
>as soon as this was drawn to my attention. (I did already have in place
>exemptions for all the generally-known binaries hierarchies.)
No, I caught those points. However, you cut the comments I was responding to
and then pretended that I was responding to your actions. You said:
>well, I would have to disagree (even if you don't think that binaries
>coming via the mailing list would be a problem, there is still the
>question of binaries posted via news - and the recent levels of abuse
>in comp.binaries.*.d, rec.*, vmsnet.* etc. suggests that there are
>plenty of people who are happy to post binaries anywhere they can
>regardless of the real purpose of a group)
And *that* is what I was responding to.
DS
>>>>> "Marco" == Marco d'Itri <[email protected]> writes:
>> [copied to Marco in case he wishes to clarify matters]
Marco> (I'm the linux.* gateway operator.)
Marco> I'm not sure if there is a consensus about binaries in linux.*
Marco> groups which do not match *.binar*. OTOH last year I added
Marco> linux.* to the default cleanfeed configuration linux.* in the
Marco> list of groups where binaries are permitted and nobody ever
Marco> complained.
did they notice, though?
(I'd suggest linux.binaries.*, if not for the fact that people would
probably start posting distribution CDs and apps there.)
Marco> If you want to be sure that the hierarchy is not hijacked by
Marco> warez kiddies you can just cancel everything not posted from
Marco> /\.bofh\.it$/.
you could have put that in cleanfeed too :-)
Cancelling after-the-fact is always only going to be second best, and
the only reason I do it at all is because the alternative is to do
nothing and watch the problem get worse.
--
Andrew.
On Dec 05, Andrew Gierth <[email protected]> wrote:
> Marco> I'm not sure if there is a consensus about binaries in linux.*
> Marco> groups which do not match *.binar*. OTOH last year I added
> Marco> linux.* to the default cleanfeed configuration linux.* in the
> Marco> list of groups where binaries are permitted and nobody ever
> Marco> complained.
>did they notice, though?
Who knows? But I suppose they will notice if this would ever become a
problem.
>(I'd suggest linux.binaries.*, if not for the fact that people would
>probably start posting distribution CDs and apps there.)
Everything should be gated below linux.binaries.* then...
The reason I think it's acceptable to not do this is that the traffic is
low even when a few binaries are gated.
Someday[1] I plan to create a linux.binaries.patches group to distribute
kernel patches, but as usual it will be moderated.
> Marco> If you want to be sure that the hierarchy is not hijacked by
> Marco> warez kiddies you can just cancel everything not posted from
> Marco> /\.bofh\.it$/.
>you could have put that in cleanfeed too :-)
At the time I still hoped to be able to switch the groups to moderated
soon.
[1] Or closer, if somebody will contribute a script able to detect new
kernel patches in a kernel.org mirror...
--
ciao,
Marco
Andrew Gierth wrote:
>the only reason I do it at all is because the alternative is to do
>nothing and watch the problem get worse.
At this time, it sounds like the existing spam countermeasures
on the lkml mailing list work well enough that your bincancels were
doing more harm than good. That could change in future. At that
point, I suspect that the bincanelling would be done at the mailing
list. So, I'd say leave bincanceling of linux.kernel off and that'll
be the end of this issue (at least until someone specifically requests
otherwise).
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."