Re: Decision: Let's get draft-allbery-usefor-usepro-00 right and publish it as draft-ietf-usefor-usepro-07

[Frank Ellermann <[e-mail]>]

Russ Allbery wrote:

>> modifying an original M-ID is utter dubious, and it could cause
>> complete confusion if a later (not the first) moderator starts to
>> modify an already approved M-ID.

> 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.

> 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.  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.

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

> The only interoperability problem that I can think of is if one of the
> earlier moderators or the poster made a digital signature that included
> the message ID, in which case changing it would invalidate the signature.

Yes, that's a more elaborated version of "note approved Message-IDs".

>> E.g. "drop" isn't a valid implementation of "reject".

> 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.  You can't just drop
legit submissions without informing the author.  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.

For a "spam" reject you could use the Return-Path, informing the server
admin that one of their users is a spammer or zombie.  They could then
decide to close this account.  If even the Return-Path isn't plausible
(no address you've heard of before, no SPF PASS, the works) you're forced
to drop it, but you'll get false positives with this approach.

> determining when this should be done versus dropping spam silently is
> a judgement call not amenable to protocol language.  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.

> 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.

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.

Frank