Subject: Re: New USEPRO path-identity text (Hello, Chair?)

From: John Stanley <[email-masked]>
Date: Tue, 26 Jul 2005 08:11:25 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Thank you for confirming that I had not said what you had alleged I had 
>said.

What I wrote was sloppy but not fatal, Charles. I left out "that is
inserted by an injecting agent", and I assumed that I had quoted the text
often enough that it would not confuse you. I'm sorry you got confused.  
(No, I know you aren't confused, you know exactly what text is being
discussed and what the problem is. You are just trying every trick you can
think of to avoid discussing the issue.)

>No, if you have a problem, please describe it in terms of what is actually
>being proposed.

I have, Charles, multiple times. I just quoted the problem text VERBATIM,
AGAIN, and was explicit as to what the problem was, in the email you just
responded to, and you have conveniently ignored that. Instead, you
demanded that I tell you the problem text and what the problem is. Stop
playing games.

We already demand that both "news" and "usenet" be mailable addresses,
even though I still have seen no justification for having two. Either
justify a mandate (of any kind, much less RFC2119) requiring a THIRD
mailable address for a news host or remove it. 

Will one of the chairs please step in here? There is a valid issue on the
table (overriding an explicit statement in an existing standard with an
unjustifiable RFC2119 mandate) that has an apparent consensus to remove
the mandate, and the editor is refusing to remove it. The problem text has
been quoted verbatim, and replacement text has been suggested. He's not
even open to a discussion of the problem, it seems, preferring to play
this "ask me again, again" game. It's an abuse of his position as draft
editor, again. I'm sure it pleases you that he does this, but it's time
for it to end.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Jul 2005 11:56:41 GMT

>mailable address for a news host or remove it.

The co-existence of "news" and "usenet" is a historical accident, which it
is too late to fix.

My proposed requirements for "news" and "usenet" are less onerous than for
2142. Do you have a problem with that?

My proposal regarding "abuse" is less onerous than for 2142 insofar as it
is not required for relaying agents and it is not required if there is a
suitable parameter in Injection-Info, and it is not required for private
servers. Do you have a problem with that?

My use of RFC 2119 language is consistent with its use to describe the
"postmaster" address in RFC 2821 (and note that what is there defined is
slightly different from RFC 2142). Do you have a problem with RFC 2821?

My proposal regarding "abuse" is more onerous that for 2142 insofar as it
requires you either to provide an MX record for the <path-identity> used
for injection or else to choose a <path-identity> which is already your
"top level domain". And it does so with "MUST" wording. Evidently you do
have a problem with that.

The reason it is so proposed is that it provides a clear and unambiguous
route to find a working "abuse" address starting from information
contained in the article's header fields.

RFC 2142 fails to provide such a route, as evidenced by the fact that when
I gave a concrete example that could be derived from the article's header
fields,	 different members of this WG arrived at different conclusions as to
what the correct "abuse" address should be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Richard Clayton <[email-masked]>
Date: Wed, 27 Jul 2005 17:04:20 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>2142. Do you have a problem with that?

