Moderation issues (was: Decision: Let's get draft-allbery-usefor-usepro-00 right and publish it as draft-ietf-usefor-usepro-07)

[Russ Allbery <[e-mail]>]

Frank Ellermann <[e-mail]> writes:
> Russ Allbery wrote:

>> How?  Could you provide some specific examples of what interoperability
>> problems you believe could result?

> The first moderator could note approved Message-IDs and cancel anything
> else appearing in his group.

I suppose.  It would be rather pointless to do so at this point, given how
few people support cancels, and those I know of who are doing this use
PGPMoose instead (thus turning this into the digital signature case).

This is a case of cross-posting between moderated groups, which I agree is
kind of iffy already.  In practice, one pretty much always works this out
via special agreement between the moderators.  We have a system described
in our document that sort of works, but it still requires prior
arrangement between the moderators to devise a way of noting that the
message was already approved.  Said prior arrangement could deal with
issues such as this as well.

This area is not going to get any better until there's a strong
authentication system for moderator approvals.  Until then, anything we
write about the mechanics of this is written on quicksand; in practice,
there are a bunch of ad hoc conventions that are not suitable for
standardization.

Again, I'll warn that trying to explore this area is going to go way off
into the weeds for this working group.  Do you want the moderator to
retain the message ID if they've made substantial changes to the post?
What if the moderator decides to remove the newsgroup to which the post
was previously approved?  There's nothing preventing them from doing that,
and there are some moderated newsgroups where the moderation policy
permits that (as much as I think it's a horrible idea for social reasons).
What if the two moderators decide to multipost the message instead of
crosspost it?

Documenting how moderation is done on Netnews and getting consensus around
recommendations is a document of its own and probably at least a year of
work for an active IETF working group.  It took longer than that the last
time, and it's only gotten more complicated.

>> cancels of a message in a moderated group have to be approved by the
>> moderator anyway,

> s/anyway/ideally/.  Cancels can be approved by the author as well, they
> don't need to be moderated.

Hm.  Well, I suppose that's a USEAGE question.  I'd consider it
questionable to self-approve *any* message to a moderated newsgroup,
including a cancel, but I can see the argument the other way.  It depends
on how one views the nature of a moderated newsgroup.  Certainly, on a
server that enforces PGPMoose authentication, such a cancel would be
ignored, but then cancels are generally ignored anyway.  (In practice, I'd
just explain to the poster of the cancel that no one honors cancels any
more anyway and they're just creating controversy for themselves without
accomplishing anything useful.)

> Some cases I have in mind:

> 1 - author submits article, moderator approves it, author decides to
>     withdraw his contribution.  The author can send a cancel to the
>     moderator (for approval by the moderator), additionally (s)he can
>     send a self-approved (author's address) cancel.  For cancels the
>     most important issue is speed.

True, to what degree they're useful.  It's really not feasible to withdraw
a message once it's been posted, but ignoring that, I do see your point.

> 2 - impostor submits article, moderator approves it, alleged author
>     cancels the fake.  Somebody abused the From:-address and/or
>     Message-ID, therefore cancel it.

Better, here, to notify the moderator since you also want to prevent the
imposter from doing it again (and that's more important than chasing the
first message with a cancel).

>> It *has* to be.  My moderated groups get hundreds of messages a day for
>> which drop is the *only* valid implementation of reject.  Those
>> messages are spam with either no contact information at all or forged
>> contact information.  Any attempt on my part to do anything but drop
>> those messages would leave me sending unsolicited e-mail or other
>> communication to someone whose only involvement with the original
>> message was to have their contact information forged by a spammer.

> That procedure has to be outlined in the standard.

Apart from simply disagreeing in general, I don't believe this is feasible
for a standards-track protocol specification.

> You can't just drop legit submissions without informing the author.

Of course I can.  It happens all the time and has for as long as there
have been moderated newsgroups.

You don't *want* moderators to drop legit submissions without informing
the author, but that's a different statement.  I understand why you want
this, and in *most* cases I would agree.  However, in practice, one simply
cannot do this reliably without missing some legitimate submissions unless
one is spamming addresses forged by spammers, since no spam detection
method (including the human eye) is 100% reliable.

> It has to be clear what the Return-Path is (= an address at the original
> server), and that you'd use the From (or Reply-To) for a "normal"
> reject.

The envelope sender (assuming that's what you mean by Return-Path) is
precisely as reliable as the From header, namely not at all.  Spammers are
not that stupid and forging the envelope sender is trivial.

>> I would be very happy to see a document that describes those judgement
>> calls, and indeed such a document was already written, as an I-D, a
>> little over ten years ago.  You can find it on the web as "NetNews
>> Moderator's Handbook."

> http://www.eff.org/Net_culture/Net_info/Technical/usenet_moderator_handbook.draft

> Ten years might be a bit old for issues related to spam.

It certainly is.  It's too old for all sorts of things, although that
document addresses many of the other judgement calls that moderators deal
with, but it would desperately need an update.

>> If we try to get into that material in the protocol specification,
>> we're going to end up wandering *way* off into the weeds.

> You could write "the procedure to do X or decide Y is not specified
> here", but we need an overall model of what a moderated newsgroup is.

I believe my current draft provides an accurate overall model of what a
moderated newsgroup is at the Netnews protocol level, namely moderators
*can* do anything they wish, but best practice says to make minimum
modifications to approved posts.

However, I come to this with a fairly intensive knowledge of how
moderation works.  Do you have a specific wording change in mind that
would make the model better for people who don't have that background,
based on what we've discussed?

> So far I thought it's an NG where "something" can decide to reject or
> accept submitted articles.  Apparently your model includes content
> modification and silently dropping articles.  That's very different.

Then this discussion has already served an educational purpose.  That's a
very good thing!  I think that many people who have not moderated a
newsgroup don't understand how Netnews moderation works at all, or don't
understand the huge variety of actions different moderators in different
groups take with posts.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>