Bulk moderator vacancies anouncements
Adam H. Kerman
vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
Why, It's Obvious! tm
I didn't look to see if each of the 8 has an actual unreachable moderator,
or if it's an abuse of process like Tim pulled a few months back, or just
an abuse of process by being totally impractical to do so many at once as
no one is looking for the audience discussing these topics.
For those of you unfamiliar with the concept of an audience, a prerequisite
for Board membership, these would be people discussing the topic. One
looks for said audience with a Google Groups search, flawed as that may be
these days, to identify possible newsgroups where said discussion is taking
place, to see if anyone is interested in volunteering to be moderator. It's
actual work, something like justification, and it's so much easier to post
the pre-written announcements to news.announce.newgroups and just change
the group name.
I'm not sure I care whether this is abuse of process or incompetence, but
I do expect the usual suspects to be along shortly. Kathy will assure me
there's no abuse of process, without explaining why. Steve will be all
indignant. Thomas will explain that if I'm against it, clearly the Board
is on the right track.
Peter will volunteer for all 8 newsgroups. Kathy will feign politeness
to Peter.
And it will all be 'Ratz's fault.
Alexander Bartolich
> In the Board's infinite wisdom, it is pretending to try to fill moderator
> vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
> Why, It's Obvious!
You ain't seen nothing yet.
There are 170 moderated groups without traffic in the last 12 months.
The plan is to start 8 proceedings every four weeks, for about one and
a half years straight.
> [...]
> I'm not sure I care whether this is abuse of process or incompetence,
> I do expect the usual suspects to be along shortly. Kathy will assure me
> there's no abuse of process, without explaining why. Steve will be all
> indignant. Thomas will explain that if I'm against it, clearly the Board
> is on the right track.
I see you enjoy the show. That's what really matters most.
--
Adam H. Kerman
>Adam H. Kerman wrote:
>>In the Board's infinite wisdom, it is pretending to try to fill moderator
>>vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
>>Why, It's Obvious!
>You ain't seen nothing yet.
>There are 170 moderated groups without traffic in the last 12 months.
>The plan is to start 8 proceedings every four weeks, for about one and
>a half years straight.
It's not any kind of a plan if you're not going to look for replacement
moderators. I encourage you to post the entire list at once so it's
perfectly clear that you aren't looking for replacements. Dragging it
out doesn't make it a process.
>>[...]
>>I'm not sure I care whether this is abuse of process or incompetence,
>>I do expect the usual suspects to be along shortly. Kathy will assure me
>>there's no abuse of process, without explaining why. Steve will be all
>>indignant. Thomas will explain that if I'm against it, clearly the Board
>>is on the right track.
>I see you enjoy the show. That's what really matters most.
Nice selective snipping there, dude.
Dave Sill
> Adam H. Kerman wrote:
>> In the Board's infinite wisdom, it is pretending to try to fill moderator
>> vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
>> Why, It's Obvious!
This is not a Board project. It was Alexander's idea, and he's leading
it. It's a project that anyone could have undertaken, not just a member
of the Board.
-Dave
Adam H. Kerman
>>Adam H. Kerman wrote:
>>>In the Board's infinite wisdom, it is pretending to try to fill moderator
>>>vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
>>>Why, It's Obvious!
>This is not a Board project. It was Alexander's idea, and he's leading
>it. It's a project that anyone could have undertaken, not just a member
>of the Board.
My predictions were off. I didn't predict denial.
Theo Markettos
> I didn't look to see if each of the 8 has an actual unreachable moderator,
> or if it's an abuse of process like Tim pulled a few months back, or just
> an abuse of process by being totally impractical to do so many at once as
> no one is looking for the audience discussing these topics.
I don't think you read the RFDs too closely:
RATIONALE:
Probe posts to this group resulted in bounces.
<comp-arch...@moderators.isc.org>: host
moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address
(in reply to RCPT TO command)
I'm quite happy that someone has chosen to investigate this, and I'm the
original proponent of that group.
> For those of you unfamiliar with the concept of an audience, a prerequisite
> for Board membership, these would be people discussing the topic. One
> looks for said audience with a Google Groups search, flawed as that may be
> these days, to identify possible newsgroups where said discussion is taking
> place, to see if anyone is interested in volunteering to be moderator. It's
> actual work, something like justification, and it's so much easier to post
> the pre-written announcements to news.announce.newgroups and just change
> the group name.
Perhaps. But if the group is dead (in the sense of no postings for a year),
why are people in other groups going to be interested in taking it over
(unless it's part of an existing subtree, eg foo.bar.announce)?
Though perhaps groups the original creation RFD/CFV was posted to (or their
successors) would be an easy start.
Theo
Adam H. Kerman
>>I didn't look to see if each of the 8 has an actual unreachable moderator,
>>or if it's an abuse of process like Tim pulled a few months back, or just
>>an abuse of process by being totally impractical to do so many at once as
>>no one is looking for the audience discussing these topics.
>I don't think you read the RFDs too closely:
It makes no difference what they said, when my concern is that they weren't
crossposted in the traditional manner.
>RATIONALE:
>Probe posts to this group resulted in bounces.
><comp-arch...@moderators.isc.org>: host
> moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address
> (in reply to RCPT TO command)
>I'm quite happy that someone has chosen to investigate this, and I'm the
>original proponent of that group.
Are you the current moderator? Then your special role as proponent ended a
long time ago.
>>For those of you unfamiliar with the concept of an audience, a prerequisite
>>for Board membership, these would be people discussing the topic. One
>>looks for said audience with a Google Groups search, flawed as that may be
>>these days, to identify possible newsgroups where said discussion is taking
>>place, to see if anyone is interested in volunteering to be moderator. It's
>>actual work, something like justification, and it's so much easier to post
>>the pre-written announcements to news.announce.newgroups and just change
>>the group name.
>Perhaps.
Perhaps nothing. That's how you look for an audience on Usenet. There is
no other way.
>But if the group is dead (in the sense of no postings for a year),
>why are people in other groups going to be interested in taking it over
>(unless it's part of an existing subtree, eg foo.bar.announce)?
I don't know, nor does anyone else, till the question is asked of them.
>Though perhaps groups the original creation RFD/CFV was posted to (or their
>successors) would be an easy start.
That would be better than doing nothing at all to look for the audience,
which is my complaint here.
How did you learn of it: You read news.announce.newgroups?
Steve Bonine
> Theo Markettos<theom...@chiark.greenend.org.uk> wrote:
>> Adam H. Kerman<a...@chinet.com> wrote:
>
>>> I didn't look to see if each of the 8 has an actual unreachable moderator,
>>> or if it's an abuse of process like Tim pulled a few months back, or just
>>> an abuse of process by being totally impractical to do so many at once as
>>> no one is looking for the audience discussing these topics.
>
>> I don't think you read the RFDs too closely:
>
> It makes no difference what they said, when my concern is that they weren't
> crossposted in the traditional manner.
The traditional manner. Exactly what is the traditional manner for
posting a Moderator Vacancy Investigation, a device which has no
tradition? Posting it to the group in question is reasonable. I'm sure
that if they had been posted to other newsgroups, you would have been
throwing a hissy fit that the board was polluting newsgroups with
unwanted traffic.
Since this seems to bother you enough to post a complaint, how about
doing something positive for a change? There is nothing to preclude you
from examining the MVI and investigating potential newsgroups into which
to post a pointer. Of course it does mean that you might have to take
the time to actually read the MVI.
>> RATIONALE:
>
>> Probe posts to this group resulted in bounces.
>
>> <comp-arch...@moderators.isc.org>: host
>> moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address
>> (in reply to RCPT TO command)
>
>> I'm quite happy that someone has chosen to investigate this, and I'm the
>> original proponent of that group.
>
> Are you the current moderator? Then your special role as proponent ended a
> long time ago.
At least he had the interest to make a positive comment. Your attack is
sad.
>>> For those of you unfamiliar with the concept of an audience, a prerequisite
>>> for Board membership, these would be people discussing the topic. One
>>> looks for said audience with a Google Groups search, flawed as that may be
>>> these days, to identify possible newsgroups where said discussion is taking
>>> place, to see if anyone is interested in volunteering to be moderator. It's
>>> actual work, something like justification, and it's so much easier to post
>>> the pre-written announcements to news.announce.newgroups and just change
>>> the group name.
>
>> Perhaps.
>
> Perhaps nothing. That's how you look for an audience on Usenet. There is
> no other way.
Right. According to that oracle of all things Usenet, Adam Kerman.
But I repeat . . . if you care to add something to Usenet, rather than
just toss stones, there's nothing to prevent you from finding this
audience you are so sure exists and trying to find someone there who
cares about the newsgroup.
>> But if the group is dead (in the sense of no postings for a year),
>> why are people in other groups going to be interested in taking it over
>> (unless it's part of an existing subtree, eg foo.bar.announce)?
>
> I don't know, nor does anyone else, till the question is asked of them.
So ask it.
>> Though perhaps groups the original creation RFD/CFV was posted to (or their
>> successors) would be an easy start.
>
> That would be better than doing nothing at all to look for the audience,
> which is my complaint here.
>
> How did you learn of it: You read news.announce.newgroups?
Perhaps (duh) he still watches the group that he proposed, where the MVI
was posted. Anyone who is still subscribed to the groups in question
would see the MVI.
But I'm sure you can do better. Show us.
Adam H. Kerman
>Adam H. Kerman wrote:
>>Theo Markettos<theom...@chiark.greenend.org.uk> wrote:
>>>Adam H. Kerman<a...@chinet.com> wrote:
>>>>I didn't look to see if each of the 8 has an actual unreachable moderator,
>>>>or if it's an abuse of process like Tim pulled a few months back, or just
>>>>an abuse of process by being totally impractical to do so many at once as
>>>>no one is looking for the audience discussing these topics.
>>>I don't think you read the RFDs too closely:
>>It makes no difference what they said, when my concern is that they weren't
>>crossposted in the traditional manner.
>The traditional manner. Exactly what is the traditional manner for
>posting a Moderator Vacancy Investigation, a device which has no
>tradition? Posting it to the group in question is reasonable. I'm sure
>that if they had been posted to other newsgroups, you would have been
>throwing a hissy fit that the board was polluting newsgroups with
>unwanted traffic.
Snarl. Growl. Yipyipyipyipyipyipyipyap
Steve Bonine
> Snarl. Growl. Yipyipyipyipyipyipyipyap
I'll take this as a "no" to my challenge to do something constructive
for a change.
This reminds me of the cartoon of "what pets hear". You see the pet
owner talking to his cat, praising it, extolling its virtues. Then you
are shown what the cat hears -- the word "tuna". I obviously did not
say the words you wanted to hear.
Adam H. Kerman
>Adam H. Kerman wrote:
>>Snarl. Growl. Yipyipyipyipyipyipyipyap
>I'll take this as a "no" to my challenge to do something constructive
>for a change.
Steve, I challenge YOU to do something constructive for a change. Let
your masters fend for themselves and go to your corner. There's a good
doggy.
Steve Bonine
> Steve Bonine<s...@pobox.com> wrote:
>> Adam H. Kerman wrote:
>
>>> Snarl. Growl. Yipyipyipyipyipyipyipyap
>
>> I'll take this as a "no" to my challenge to do something constructive
>> for a change.
>
> Steve, I challenge YOU to do something constructive for a change.
I help moderate two newsgroups. I'm a member of group mentors and have
provided advice and encouragement to proponents. I help out with a few
minor administrative tasks for the board. I occasionally make
constructive comments and provide suggestions that are reasonable. I am
comfortable that I contribute to Usenet in a positive way.
You will, of course, disagree with this. But that's your contribution
to Usenet -- disagreement.
David Bostwick
Adam's reply will not be a response, but the cry of defeat: "Straw man! Straw
man!"
Brian Mailman
It's just part of the process, you should assume it automatically.
B/
Brian Mailman
Wow, that took an hour and 20 minutes to reply. Why are you trying to
cause trouble by posting to an old thread?
B/
Mark Kramer
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>I don't think you read the RFDs too closely:
>
>
>RATIONALE:
>
>Probe posts to this group resulted in bounces.
Then the claim that this is to protect those poor people who try to post
and never see any response is false. Thanks for clarifying that. They
aren't left hanging waiting for something to happen, they are told
outright there is a problem and they won't get help here.
Steve Bonine
Are you really this clueless, or are you pretending for the sake of
tossing yet another stone? The bounce goes back to the news server that
sent the email, not to the user. The only way the user will see a
bounce is by knowing how to send a probe to the ISC relay.
Adam H. Kerman
>Steve Bonine <s...@pobox.com> wrote:
>>Adam H. Kerman wrote:
>>>Steve Bonine<s...@pobox.com> wrote:
>>>>Adam H. Kerman wrote:
>>>>>Snarl. Growl. Yipyipyipyipyipyipyipyap
>>>>I'll take this as a "no" to my challenge to do something constructive
>>>>for a change.
>>>Steve, I challenge YOU to do something constructive for a change.
>>I help moderate two newsgroups. I'm a member of group mentors and have
>>provided advice and encouragement to proponents. I help out with a few
>>minor administrative tasks for the board. I occasionally make
>>constructive comments and provide suggestions that are reasonable. I am
>>comfortable that I contribute to Usenet in a positive way.
>>You will, of course, disagree with this. But that's your contribution
>>to Usenet -- disagreement.
>Adam's reply will not be a response, but the cry of defeat: "Straw man!
>Straw man!"
Steve's a happy puppy today: A second slurper!
Mark Kramer
Steve Bonine <s...@pobox.com> wrote:
>Mark Kramer wrote:
>> Then the claim that this is to protect those poor people who try to post
>> and never see any response is false. Thanks for clarifying that. They
>> aren't left hanging waiting for something to happen, they are told
>> outright there is a problem and they won't get help here.
>
>Are you really this clueless, or are you pretending for the sake of
>tossing yet another stone? The bounce goes back to the news server that
>sent the email, not to the user.
Then the server is misconfigured. The email is FROM the user, not the
server. If the server puts itself instead of the user in the envelope
from, it is lying. There is no reason to protect the user from bounces due
to delivery failures on a moderated group and every reason to expose them.
>The only way the user will see a
>bounce is by knowing how to send a probe to the ISC relay.
Or by reading their email when using a properly configured news system.
Of course, if their From header is munged, they face the perpetual
issue of not getting email responses, but that was a choice freely made,
and not part of this discssion.
Doug Freyburger
>
> .... I'm a member of group mentors and have
> provided advice and encouragement to proponents ...
Have you seen any traffic on that list in the last two years?
Steve Bonine
I believe it has been about a year since there was any activity there.
Theo Markettos
>
> Perhaps (duh) he still watches the group that he proposed, where the MVI
> was posted. Anyone who is still subscribed to the groups in question
> would see the MVI.
The above. I do read news.announce.newgroups, but saw it in
comp.arch.hobbyist first.
I've just discovered that my newsfeed is only carrying crossposts to
news.groups.proposals, but no messages posted to only that group. So I
can't see any discussion in there (without going to Google). I've asked my
newsadmin to fix it, and when it's working I'll do a bit more to see if
there's interest in c.a.h from neighbouring groups.
Theo
David Bostwick
At least I didn't wait a week. Did I at least spell everything correctly?
David Bostwick
Dang. Wrong canned response. Shoulda flipped the coin a couple more times.
Brian Mailman
> In article <io6dnafctPHbD23X...@supernews.com>, Brian Mailman <bmai...@sfo.invalid> wrote:
>>David Bostwick wrote:
>>> In article <7lavhsF...@mid.individual.net>, Steve Bonine <s...@pobox.com>
>> wrote:
>>>>Adam H. Kerman wrote:
>>>>> Steve Bonine<s...@pobox.com> wrote:
>>>>>> Adam H. Kerman wrote:
>>>>>
>>>>>>> Snarl. Growl. Yipyipyipyipyipyipyipyap
>>>>>
>>>>>> I'll take this as a "no" to my challenge to do something constructive
>>>>>> for a change.
>>>>>
>>>>> Steve, I challenge YOU to do something constructive for a change.
>>>>
>>>>I help moderate two newsgroups. I'm a member of group mentors and have
>>>>provided advice and encouragement to proponents. I help out with a few
>>>>minor administrative tasks for the board. I occasionally make
>>>>constructive comments and provide suggestions that are reasonable. I am
>>>>comfortable that I contribute to Usenet in a positive way.
>>>>
>>>>You will, of course, disagree with this. But that's your contribution
>>>>to Usenet -- disagreement.
>>>
>>> Adam's reply will not be a response, but the cry of defeat: "Straw man!
>> Straw
>>> man!"
>>
>>Wow, that took an hour and 20 minutes to reply. Why are you trying to
>>cause trouble by posting to an old thread?
>
You're so good, so very very good.
> Did I at least spell everything correctly?
Who cares?
Brian Mailman
> In article <io6dnafctPHbD23X...@supernews.com>, Brian Mailman <bmai...@sfo.invalid> wrote:
>>David Bostwick wrote:
>>> In article <7lavhsF...@mid.individual.net>, Steve Bonine <s...@pobox.com>
>> wrote:
>>>>Adam H. Kerman wrote:
>>>>> Steve Bonine<s...@pobox.com> wrote:
>>>>>> Adam H. Kerman wrote:
>>>>>
>>>>>>> Snarl. Growl. Yipyipyipyipyipyipyipyap
>>>>>
>>>>>> I'll take this as a "no" to my challenge to do something constructive
>>>>>> for a change.
>>>>>
>>>>> Steve, I challenge YOU to do something constructive for a change.
>>>>
>>>>I help moderate two newsgroups. I'm a member of group mentors and have
>>>>provided advice and encouragement to proponents. I help out with a few
>>>>minor administrative tasks for the board. I occasionally make
>>>>constructive comments and provide suggestions that are reasonable. I am
>>>>comfortable that I contribute to Usenet in a positive way.
>>>>
>>>>You will, of course, disagree with this. But that's your contribution
>>>>to Usenet -- disagreement.
>>>
>>> Adam's reply will not be a response, but the cry of defeat: "Straw man!
>> Straw
>>> man!"
>>
>>Wow, that took an hour and 20 minutes to reply. Why are you trying to
>>cause trouble by posting to an old thread?
> At least I didn't wait a week.
...and besides, why should I rush to find the latest pile of steaming
Bostwick? When I decide to open News, it'll still be steaming.
B/
Brian Mailman
> Mark Kramer wrote:
>> In article<Niv*Ns...@news.chiark.greenend.org.uk>,
>> Theo Markettos<theom...@chiark.greenend.org.uk> wrote:
>>> I don't think you read the RFDs too closely:
>>>
>>>
>>> RATIONALE:
>>>
>>> Probe posts to this group resulted in bounces.
>>
>> Then the claim that this is to protect those poor people who try to post
>> and never see any response is false. Thanks for clarifying that. They
>> aren't left hanging waiting for something to happen, they are told
>> outright there is a problem and they won't get help here.
>
> Are you really this clueless, or are you pretending for the sake of
> tossing yet another stone? The bounce goes back to the news server that
Wow. How'd you get to be a "head moderator" when you don't know how
News works?
B/
Brian Mailman
Yeah, he could have been oh-so-original and done the "but YOU do it
too!" one that you find oh-so-effective.
B/
Alexander Bartolich
man inn.conf
# [...]
# mta
#
# The command to use when mailing postings to moderators and
# for the use of innmail(1). The message, with headers and an added
# To: header, will be piped into this program. The string %s, if
# present, will be replaced by the e-mail address of the moderator.
# It's strongly recommended for this command to include %s on the
# command line rather than use the addresses in the To: and Cc: headers
# of the message, since the latter approach allows the news server
# to be abused as a mechanism to send mail to arbitrary addresses and
# will result in unexpected behavior. There is no default value for
# this parameter; it must be set in inn.conf or a fatal error message
# will be logged via syslog.
#
# For most systems, "/usr/lib/sendmail -oi -oem %s" (adjusted for the
# correct path to sendmail, and between double quotes) is a good choice.
Consulting the man page of sendmail to determine the behaviour of the
default installation is left as an exercise to the reader.
--
David Bostwick
[...]
>
>Yeah, he could have been oh-so-original and done the "but YOU do it
>too!" one that you find oh-so-effective.
>
>B/
See, Brian, I knew you could respond right away if it was important. Three
replies in just a few minutes. I'm all a-tingle, even if they were repeats.
Thanks for the ego boost.
Mark Kramer
Alexander Bartolich <alexander...@gmx.at> wrote:
># The command to use when mailing postings to moderators and
># for the use of innmail(1). The message, with headers and an added
># To: header, will be piped into this program. The string %s, if
># present, will be replaced by the e-mail address of the moderator.
># It's strongly recommended for this command to include %s on the
># command line rather than use the addresses in the To: and Cc: headers
># of the message, since the latter approach allows the news server
># to be abused as a mechanism to send mail to arbitrary addresses and
># will result in unexpected behavior. There is no default value for
># this parameter; it must be set in inn.conf or a fatal error message
># will be logged via syslog.
>#
># For most systems, "/usr/lib/sendmail -oi -oem %s" (adjusted for the
># correct path to sendmail, and between double quotes) is a good choice.
>
>Consulting the man page of sendmail to determine the behaviour of the
>default installation is left as an exercise to the reader.
You've now described the appearance of the DESTINATION address (the
moderator), but not the ignorance of the sender. Of course the To: header
needs to be ignored since most posters to moderated groups don't include
a To: header. They don't know what the address is. If they've included
one, then the news agent will take care of mailing the copy there.
-oi "Ignore dots" and -oem "mailback errors" doesn't change the fact
that the sender of the message is known and is the proper place for
bounces to be sent. Don't pretend that the sender isn't known; the
From: header is MANDATORY in news, don'tcha know?
Or is the difference between the moderator (recipient) and sender (sender)
too hard to keep track of?
Peter J Ross
<da...@sill.org> wrote:
> On 11/02/09 01:13, Alexander Bartolich wrote:
>> Adam H. Kerman wrote:
>>> In the Board's infinite wisdom, it is pretending to try to fill moderator
>>> vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
>>> Why, It's Obvious!
>
> This is not a Board project. It was Alexander's idea, and he's leading
> it. It's a project that anyone could have undertaken, not just a member
> of the Board.
Note, however, that only people willing to participate in the NGP
treehouse have the opportunity to post RFDs.
Questions for Alexander:
Did you try to consult Jim Riley, the acknowledged expert on "dead"
moderated groups?
If you don't find suitable moderators for the "dead" groups with your
current MVI posts, what do you propose to do next? Search further or
propose rmgrouping?
Why did you undertake this project after becoming a Bamby, not before?
--
PJR :-)
slrn newsreader v0.9.9p1: http://slrn.sourceforge.net/
extra slrn documentation: http://slrn-doc.sourceforge.net/
newsgroup name validator: http://pjr.lasnobberia.net/usenet/validator
Peter J Ross
<a...@chinet.com> wrote:
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
^^^^^^
<...>
Dear Adam,
Search for "chiark" in uk.net.news.management. Their antics may amuse
you.
It's likely that this element of the Chiark Gestalt Entity has drifted
into news.groups because one can as easily shit on two hierarchies as
on one.
<...>
Peter J Ross
Freyburger <dfre...@yahoo.com> wrote:
Have you posted any of your notorious BI>100 spam to it?
In fact, of course, newsgroup proponents aren't as stupid as you'd
like them to be. They receive all the advice and encouragement they
need right here in news.groups, and wisely ignore a kooky gang of
self-proclaimed "mentors".
Peter J Ross
<theom...@chiark.greenend.org.uk> wrote:
Even the University of Cambridge doesn't carry the otiose NGP
treehouse?
Wow.
Btw, you won't find much discussion in the NGP treehouse even in
Google Groups. The discussion mostly happens here, not there.
Alexander Bartolich
> Alexander Bartolich <alexander...@gmx.at> wrote:
>> [...]
>> Consulting the man page of sendmail to determine the behaviour of the
>> default installation is left as an exercise to the reader.
>
> You've now described the appearance of the DESTINATION address (the
> moderator), but not the ignorance of the sender.
What part of "Consulting the man page of sendmail is left as an
exercise to the reader" did you not understand?
Unless you specify option "-f", sendmail will determine the envelope
address based on the user ID it is running with.
INN does not use this option. Thus a broken submission address
will result in a bounce to the user account of the news server.
The contents of From: or Sender: is completely ignored for this.
> [...]
> Don't pretend that the sender isn't known; the
> From: header is MANDATORY in news, don'tcha know?
>
> Or is the difference between the moderator (recipient) and
> sender (sender) too hard to keep track of?
The communication between Usenet server and moderation address is not
configurable by the user. So it is a good thing that detailed error
messages are sent to the people that can actually fix (or at least
understand) the problem.
On the other hand the information that an error occured is valuable to
the user. So I would appreciate it if bounces were automatically for-
warded. Doing so manually is tedious and error-prone.
However, it is one thing to complain about the default behaviour of
contemporary Usenet servers and a completely different thing to claim
that the behaviour does not exist.
Message-ID: <hcq45f$dsm$1...@pcls6.std.com>
# From: [...] (Mark Kramer)
# [...]
# >Probe posts to this group resulted in bounces.
#
# Then the claim that this is to protect those poor people who try to post
# and never see any response is false. Thanks for clarifying that. They
# aren't left hanging waiting for something to happen, they are told
# outright there is a problem and they won't get help here.
I really don't understand why you keep on doing this. I mean, every-
body here can verify this issue, even without delving into the details
of manual pages. Just use your newsreader to post to one of the broken
groups and see whether you get a bounce. Then repeat the exercise with
your email client.
What do you expect by being rude, ignorant and easily refutable?
--
Mark Kramer
Alexander Bartolich <alexander...@gmx.at> wrote:
>Mark Kramer wrote:
>> Alexander Bartolich <alexander...@gmx.at> wrote:
>>> [...]
>>> Consulting the man page of sendmail to determine the behaviour of the
>>> default installation is left as an exercise to the reader.
>>
>> You've now described the appearance of the DESTINATION address (the
>> moderator), but not the ignorance of the sender.
>
>What part of "Consulting the man page of sendmail is left as an
>exercise to the reader" did you not understand?
Sir, I consulted the man page for sendmail. It explains the '-oi' flag
(ignore dots), and the '-oem' (mail errors) options, but does not explain
why one would ignore a critical piece of information like "who is the
real sender" when sending email to a moderation submission address. It
speaks nothing about that. Maybe your man page is different.
>Unless you specify option "-f", sendmail will determine the envelope
>address based on the user ID it is running with.
And you've yet to explain why the information about who the real sender
is should be ignored. It's poor configuration to have information that
is usable but simply pretend that a demon is the sender of the email.
>INN does not use this option.
Yep. Poor configuration is a choice, not a requirement.
>Thus a broken submission address
>will result in a bounce to the user account of the news server.
Yep. Poorly configured. You have the information required to get the
bounce to the user, you have the means of setting that flag so it could
go there, but choose not to.
>The contents of From: or Sender: is completely ignored for this.
Yep. Shouldn't be, but is. Does the sendmail man page say why? No,
of course not, so your demand to refer to the sendmail man page for
the reason is a red herring. The problem is in inn, not sendmail.
>> Or is the difference between the moderator (recipient) and
>> sender (sender) too hard to keep track of?
>
>The communication between Usenet server and moderation address is not
>configurable by the user.
Of course not. Who said it had to be? Red herring.
>So it is a good thing that detailed error
>messages are sent to the people that can actually fix (or at least
>understand) the problem.
Exactly how will the news admin at site A, who probably ignores any
bounces from submitted articles anyway, FIX the bad address at site B,
where the moderator is supposed to be? It's unlikely that he can, so
it's useless to send the bounce to him.
(And I'll point out, if all the admins were paying all this attention to
these bounces and fixing the addresses, there wouldn't be 170 groups with
bouncing moderation submission addresses. Makes me think that they don't
really do all that fixing, at least in this area.)
Why do you think that a user posting to a moderated group wouldn't
UNDERSTAND the problem when he gets a bounce saying "invalid address"
or "no such user"? It's pretty clear from that message that the article
didn't get through and he shouldn't bother looking for it in the group
anytime soon. That would protect these precious users from the horrible
reality that they post and never see anything.
>On the other hand the information that an error occured is valuable to
>the user.
Yes. Very. But inn is configured so that information will be hidden
from the user. Valuable information. Trivial fix. It's called "-f".
Refer to the sendmail man page for further info. (Wow. It felt really
good to say that, but I bet you'll consider it rude. But it's the same
thing you said earlier and you wouldn't be rude, would you?)
>So I would appreciate it if bounces were automatically for-
>warded. Doing so manually is tedious and error-prone.
Why automatically forward them when they can go directly to the user
who generated the email in the first place? I would appreciate knowing
if a submission I make bounces, without having the local admin involved,
too.
>However, it is one thing to complain about the default behaviour of
>contemporary Usenet servers and a completely different thing to claim
>that the behaviour does not exist.
And yet another thing to admit that it is a poor configuration, which
is what I said. I did not say it does not exist, I said that it exists
only on poorly configured sites. You know the sender address, or what
the sender tells you his address is, you might as well use it. There is
no reason not to. Poor configuration is a choice, not a mandate.
>I mean, every-
>body here can verify this issue, even without delving into the details
>of manual pages. Just use your newsreader to post to one of the broken
>groups and see whether you get a bounce. Then repeat the exercise with
>your email client.
And all that would prove is whether the site I post from is well-configured
or not. We already know that inn/whatever could use the -f flag to sendmail,
we already know that the information that the message bounced is valuable
to the user -- even you admit this. What value is the exercise?
>What do you expect by being rude, ignorant and easily refutable?
What do you expect from being rude when you were so easily refuted? It's
Usenet. Don't jump down my throat for not reading a man page that has
nothing to do with the reason that important information is never passed
to the user, especially after it's obvious that I know the sendmail
options that inn has suggested be used.
Refute this, Alex. Inn knows the sender address, why does it throw that
information away just so that the overworked admin can ignore bounces
that he can do as little about as the user? If it's so easy to refute
me on this, why did you sidestep the issue? You explained how inn does
the recipient address, but not why it fails to use the sender information
it has.
Adam H. Kerman
>Alexander Bartolich <alexander...@gmx.at> wrote:
>>Mark Kramer wrote:
>>>Alexander Bartolich <alexander...@gmx.at> wrote:
>>>>Consulting the man page of sendmail to determine the behaviour of the
>>>>default installation is left as an exercise to the reader.
>>>You've now described the appearance of the DESTINATION address (the
>>>moderator), but not the ignorance of the sender.
>>What part of "Consulting the man page of sendmail is left as an
>>exercise to the reader" did you not understand?
>Sir, I consulted the man page for sendmail. It explains the '-oi' flag
>(ignore dots), and the '-oem' (mail errors) options, but does not explain
>why one would ignore a critical piece of information like "who is the
>real sender" when sending email to a moderation submission address. It
>speaks nothing about that. Maybe your man page is different.
>>Unless you specify option "-f", sendmail will determine the envelope
>>address based on the user ID it is running with.
>And you've yet to explain why the information about who the real sender
>is should be ignored. It's poor configuration to have information that
>is usable but simply pretend that a demon is the sender of the email.
Mark, A.B. is correct about this. The News daemon is the client WRT
sendmail, not the user, so the user's mailbox will not appear in Envelope
Sender. The error message the user might see should be passed back via
the News server, not via the Mail server.
So the question to ask is why INN doesn't do this by default.
Mark Kramer
>the News server, not via the Mail server.
And pray tell, how does the news server pass the error back to the user
when the news server explicitely requests mail delivery of failure notices?
The only way it has to do that is to set the sender to be the user instead
of itself. It cannot assume the user will be connected long enough for the
problem to be reported back to the news server and then to the user.
>So the question to ask is why INN doesn't do this by default.
Because it's misconfigured by design.
As I said from the start, the bounce goes to the user except if the news
server is poorly configured.
Adam H. Kerman
>Adam H. Kerman <a...@chinet.com> wrote:
>>The error message the user might see should be passed back via
>>the News server, not via the Mail server.
>And pray tell, how does the news server pass the error back to the user
>when the news server explicitely requests mail delivery of failure notices?
Uh, the user is logged?
>The only way it has to do that is to set the sender to be the user instead
>of itself. It cannot assume the user will be connected long enough for the
>problem to be reported back to the news server and then to the user.
That's what email is for.
>>So the question to ask is why INN doesn't do this by default.
>Because it's misconfigured by design.
No, Mark, it's not.
>As I said from the start, the bounce goes to the user except if the news
>server is poorly configured.
One assumes the News administrator might need to know, which is why it goes
to the mailbox associated with the News daemon.
Ray Banana
> In article <hcvtbt$s7r$1...@news.albasani.net>,
> Adam H. Kerman <a...@chinet.com> wrote:
>> The error message the user might see should be passed back via
>>the News server, not via the Mail server.
> And pray tell, how does the news server pass the error back to the user
> when the news server explicitely requests mail delivery of failure notices?
The server does *not* explicitly set the envelope-from, so it's the
sendmail default setting that is used.
BTW, the originator of the mail to the moderator is indeed the newsserver,
*not* the author of the article. The news client submits the article to
the newsserver (via the NNTP POST command, via UUCP + rnews, etc) and
the newsserver will convert it into an email and transmit it to a mail
server, based on the information in its active file and moderators.conf.
So it is correct to set the return path to the mailbox associated with
the newsserver. As SMTP is a store-and-forward protocol, delivery of emails
may be postponed for various reasons (temporary network problems on the way,
greylisting, etc), so it is not possible "return the error back to the user",
as you suggested. Bounces may arrive several hours or even days after the mail
was submitted. Also, a newsserver is not a mail server. This means that it
does not receive mails via SMTP. The non-delivery notifications are delivered
to a mail box associated with the newsserver, *not* to the newsserver.
Explicitly setting the return path of a mailed news article to the mail
address in the From: header, which may appear as the perfect solution to this
dilemma to an ingenuous mind, causes problems for domains with SPF records or
mail servers using sender callout verification. In addition, the news admin
of the originating newsserver is *not* the rightful owner of the mail address
used in the From: header, so it is not correct to use it in a conversation
with a remote mail server.
Furthermore, the news admin would have to trust the user supplied mail
address before using it as the MAIL FROM address in a SMTP conversation.
You may have noticed that many posters on Usenet deliberately munge their
From: headers or even use invalid or forged mail addresses, others use
mail addresses pointing to spam traps and the like, so indiscriminately
using such addresses for forwarding news articles to moderators' mailboxes
is bound to get the news server listed on various blacklists.
The only viable solution to the problem of vanishing submissions to
moderated newsgroups I can think of, would be to let the news client
decide wether the article should be posted or mailed. As far as I
know, the only news client that has this capability, is Turnpike.
> The only way it has to do that is to set the sender to be the user instead
> of itself. It cannot assume the user will be connected long enough for the
> problem to be reported back to the news server and then to the user.
>
>>So the question to ask is why INN doesn't do this by default.
>
> Because it's misconfigured by design.
>
> As I said from the start, the bounce goes to the user except if the news
> server is poorly configured.
And you are no doubt able to name the confiuration option that would allow
a news administrator to achieve this behaviour?
--
Too many ingredients in the soup, no room for a spoon
http://www.eternal-september.org
Adam H. Kerman
>>>The error message the user might see should be passed back via
>>>the News server, not via the Mail server.
>>And pray tell, how does the news server pass the error back to the user
>>when the news server explicitely requests mail delivery of failure notices?
>The server does *not* explicitly set the envelope-from, so it's the
>sendmail default setting that is used.
>BTW, the originator of the mail to the moderator is indeed the newsserver,
>*not* the author of the article. The news client submits the article to
>the newsserver (via the NNTP POST command, via UUCP + rnews, etc) and
>the newsserver will convert it into an email and transmit it to a mail
>server, based on the information in its active file and moderators.conf.
>So it is correct to set the return path to the mailbox associated with
>the newsserver. As SMTP is a store-and-forward protocol, delivery of
>emails may be postponed for various reasons (temporary network problems
>on the way, greylisting, etc), so it is not possible "return the error
>back to the user", as you suggested. Bounces may arrive several hours
>or even days after the mail was submitted. Also, a newsserver is not
>a mail server. This means that it does not receive mails via SMTP. The
>non-delivery notifications are delivered to a mail box associated with
>the newsserver, *not* to the newsserver.
I assume this is addressed to me, piggybacked on a followup to Mark. Yes,
you are correct of course.
Then let me improve my scenario: In an environment in which the user has
been authenticated AND has registered a mailbox known to the News
administrator for correspondence from him, there could be a process in which
that error message is automatically forwarded to the user upon receipt. And
you're right: It would be outside the scope of the News server.
Otherwise I agree with your other comments, snipped.
Ray Banana
> I assume this is addressed to me, piggybacked on a followup to Mark. Yes,
> you are correct of course.
It was a contribution to the discussion in this thread.
> Then let me improve my scenario: In an environment in which the user has
> been authenticated AND has registered a mailbox known to the News
> administrator for correspondence from him, there could be a process in which
> that error message is automatically forwarded to the user upon receipt. And
> you're right: It would be outside the scope of the News server.
In the scenario you describe above, it would IMO even be acceptable to
modify the mailer code to use the registered and verified mail address of
the poster as the return-path destination. This would, however, require
changes to the code, it's not configurable, contrary to Mark's previous
statements.
Steve Bonine
> I assume this is addressed to me, piggybacked on a followup to Mark. Yes,
> you are correct of course.
I rather think that the response is addressed to Mark. He began this
subthread on 3 November in <hcq45f$dsm$1...@pcls6.std.com> with "Then the
claim that this [Alexander's project to fix or remove broken moderated
newsgroups] is to protect those poor people who try to post and never
see any response is false. Thanks for clarifying that. They aren't left
hanging waiting for something to happen, they are told outright there is
a problem and they won't get help here." At that point I pointed out
that this wasn't true, and the response was "Then the server is
misconfigured." and "Wow. How'd you get to be a 'head moderator' when
you don't know how News works?"
> Then let me improve my scenario: In an environment in which the user has
> been authenticated AND has registered a mailbox known to the News
> administrator for correspondence from him, there could be a process in which
> that error message is automatically forwarded to the user upon receipt. And
> you're right: It would be outside the scope of the News server.
As I was doing some mindless work after reading this, I was struck by
the analogy between this issue and the issue of voting in Usenet. Here
we have a situation where someone _could_ write code that analyzed the
bounces returned to the news server and initiated email to the poster
informing them that the moderated newsgroup they were trying to use is
broken. The code would be non-trivial, and the effort to write it is
justified only perhaps as a training exercise for someone trying to hone
their skills. The population affected is anyone trying to post to a
broken moderated newsgroup from that server, which is a tiny number.
The incremental benefit is tiny, but the potential problems are not.
For Usenet voting, the coding is more difficult and the benefit is
similarly tiny. I would be surprised to see a dozen opportunities to
use a voting facility before the trickle of newsgroup proposals stops
completely. Yet we continue to see the bluster in news.groups about
voting. Give it up, guys . . . the benefit just isn't there to justify
the effort.
Theo Markettos
> Even the University of Cambridge doesn't carry the otiose NGP
> treehouse?
'Treehouse'?
Cambridge carries it, but we think somewhere upstream doesn't. In fact it
looks like somewhere upstream has been ignoring newgroup messages. So we
only get articles that happen to be crossposted.
> Btw, you won't find much discussion in the NGP treehouse even in
> Google Groups. The discussion mostly happens here, not there.
I've seen two non-crossposted posts in NGP so it looks like it's fixed, but
I'm waiting to hear for certain that it's sorted before posting a thread I
can't read. Will direct people here if they have difficulty.
Theo
Theo Markettos
> you.
>
> It's likely that this element of the Chiark Gestalt Entity has drifted
> into news.groups because one can as easily shit on two hierarchies as
> on one.
Nice to meet you, too ;-)
I'm not quite sure how reviving (or not) a group that I originally promoted
and put through the big-8 vote process 11 years ago can be said to be
'shitting' on the hierarchy, but you're entitled to your opinion.
You tend not to get very far saying "There is no conspiracy" to conspiracy
theorists...
Theo
"The Great One"
"Art Deco" <erfc...@usa.net> wrote in message news:071120090847396079%erfc...@usa.net...
> Alexander Bartolich <alexander...@gmx.at> wrote:
>
> >What part of "Consulting the man page of sendmail is left as an
> >exercise to the reader" did you not understand?
>
>
>
> --
> Official Art Deco Post
Tholen says "Hi" Karl !!
--
Your Pal,
John C.
Alexander Bartolich
> [...]
> Questions for Alexander:
>
> Did you try to consult Jim Riley, the acknowledged expert on "dead"
> moderated groups?
No. I was told that his departure was not free of friction.
> If you don't find suitable moderators for the "dead" groups with your
> current MVI posts, what do you propose to do next? Search further or
> propose rmgrouping?
The regular schedule is MVI, and then two weeks later RFD.
comp.ai.jair.* is an exception as it was started out of schedule.
> Why did you undertake this project after becoming a Bamby, not before?
I now feel obliged to fulfill the mission statement.
--
Adam H. Kerman
>Peter J Ross wrote:
>>Questions for Alexander:
>>Did you try to consult Jim Riley, the acknowledged expert on "dead"
>>moderated groups?
>No. I was told that his departure was not free of friction.
He was never a Bambi.
>>Why did you undertake this project after becoming a Bamby, not before?
>I now feel obliged to fulfill the mission statement.
Snarf.
Mark Kramer
Adam H. Kerman <a...@chinet.com> wrote:
>Mark Kramer <c28...@TheWorld.com> wrote:
>>Adam H. Kerman <a...@chinet.com> wrote:
>
>>>The error message the user might see should be passed back via
>>>the News server, not via the Mail server.
>
>>And pray tell, how does the news server pass the error back to the user
>>when the news server explicitely requests mail delivery of failure notices?
>
>Uh, the user is logged?
You mean "stoned"? Or you mean 'the message he sent is recorded in
a log'? Ok, his message is logged. Then "usenet@..." gets a DSN. Is
there some existing software in the news server that accepts DSN messages
for moderated group submissions and then uses this log information to
forward the error to the user? The answer you're looking for is "no".
The chain of evidence is broken when the news server sends the email as
itself instead of the real user and asks for emailed errors.
>>The only way it has to do that is to set the sender to be the user instead
>>of itself. It cannot assume the user will be connected long enough for the
>>problem to be reported back to the news server and then to the user.
>
>That's what email is for.
But the email doesn't GO to the user. It goes to "usenet@...", not
the user. Even if the email then gets fed into the news server so the
user could be told of the failure, he may have gone away by the time
the error appears. The news server can't report the error to the user
if the user isn't there anymore.
>>>So the question to ask is why INN doesn't do this by default.
>
>>Because it's misconfigured by design.
>
>No, Mark, it's not.
If the error goes someplace where the user can't see it, instead of the
user, then yes, it is misconfigured.
>>As I said from the start, the bounce goes to the user except if the news
>>server is poorly configured.
>
>One assumes the News administrator might need to know,
You may assume that, but why? The news admin of site X cannot do anything
about a bogus email address pointed to by the ISC moderation forwarders
that the user couldn't do just as well. You don't have to be a news admin
to say "hey, there's a problem with group X".
The USER has a vested interest in getting the message through. The USER
has a vested interest in knowing the message did not. The "news admin" is
an observer in this process and has no real reason to care. It's not his
system that failed, it's not his system to be fixed.
Mark Kramer
Ray Banana <ray...@banana.shacknet.nu> wrote:
>* Mark Kramer wrote:
>> In article <hcvtbt$s7r$1...@news.albasani.net>,
>> Adam H. Kerman <a...@chinet.com> wrote:
>>> The error message the user might see should be passed back via
>>>the News server, not via the Mail server.
>> And pray tell, how does the news server pass the error back to the user
>> when the news server explicitely requests mail delivery of failure notices?
>
>The server does *not* explicitly set the envelope-from, so it's the
>sendmail default setting that is used.
Sigh. By explicitely NOT setting the envelope-from, it is explicitely saying
"send DSN to me". I think we all know sendmail's default by now, and I think
we all know how TRIVIAL it is to get around it.
>BTW, the originator of the mail to the moderator is indeed the newsserver,
>*not* the author of the article.
Incorrect. The message is originated by the user, not the newsserver.
>The news client submits the article to
>the newsserver (via the NNTP POST command, via UUCP + rnews, etc) and
>the newsserver will convert it into an email and transmit it to a mail
>server, based on the information in its active file and moderators.conf.
Yep. Converted message. Originated by the user, whose email address is
known.
>Explicitly setting the return path of a mailed news article to the mail
>address in the From: header, which may appear as the perfect solution to this
>dilemma to an ingenuous mind, causes problems for domains with SPF records or
>mail servers using sender callout verification.
Today it might. There are, however, workarounds for SPF.
>In addition, the news admin
>of the originating newsserver is *not* the rightful owner of the mail address
>used in the From: header, so it is not correct to use it in a conversation
>with a remote mail server.
Horse hockey. By that argument, every mail forwarder must shut down
immediately. Every mailing list, every exploder, every place where an
incoming email is sent on to other server. News to mail gateways would
be gone.
>Furthermore, the news admin would have to trust the user supplied mail
>address before using it as the MAIL FROM address in a SMTP conversation.
He trusts it in posting to news.
>You may have noticed that many posters on Usenet deliberately munge their
>From: headers or even use invalid or forged mail addresses,
Yes, they do. And I've already pointed that out. If you use a
non-replyable From: address, you don't get the DSN from your submission,
JUST LIKE YOU DON'T GET REJECTION NOTICES FOR ONES THAT GET THROUGH
AND AREN'T ACCEPTED. We've already accepted the latter as "costs of
doing business". The former is no different.
> others use
>mail addresses pointing to spam traps and the like, so indiscriminately
>using such addresses for forwarding news articles to moderators' mailboxes
>is bound to get the news server listed on various blacklists.
If a user points his email at a "spam trap" and reports the news server
when a bounce comes back from a message HE INITIATED, well, life sucks
but stupid people do all kinds of stupid things. He's going to report
the moderators when they send email back to his address related to his
submission, too.
>> As I said from the start, the bounce goes to the user except if the news
>> server is poorly configured.
>
>And you are no doubt able to name the confiuration option that would allow
>a news administrator to achieve this behaviour?
Ummm, '-f'. Refer to the man page for sendmail for details.
Mark Kramer
This environment is, AFAIK, rare. The user need not have a "registered
mailbox", all the server has to do it look in the message it is
forwarding. It's called the From header and it is mandatory in news.
You could create all kinds of unworkable forwarding systems to take the
email DSN that arrives at the usenet@... address, but you need to rely on
the bounce being in a known format, and THEN you need to tie the bounce
to the original sender.
All to get around using a simple flag to sendmail that puts the problem
where it belongs.
Mark Kramer
Ray Banana <ray...@banana.shacknet.nu> wrote:
>the poster as the return-path destination. This would, however, require
>changes to the code, it's not configurable, contrary to Mark's previous
>statements.
I didn't say it was currently configurable. I said you know the
address and sendmail has the option of being told to use it. The
configuration that exists now is MISconfigured. That doesn't mean a
correct configuration is one keystroke away.
Mark Kramer
Ok.
>I was struck by
>the analogy between this issue and the issue of voting in Usenet. Here
>we have a situation where someone _could_ write code that analyzed the
>bounces returned to the news server and initiated email to the poster
>informing them that the moderated newsgroup they were trying to use is
>broken. The code would be non-trivial, and the effort to write it is
>justified only perhaps as a training exercise for someone trying to hone
>their skills.
There is no need to analyze bounces and initial email to the poster. This
is just another example of ... well, mindless ideas coming from mindless
work.
It appears that the code that is required is a small change to INN
or whatever to simply use the existing -f flag and point the bounce
messages to the person who ORIGINATED the message instead of an admin
at an intermediate site.
>The population affected is anyone trying to post to a
>broken moderated newsgroup from that server, which is a tiny number.
>The incremental benefit is tiny, but the potential problems are not.
Thanks for proving my point. The "benefit" of finding these "dead groups"
is tiny, since the alleged damage is tiny. If the "benefit" from fixing
the system so people aren't blindly posting to dead moderated groups is
tiny, then the damage cannot be anything but tiny. That makes the intifada
on dead moderated groups of "tiny" benefit, not worth the cost.
>For Usenet voting, the coding is more difficult and the benefit is
>similarly tiny.
That's because you cannot connect the lessened use of Usenet to the lack
of ownership felt by those users.
>I would be surprised to see a dozen opportunities to
>use a voting facility before the trickle of newsgroup proposals stops
>completely.
Then the job of the board is similarly moot.
Peter J Ross
Bartolich <alexander...@gmx.at> wrote:
> Peter J Ross wrote:
>> [...]
>> Questions for Alexander:
>>
>> Did you try to consult Jim Riley, the acknowledged expert on "dead"
>> moderated groups?
>
> No. I was told that his departure was not free of friction.
A lot of the friction was between Mr Riley and me, but it had nothing
to do with his expertise on the topic of dead moderated groups.
>> If you don't find suitable moderators for the "dead" groups with your
>> current MVI posts, what do you propose to do next? Search further or
>> propose rmgrouping?
>
> The regular schedule is MVI, and then two weeks later RFD.
> comp.ai.jair.* is an exception as it was started out of schedule.
I assume the MVI process continues during the RFD period.
>> Why did you undertake this project after becoming a Bamby, not before?
>
> I now feel obliged to fulfill the mission statement.
Well, somebody has to! :-)
Peter J Ross
<theom...@chiark.greenend.org.uk> wrote:
> Peter J Ross <p...@example.invalid> wrote:
>> Even the University of Cambridge doesn't carry the otiose NGP
>> treehouse?
>
> 'Treehouse'?
Yes, newbie. "Treehouse."
<...>
> Will direct people here if they have difficulty.
They'll find that we're even friendlier than the good people of
uk.net.news.*. Except when we encounter kooks, of course.
Ray Banana
>>The server does *not* explicitly set the envelope-from, so it's the
>>sendmail default setting that is used.
> Sigh. By explicitely NOT setting the envelope-from, it is explicitely saying
> "send DSN to me".
Now I wonder why you have to resort to semantic shenanigans at this early
stage of the discussion. "Not explicitly" is not identical with
"Explicitly not", in fact it's the opposite, so please stop twisting
my words.
> I think we all know sendmail's default by now, and I think
> we all know how TRIVIAL it is to get around it.
"We all"? TINW. You seem to think it's trivial, but you still haven't
provided a solution for a news admin to actually do it.
The -f option of sendmail requires an argument, so simply adding -f
to inn.conf's mta option will just get you a syntax error, not the
desired behaviour. You would have to put something like -f %s in there
and inn (or rather nnrpd, in this case) would have to replace the %s
part with a reasonable value. This requires changes to the program logic
and it requires some consideration as to what "reasonable" means in this
case. I wouldn't call this "trivial". Just imagine a news article
containing a From: header, a Reply-To: header and a Sender: header.
>>BTW, the originator of the mail to the moderator is indeed the newsserver,
>>*not* the author of the article.
> Incorrect. The message is originated by the user, not the newsserver.
This is true for the news article, not for the mail, as I tried to
explain in my previous post.
>>The news client submits the article to
>>the newsserver (via the NNTP POST command, via UUCP + rnews, etc) and
>>the newsserver will convert it into an email and transmit it to a mail
>>server, based on the information in its active file and moderators.conf.
> Yep. Converted message. Originated by the user, whose email address is
> known.
The email address is not known in the sense of "reliable" or
"trustworthy", as I tried to explain in my previous post.
>>Explicitly setting the return path of a mailed news article to the mail
>>address in the From: header, which may appear as the perfect solution to this
>>dilemma to an ingenuous mind, causes problems for domains with SPF records or
>>mail servers using sender callout verification.
> Horse hockey. By that argument, every mail forwarder must shut down
> immediately. Every mailing list, every exploder, every place where an
> incoming email is sent on to other server.
All mailing lists I know use there own return-path address and open mail
relays have long disappeared or are blacklisted.
>>Furthermore, the news admin would have to trust the user supplied mail
>>address before using it as the MAIL FROM address in a SMTP conversation.
> He trusts it in posting to news.
The From: header is meaningless in the propagation of news articles, so
there's no risk in accepting invalid From: headers.
>>You may have noticed that many posters on Usenet deliberately munge their
>>From: headers or even use invalid or forged mail addresses,
> Yes, they do. And I've already pointed that out. If you use a
> non-replyable From: address, you don't get the DSN from your submission,
> JUST LIKE YOU DON'T GET REJECTION NOTICES FOR ONES THAT GET THROUGH
> AND AREN'T ACCEPTED. We've already accepted the latter as "costs of
> doing business". The former is no different.
Obviously, I am looking at this from a newsserver operator's point of
view and, to me, there's a hell of a difference between getting bounces
for mails to a moderator originating from my server and getting my
server blacklisted for using forged return-paths.
>> others use
>>mail addresses pointing to spam traps and the like, so indiscriminately
>>using such addresses for forwarding news articles to moderators' mailboxes
>>is bound to get the news server listed on various blacklists.
> If a user points his email at a "spam trap" and reports the news server
> when a bounce comes back from a message HE INITIATED, well, life sucks
> but stupid people do all kinds of stupid things.
But I will not let them do stupid things to my server. Get the idea?
Adam H. Kerman
>Thus spake c28...@TheWorld.com (Mark Kramer)
>>>The server does *not* explicitly set the envelope-from, so it's the
>>>sendmail default setting that is used.
>>Sigh. By explicitely NOT setting the envelope-from, it is explicitely saying
>>"send DSN to me".
>Now I wonder why you have to resort to semantic shenanigans at this early
>stage of the discussion. . . .
Hehehehehe. Welcome to news.groups.
Mark Kramer
Ray Banana <ray...@banana.shacknet.nu> wrote:
>Thus spake c28...@TheWorld.com (Mark Kramer)
>
>>>The server does *not* explicitly set the envelope-from, so it's the
>>>sendmail default setting that is used.
>
>> Sigh. By explicitely NOT setting the envelope-from, it is explicitely saying
>> "send DSN to me".
>
>Now I wonder why you have to resort to semantic shenanigans at this early
>stage of the discussion. "Not explicitly" is not identical with
>"Explicitly not", in fact it's the opposite, so please stop twisting
>my words.
The server does not set the envelope-from, explicitely or otherwise. By
choosing that option, the person who configured it has explicitely chosen
to have the DSN sent to the usenet@ address instead of the user.
The only semantic game being played is by those who want to complain that
'explicitely not' and 'not explicitely' are different. We know what does
and does not do what and what the explicit effect is.
>> I think we all know sendmail's default by now, and I think
>> we all know how TRIVIAL it is to get around it.
>
>"We all"? TINW.
If you think it is complicated to use the -f flag for sendmail, I'd suspect
your abilities as an admin. It was one of the first things I learned about
when writing my first news to mail gateway.
>You seem to think it's trivial, but you still haven't
>provided a solution for a news admin to actually do it.
I don't run INN so I can't tell you specifically how to get INN to do
this. That doesn't mean it's hard, just that the specifics aren't known.
>The -f option of sendmail requires an argument, so simply adding -f
>to inn.conf's mta option will just get you a syntax error, not the
>desired behaviour.
For someone who accused others of playing semantic games, you sure seem
happy to do so when it benefits you. Of course the argument -f takes a
parameter. We all know that.
>You would have to put something like -f %s in there
>and inn (or rather nnrpd, in this case) would have to replace the %s
>part with a reasonable value.
Yep. That sounds like a correct analysis.
>This requires changes to the program logic
>and it requires some consideration as to what "reasonable" means in this
>case.
It may require changes, I don't know. I do know that INN has the
information, and that the "reasonable" entry is pretty obvious. If you
want the DSN to have any chance of going to the originator of the message,
you use the address of the orginator.
>I wouldn't call this "trivial". Just imagine a news article
>containing a From: header, a Reply-To: header and a Sender: header.
Ok. Which is the address of the originator, as defined in RFC1036? From
unless Sender.
>> Incorrect. The message is originated by the user, not the newsserver.
>
>This is true for the news article, not for the mail, as I tried to
>explain in my previous post.
It is one message, CONVERTED (your word) from news to mail. As I already
pointed out.
>The email address is not known in the sense of "reliable" or
>"trustworthy", as I tried to explain in my previous post.
And as I already explained, it is as trustable as anything you have. If
the user munges his address, tough shit for the user. If he doesn't he
should benefit from his honesty and be told the message he posted didn't
get to the moderator.
Ray Banana
>>stage of the discussion. "Not explicitly" is not identical with
>>"Explicitly not", in fact it's the opposite, so please stop twisting
>>my words.
> The server does not set the envelope-from, explicitely or otherwise.
Please be more precise in your wording. By "the server", are you
referring to the mail (SMTP) server or the news (NNTP) server?
The news server does not set the envelope, but the MTA does.
By default (i.e. if not *explicitly* instructed otherwise), it uses
the user id that owns the process submitting the mail
and adds domain information from its configuration.
> By choosing that option, the person who configured it has explicitely chosen
> to have the DSN sent to the usenet@ address instead of the user.
You are wrong about the usenet@ part. See explanation above.
[ad-hominem drivel snipped]
>>You seem to think it's trivial, but you still haven't
>>provided a solution for a news admin to actually do it.
> I don't run INN so I can't tell you specifically how to get INN to do
> this. That doesn't mean it's hard, just that the specifics aren't known.
It simply means that you are not in a position to judge the complexity
of such a change. Thanks for stating the obvious.
>>The -f option of sendmail requires an argument, so simply adding -f
>>to inn.conf's mta option will just get you a syntax error, not the
>>desired behaviour.
> For someone who accused others of playing semantic games, you sure seem
> happy to do so when it benefits you. Of course the argument -f takes a
> parameter. We all know that.
TINW. And programs have parameters and options take arguments. You,
however, lack both.
>>You would have to put something like -f %s in there
>>and inn (or rather nnrpd, in this case) would have to replace the %s
>>part with a reasonable value.
> Yep. That sounds like a correct analysis.
>>This requires changes to the program logic
>>and it requires some consideration as to what "reasonable" means in this
>>case.
> It may require changes, I don't know. I do know that INN has the
> information,
No, it doesn't. It could extract some information from the posted
article, based on some assumptions made by the developer.
> and that the "reasonable" entry is pretty obvious. If you
> want the DSN to have any chance of going to the originator of the message,
> you use the address of the orginator.
>>I wouldn't call this "trivial". Just imagine a news article
>>containing a From: header, a Reply-To: header and a Sender: header.
> Ok. Which is the address of the originator, as defined in RFC1036? From
> unless Sender.
RFC1036 reflects the state of Usenet at a time before the Fall from
Grace, when hords of unkempt AOLers and Compuservers were allowed
to enter Paradise and turn it into an apocalyptic Muppet show.
USEFOR[1] explicitly(sic!) allows the use of the .invalid TLD in the
From: header and thus renders it useless for determining the originator
of a posted article.
But RFC 1036 also makes some remarks about transferring news via mail,
that may also be relevant in the context of moderated newsgroups, too:
4.2. Transfer by Mail
[...]
One problem with this method is that it may not be possible to
convince the mail system that the "From" line of the message is
valid, since the mail message was generated by a program on a
system different from the source of the news message. Another
problem is that error messages caused by the mail transmission
would be sent to the originator of the news message, who has no
control over news transmission between two cooperating hosts
and does not know whom to contact. Transmission error messages
should be directed to a responsible contact person on the
sending machine.
And that's exactly how it is done today.
BTW, I just did a bit of research on the problem of bouncing submissions
to moderated groups and these are the figures for the past 30 days [3]:
Total number of postings: 181,399
Postings to moderated groups: 2,768
bounced postings to moderators: 4
From this point of view, I don't really think bouncing submissions
to moderators are a problem serious enough to justify the effort
of implementing a software solution for it.
[1] http://www.ietf.org/rfc/rfc1036.txt
[2] http://tools.ietf.org/html/draft-ietf-usefor-usepro-14
[3] Based on the logs of news.eternal-september.org for the Big 8, alt.*
and reginal hierarchies like uk.*, fr.*, de.*, it.*, etc.
Kathy Morgan
> TINW. And programs have parameters and options take arguments. You,
> however, lack both.
I think that probably belongs in a .sig file. :-)
> BTW, I just did a bit of research on the problem of bouncing submissions
> to moderated groups and these are the figures for the past 30 days [3]:
>
> Total number of postings: 181,399
> Postings to moderated groups: 2,768
> bounced postings to moderators: 4
Thanks for the interesting stats and the laugh.
--
Kathyb
Harald Maedl
> In the Board's infinite wisdom, it is pretending to try to fill moderator
> vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
> Why, It's Obvious! tm
THE Board's infinite wisdom was coming by meditation in the empty
deserts of these groups. And suddenly a voice was speaking: "Take this
new broom! It sweeps so clean!...
Ray Banana
Now I can see the full extent of this conspiracy. Alexander paves the
way for Harald Maedl to become the supermoderator of 170 Big 8 groups.
Resistance is futile, you will be schnuerpelized ...
Harald Maedl
> Thus spake Harald Maedl:
>> Adam H. Kerman schrieb:
>>> In the Board's infinite wisdom...
>>> [quote snipping wizardry]
>>> ... It's Obvious! tm
>> THE Board's infinite wisdom was coming by meditation in the empty
>> deserts of these groups. And suddenly a voice was speaking: "Take this
>> new broom! It sweeps so clean!...
> Now I can see the full extent of this conspiracy. Alexander paves the
> way for Harald Maedl to become the supermoderator of 170 Big 8 groups.
> Resistance is futile, you will be schnuerpelized ...
<bot on> Schnuerpel gives Ray a big hug from Harry</>
Ic, the high priest of "eternal september" is my truest fan. But plzzz,
nobody here is ready for the only truth. BTW, it's not a problem to
moderate 170 stone-dead groups. Put on a grave light once a year, that's
all. Pls donate now!
Harry
Harald Maedl
> Adam H. Kerman wrote:
>> In the Board's infinite wisdom, it is pretending to try to fill moderator
>> vacancies in 8 newsgroups. Looks like bulk rmgroup messages are coming.
>> Why, It's Obvious!
> There are 170 moderated groups without traffic in the last 12 months.
> The plan is to start 8 proceedings every four weeks, for about one and
> a half years straight.
The big question is, why they are dead. Normally a moderator would not
leave his baby without a reason.
First the users are leaving a group and then the frustrated moderators.
In some groups one of the reasons could be, that the status of moderated
groups are handled in a different way by the admins
I've found i.e in the biz hierarchy (by checking only three IPSs) round
about 19 groups listet with different status (moderated/unmoderated) and
2 in comp*, totally the half of 42! OMG:
+ biz.caucus
+ biz.clarinet.sample
+ biz.clarinet.web.sample
+ biz.comp.accounting
+ biz.ecommerze
+ biz.general
+ biz.healthcare
+ biz.marketplace.computers.mac
+ biz.marketplace.computers.other
+ biz.marketplace.computers.workstation
+ biz.marketplace.discussion
+ biz.marketplace.international
+ biz.marketplace.investors
+ biz.marketplace.non-computer
+ biz.marketplace.real-estate
+ biz.marketplace.services.computers
+ biz.marketplace.services.discussion
+ biz.marketplace.web-design
+ biz.stolen
+ comp.archives.ms-windows.discuss
+ comp.binaries.cbm
Just now we have had the discussion in d.a.n.g about the problems with
different status for such groups. User, who are posting via such ISPs,
who haven't changed the status to "moderated", will be very lonesome.
Not listed groups like
+ rec.toys.transformers.moderated
+ rec.tracel.resorts.all-inclusive
+ rec.arts.erotica
+ rec.arts.movies.erotica
+ talk.current.events
are not problem in this context.
>> [...]
>> I'm not sure I care whether this is abuse of process or incompetence,
>> I do expect the usual suspects to be along shortly. Kathy will assure me
>> there's no abuse of process, without explaining why. Steve will be all
>> indignant. Thomas will explain that if I'm against it, clearly the Board
>> is on the right track.
> I see you enjoy the show. That's what really matters most.
One suggestion could be:
+ first have a try with auto-approve for a certain time. I'm highly
sceptical to find enough engaged moderators.
Probably the approving could be done by scripting directly on
moderators.isc.org. If not, it will be a lot work to change the
submission addresses. Regarding the Banana's high priest plan it would
be useful to use a common account like *.@usenet-moderation-net *g*
+ try to get the same status (moderated) for the most of important ISPs
(very hard work)
+ if no further interest to the group --> rmgroup
The question is: Would be this procedure worth the effort?
Harry
Harald Maedl
> In some groups one of the reasons could be, that the status of moderated
> groups are handled in a different way by the admins
> I've found i.e in the biz hierarchy (by checking only three IPSs) round
> about 19 groups listet with different status (moderated/unmoderated) and
> 2 in comp*, totally the half of 42! OMG:
> + biz.*
Sorry, I was just in a parallel world, where the Big 9 rulez!
Ray Banana
> Sorry, I was just in a parallel world, where the Big 9 rulez!
and domains have no dots ;-)
Alexander Bartolich
> [...]
> One suggestion could be:
> + first have a try with auto-approve for a certain time.
What should this be good for?
Write-only users do not care whether their messages appear in the
target group. And for users that read the group it is enough to
post an MVI announcement.
--