I'm reading usepro-4 here, which is the one on the IETF site, and this
whole area is just getting baroque :(

The basic idea is that someone stands up and takes responsibility for
articles that are injected into the system. In principle, they can stop
further articles by cancelling an account, barring a user, manually
checking future posts or whatever.

The rest of the planet needs to know who that person is and needs to be
able to send email to them.  Traditionally, one used news@ or usenet@
but these days abuse@ will reach a specialist team rather than the
administrators, so that's what most people use.

There's also a need to stop people moaning, and so we let them specify
exciting alternatives   stopnow@ or whatever, not that anyone is likely
to notice and to use them -- but it stops people moaning that they just
cannot cope with everything coming to abuse@

For this purpose we have the Injection-Info: header field.  This field
is a MUST requirement according to 2.3 (though mysteriously in 3.1 it is
described as optional and in USEFOR it is said to be optional).

Anyway, we need to have a set of rules for what it says in this header
field and quite clearly (from above) it needs to be an identity from
which one can trivially obtain a domain, prepend abuse@, news@ or
usenet@ and have email delivered to the correct place.

I don't see that we have to have a whole pile of things about FQDNs,
domains the concept of "mailable" (which only involves two of the three
destination addresses anyway) or any mixing up of the notion of UUCP
identities with this part of the format.

We just need to set out the rules for the complainer and then say that
the Injecting agent must generate header fields to ensure that these
rules will work.

- -=-=-=-=-

At present, #2.3 confuses the notion of where to complain to with where
the article has come from, viz: the Path: header field.

I can see NO LINKAGE between these two concepts (except in so far as in
many cases they may be the same).  Is the idea that you can match the
entries in the Path with the Injection-Info: material ?  What does this
gain you ? 

!Path: demon!highwayman.com!richard
!Injection-Info: demon; mail-complaints-to=[email-masked]; 12345678

What this means is that if you don't like what I wrote then you complain
to [email-masked] (the beeb happen to use Demon's news server).

I don't any huge advantage to (the wrapped)

!Path: demon!highwayman.com!richard
!Injection-Info: news.demon.co.uk;
                 mail-complaints-to=[email-masked]; 12345678

it means that people may write to [email-masked] (which would
be coped with, but is a nuisance)

In fact, what is the point of this first path field when there's a mail-
complaints-to clause ?  I can see it makes sense for

!Injection-Info: news.demon.co.uk; 12345678

where one writes to [email-masked] or whatever...

So I come back to the point made above -- viz: that what's needed is the
rules for the complainer to follow, then a statement that says that this
MUST yield a valid email address.  Then drop all the rest of the guff.

>servers. Do you have a problem with that?

I have a problem with understanding which part of the Injection-Info
header field is being talked about, and I have a big problem
understanding why if the injection agent doesn't offer a public service
they should be excused offering abuse@ ...  suppose beeb.net was a
private club; why should you not expect [email-masked] to work when
their article emerged onto the public part of Usenet ?

>slightly different from RFC 2142). Do you have a problem with RFC 2821?

the world is full of people who have problems with the postmaster@
requirements of 2821. That's a can of worms that is best left alone here

>have a problem with that.

yes, and so do I

write the rules for the complainant, leave how that is made to work
alone; it's far too complex to describe the general case :(

>contained in the article's header fields.

but that's exactly what it currently does NOT do -- you're left to
deduce it :(

>what the correct "abuse" address should be.

and it was agreed that in all cases the complaint would reach someone
who knew what to do with it.  This is not an area that needs fixing.

To reiterate, since I fear people skip-read these long messages.

a) Turn the whole thing around and provide a clear set of rules of how
to construct an email address to which to send a complaint

b) say that the Injection-Info header field must be built in such a way
as to have these rules work

c) say nothing more that that!

d) pin down whether Injection-Info is or is not mandatory and fix the
text accordingly

e) break the unnecessary connection between the data in the Injection-
Info header field AND that in the Path header field _AND_ (since it is a
completely different thing) the Xref header field.  Once you do that all
sorts of SHOULDs disappear, which is a Good Thing :)  Then we can look
at whether all these complex rules about MX records are needed for the
Xref and Path header field info (hint: "no")

As ever, I can write text for this if it's essential to make people
understand it -- but it mitigates against consistency of style :(

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 13:43:02 -0400

On Wed July 27 2005 12:04, Richard Clayton wrote:

> able to send email to them.

It is desirable to be able to communicate.  Whether the form of communication
"needs to be" via email is debatable.  For "postmaster" and a mail server,
that is reasonable because after all it *is* a mail server which is obviously
capable of handling mail.  For Usenet, that does not necessarily apply.
We can try to mandate or recommend that each news server associated with
responsibility for injection also accept mail and could further mandate or
recommend specific mail protocols, addressing formats, and/or mailboxes.
That may adversely affect sites handling news via UUCP, Fidonet, etc.

> described as optional and in USEFOR it is said to be optional).

There was also a Complaints-To proposal, which was never as mired in problems
as Injection-Info.  IIRC one person objected that some sites which have no
email capability but which do have HTTP service might actually supply an
HTTP URI for complainants to use.  Quelle horreur!  Another case of a
personal fetish overriding calm consideration of technical issues, resulting
in a huge waste of time and effort.

> field

Meaning Path?  Or Injection-Info?  Or something else?

> and quite clearly (from above) it needs to be an identity from 
> usenet@

Injection info provides for an address-list (which is email- and Internet-
specific), though that has severe syntax problems with the proposed use
of MIME-like parameters.  Complaints-To could have an address-list w/o
syntax problems, or could have a bracketed URI list (permitting an
ordered hierarchy of contact mechanisms), the latter fully encompassing
the capabilities of a mere address-list and providing alternate mechanisms.

> and have email delivered to the correct place.

That presumes that email is available to the complainer and the responsible
party.

> the Injecting agent must generate header fields to ensure that these

Somewhere the concept of voluntary standards passed over somebody's head,
and was replaced by a bizarre ESP-like guess-the-mechanism-and-mailbox
concept, replete with "here's an example; guess the mailbox" games.
There's no guarantee -- even if we write "POSITIVELY, ABSOLUTELY, UNDER
PAIN OF CHASTISEMENT FROM CHARLES, MUST" w.r.t. email support for complaints
that a site will conform.  Far simpler and more sensible to provide a
standardized mechanism which can be used by those who wish to take
responsibility for injection (those who do not will not regardless of what
is written) to do so in accordance with some set of mechanisms that provide
for negotiation of mutually usable communications media between complainer
and responsible party.  Complaints-To with a bracketed URI list would do
just that. Those who wish can still engage in guess-the-mechanism games
(and we can still write SHOULD or even MUST).

[...]
> MUST yield a valid email address.  Then drop all the rest of the guff.

I'd go further and permit mechanisms in addition to/alternate to email.
 
> to construct an email address to which to send a complaint

Or alternate mechanisms.
 
> as to have these rules work

Or whatever field is designed to provide the functionality.  Best to
keep separate functionality in separate fields so that e.g. a complainer
doesn't have to wade through difficult syntax for unrelated cruft in
order to file a complaint.
  
> c) say nothing more that that!

Except for necessary registrations and corresponding IANA considerations,
any security issues (obviously, publishing contact information gives
potential attackers a target for DoS or other attacks), etc.
 
> d) pin down whether Injection-Info is or is not mandatory and fix the

There doesn't seem to be anything there that warrants making it mandatory.
Much is redundant with what is in Path and/or other fields (and easier to
extract from Path and/or other fields).
 
> Xref and Path header field info (hint: "no")

Sounds good to me.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 27 Jul 2005 19:00:52 +0100

In message <[email-masked]>, Bruce Lilly
<[email-masked]> writes

>"needs to be" via email is debatable. 

today, it is -- complaining in the newsgroup is generally frowned on,
and IRC doesn't generally cut it :(

> For "postmaster" and a mail server,

this is the Real World (TM)  everyone but everyone has email

don't forget that the abuse@ team also deal with complaints about UDP
packets and no-one seems to have any real long-term difficulty working
out where to complain about those ! 

>That may adversely affect sites handling news via UUCP, Fidonet, etc.

frankly, I doubt it.  If you could name such a site (which has a Fidonet
feed say, but no globally accessible email address), then your assertion
might carry more weight :(

>IIRC one person objected that some sites which have no
>HTTP URI for complainants to use.  Quelle horreur!  

I've got no problem with complaints via HTTP, but the community
currently objects if you cannot complain by email as well (or instead)

>Meaning Path?  Or Injection-Info?  Or something else?

whatever the complaints directing header field is (I was still being
addressing the general principle of what we actually need to do at that
point), I'll live with Injection-Info for the purpose.

>I'd go further and permit mechanisms in addition to/alternate to email.

the main effect of this would be to encourage reporting via web forms

I can live with that, but I don't think it would be widely seen as being
realistic in today's climate

>extract from Path and/or other fields).

it's hard to extract from the path if we continue to permit

        !demon!highwayman.com!richard

because the correct place to complain is [email-masked], and that's not
especially easy to write rules as to how to do the extraction :)

Hence there is significant value in a new field (and making it
mandatory) and it sweeps away the rather-hard-to-machine-parse existing
set of oddments used for the purpose

- -- 
richard                                              Richard Clayton

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 15:38:14 -0400

> and IRC doesn't generally cut it :(

Those aren't the only alternatives; there's ftp, HTTP, the telephone,...
 
> this is the Real World (TM)  everyone but everyone has email

Not all email systems are reachable via an Internet-style address with
a local-part consisting solely of "abuse".  There's e.g. UUCP, X.400, ...

> packets

UDP packets are unlikely to emanate from a UUCP site with no Internet
connectivity.

> the main effect of this would be to encourage reporting via web forms

And you have determined that from? Gazing into a crystal ball?
Looking at tea leaves?  Rummaging through entrails?
 
> realistic in today's climate

In some cases HTTP or other mechanisms are more reliable than email for
reporting abuse.  A common case is reporting a message containing a "virus";
that might not pass through some mail filters, whereas it can be copied
and pasted into a web form or sent via ftp, etc.  Likewise for some
malformed messages.
 
> especially easy to write rules as to how to do the extraction :)

That's not relevant to most of what's in Injection-Info; the posting
host can be obtained from Path, sender can be obtained from originator
header fields or placed in the "tail-entry".  Likewise posting account
information could be encoded into the tail-entry.

For complaint information,
  Complaints-To: <mailto:abuse%40beeb.net>
would work fine.  Easy to parse, almost trivial to automate/assist
complaint submission.  Uses mailto URIs which are widely supported.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Jul 2005 15:24:10 GMT

>>2142. Do you have a problem with that?

My understanding has always been that you used "news"/"usenet" for
technical issues ("Do you realize that articles are looping through your
site?", or "do you realize that you have group X wrongly configured as
moderated (or not)?". Generally, those addresses go to the one news-clueful
person in the organization, and it is counterproductive to smother such
people in spam complaints. However, there is some need to contact those
tech people at both relaying and injecting agents.

OTOH, you use "abuse" for complaints of spam, phishing, etc, and that
address typically goes to some droid totally without clue :-( .

>checking future posts or whatever.

Moreover it is up to that organization to designate its preferred "abuse@"
domain, rather that have it tied to some mythical "top level" (yes, if you
send it to the 'wrong' address, it MAY get passed on to the right person
eventually - IF you are lucky).

>administrators, so that's what most people use.

Right, so the algorithm I am trying to establish for finding that person
is:

   IF there is an Injection-Info header THEN
      IF it includes a "mail-complaints-to" parameter THEN
         use that address
      ELSE
         use "abuse@<path-identity>"
      FI
   ELSE
      Locate the <path-identity> of the injecting agent in the Path
      header (it should be followed by "POSTED");
      use "abuse@<path-identity>"
   FI

Actually, the <path-identity> you find in the Injection-Info is supposed
to be the same as the one you find from the Path, just so there is one
thing less to go wrong.

Question: Clearly injecting agents have to arrange that a working abuse
address can be found from the above algorithm. Do you want that to be a
requirement with the strength of a "MUST"?

>described as optional and in USEFOR it is said to be optional).

No, I don't see that in 2.3. Certainly, provision of Injection-Info has
always been a SHOULD, so it is not mandatory. If someone wants to change
that, then speak up (though I detect some reluctance to create more
mandatory headers).

>usenet@ and have email delivered to the correct place.

Not quite. I would not expect "news@" to work for every domain name where
"abuse@" worked, or vice versa. "Abuse@" should go to some designated desk
within the organization. Ideally, I would hope that "news@" would work for
every serving, relaying or injecting host identifiable in the Path (that
is what RFC 2142 implies, though I am not insisting on quite that much
in my text).

>-=-=-=-=-

>MUST yield a valid email address.  Then drop all the rest of the guff.

Indeed, the text could be recast in that form. But I would like us to
agree on what the complaints procedure is to be, and whether "news/usenet"
needs different treatment from "abuse" (like whether it needs to work at
relaying agents found in the Path) and so on, and which bits of it are
MUST/SHOULD/should/MAY, before I start writing new text.

>header field is being talked about,

The "mail-complaints-to" paramater, if present

> and I have a big problem
>they should be excused offering abuse@ ...

It's what our drafts have said for the last N years. If someone wants to
propose a change, then do so, but I suspect that small private sites
currently do not provide "abuse@".

>requirements of 2821. That's a can of worms that is best left alone here

Sure. I was merely pointing out that RFC 2821 used the dreaded "MUST" word
in much the same context as I was trying to use it, and nobody was
complaining about 2821 on that ground.

>alone; it's far too complex to describe the general case :(

The MUST relates to providing enough information for my algorithm above to
work. Providing suitable MX records is just one way of achieving that. The
question at issue was whether the "MUST" word could be used at all in the
context of ensuring that a clear route to an abuse address exists.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 28 Jul 2005 19:04:10 +0200

>       use "abuse@<path-identity>"

Okay, now I think I see the problem:  What you want is in fact
no "MUST abuse@<p-id>", but a "MUST mail-complaints-to" with a
default abuse@<p-id>.  In other words, if abuse@<p-id> exists,
a mail-complaints-to might be omitted, although that's not a
good idea.  Is that so far correct ?

If "yes" what you have is essentially correct.  But it was not
exactly obvious for two or three users here, so maybe it needs
a better explanation / motivation than the "MUST abuse@<p-id>".

                       Bye, Frank

---

From: Richard Clayton <[email-masked]>
Date: Thu, 28 Jul 2005 20:41:14 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>domain, 

yes, but there should be a simple default if they do not so designate

>      use "abuse@<path-identity>"

yes, I'm happy with that.   So now you only need to say that if people
choose to have an Injection-Info header field they should ensure that
following this algorithm will result in a suitable address for reporting
problems with the article.

>to be the same as the one you find from the Path

I saw that, but I did not see why that was necessary. By making that a
requirement you are complicating things (because the path-identity in
the Injection-Info header field may have some relationship to email
handling, whereas the one in the Path header field has no such need)

>, just so there is one

that's not necessary -- besides, if they mismatched should people
discard the article as malformed ?

Mind you, going back to the algorithm above -- if you have a mail-
complaints-to clause then what purpose is the path-identity serving ?

>requirement with the strength of a "MUST"?

I think it's a SHOULD, nothing really breaks if a site only posts
perfect, universally welcomed, articles and doesn't have an abuse
address.  I like my words above as it happens

   the Injection-Info header field data SHOULD contain values so that
   following this algorithm will result in a suitable email address for
   reporting problems with the article.

no nonsense about mailable, or making statements such as the email must
be accepted or acted upon or anything else implausible.

I stick with my position that in 2005 everyone but everyone has an email
address, even people at the far end of mythical UUCP links.

>No, I don't see that in 2.3. 

   An injecting agent MUST
   identify itself with the same <path-identity> in both Path and
   Injection-Info header fields

that looks like a requirement to me.  If you want to say that if it
chooses to have an Injection-Info header field then dot dot dot then I
suggest you changing the text. I just read it as it is.

>Certainly, provision of Injection-Info has

Almost everyone generates one of the many variants.... so it is not a
huge imposition. However, given my remarks above about newsparadise.com
(or wherever) that never needs to trace anything and never has
complaints, then I don't suppose it reaches MUST status.

>"abuse@" worked, or vice versa. 

OK -- well that entirely argues for going for the determine the email
address algorithm approach, since this subtlety would make the existing
complex wording even worse

>"Abuse@" should go to some designated desk

2142 was merely recording what "everyone knew" at the time. Times change
(and so such specialist addresses fall out of use because of the need
for spam filtering and the rise of the specialist abuse team). Hence I
don't a huge value in repeating any of what is in 2142 if it's not an
actual requirement to make the system work.

>Indeed, the text could be recast in that form. 

I recommend it

>currently do not provide "abuse@".

if you don't provide abuse@ then you end up in the rfc-ignorant lists
and the ignorant blacklist your email.  Only a fool doesn't currently
accept email addressed to abuse@

but what I was puzzled about was why a "non-public service" was the
distinction ?  if the articles reach the main feed then the status of
the injecting site is not going to matter much one way or another

To restate (for the skip-reading) my slightly refined proposal:

a) set out the algorithm for deducing the email address to write to, the
one Charles proposed looks OK to me

b) make it a SHOULD that there is an Injection-Info header field and
that the information in that field yields a suitable email address, when
the algorithm is applied, to reach the people responsible for the
injection event.

c) someone needs to justify why there is a path-identity in the
Injection-Info at all (let alone why it has to match the Path), there's
two completely different things going on (where did it come from, who do
I complain to) and mixing them up is (apparently) pointless

d) drop all mention of news@ and usenet@  (leave 2142 to its own
devices)

e) I appreciate I'm going for "email only" to deal with complaints. I
think it's possible (and realistic) for all sites as a base level
complaint mechanism.

- -- 
richard                                              Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Jul 2005 15:11:11 GMT

>>   IF there is an Injection-Info header THEN
...................

>yes, I'm happy with that...........

>I saw that, but I did not see why that was necessary.........

>that's not necessary

OK, you have persuade me to s/MUST/SHOULD/

>complaints-to clause then what purpose is the path-identity serving ?

You would still use it for "news@" and "usenet@". And just for knowing who
really injected it. If it really was injected at demon, but complaints
were supposed to go to the Beeb, for some strange reason, then it would
still help to know that it was demon that put the header there.

>address.

And pigs might fly :-) .

But your SHOULD preference is noted. Let us hear other opinions on that.

>be accepted or acted upon or anything else implausible.

All "mailable" means is that there is some server somewhere that will
accept it. If it then silently goes to devnull, then that is regrettable,
but not much we can do about it.

>suggest you changing the text. I just read it as it is.

Point taken. I now have:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref header fields. Whatever <path-identity> is
   used in the Path header field SHOULD be used also in any Injection-
   Info header field (and it would be normal to use it in any Xref
   header field also).

>2142 was merely recording what "everyone knew" at the time.

Yes, but unfortunately its status is "Proposed Standard", and it is a
mess. So I thought it better to decide exactly which bits we wanted and
write them down clearly.

> Times change
>for spam filtering and the rise of the specialist abuse team).

Yes, but "news@" and "usenet@" are still expected, though not necessarily
for every server internal to some site. So I still think they need a
mention. They are comparable to "postmaster@" in mail (and that has a
"MUST" behind it in RFC 2821).

>accept email addressed to abuse@

Well "clerew.man.ac.uk" hasn't landed in rfc-ignorant yet :-) .

The point is that there are all sorts of small sites, private peering
arrangements, and so on.

Anyway, I need to hear opinions on this. Can those sites be excused from
"abuse@"?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Jul 2005 14:29:34 GMT

>>    IF there is an Injection-Info header THEN
................

>default abuse@<p-id>.

Not quite. You MUST provide _one_ of the mechanisms. We might not care
which (or we might drop some hint that one or other is preferable).

What is you position on MUST vs SHOULD for providing at least one? Richard
seems to be preferring SHOULD, and we all know that MUST sends John into
apoplexy :-( .

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Jul 2005 23:03:28 +0200

Charles Lindsey wrote:

> What is you position on MUST vs SHOULD for providing at least
> one? Richard seems to be preferring SHOULD, and we all know
> that MUST sends John into apoplexy :-(

Forrest's 2119 quote is important:

| they must not be used to try to impose a particular method
| on implementors where the method is not required for
| interoperability.

We can justify a MUST about news@ / usenet@ because that's how
it always was, and NetNews is one of these very old systems
where "interoperability problems" (aka errors) have to be fixed
manually and are reported by mail (or phone).

For the mail-complaints-to better avoid 2119 keywords, and as
long as Scott doesn't catch you there is still the lower case
"must" or similar words.  Actually I think you can omit abuse@,
those who don't use mail-complaints-to (or its x-predecessor)
will also ignore any "MUST abuse@".

Their "zone cut" will be listed as abuse.rfc-ignorant, their
peers will have to share the fun, sooner or later it goes to
news.admin.policy or what's the UDP group, and they're cut off.

Unrelated:  One script that will have to implement 2231 to get
mail-complaints-to is Spamcop (using SC for news complaints is
shaky, but in simple cases like groups.google.com okay).  Bye