From: Russ Allbery (rra@stanford.edu)
Date: Thu Nov 04 1999 - 21:49:13 CST
Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> I see nothing in RFC 1036 or Son-of-1036 to support the view that the
> first character should suffice. Anyway, I have now removed
> "unmoderated".
For a lot of things news-related these days, existing code is a better
reference. From INN, a bit of code in the traditional shell script
control message handling that's remained unchanged all the way back to
at least 1.4:
case "$2" in
[Mm]*)
set $1 m
;;
*)
set $1 y
;;
esac
I've seen control messages issued with just "m" before, although spelling
out "moderated" is more common. As you can see, INN historically accepts
*anything* else as indicating that the group be unmoderated.
> NOTE: some alternative flags such as "y" and "m", which are sent and
> recognised by some current software, are NOT part of this standard and
> MUST NOT be used.
Collabra also sends rmgroups with an "r" flag to indicate that they're
supposed to be recursive, but I don't see any particular reason to
document that. Just mentioning it as an aside.
> Yes, I can see a use for a few announce groups, and maybe for groups
> like news.answers. OTOH, users are going to find it confusing not to be
> allowed to post to what seems a normal group.
Well, the news server does send back a "local posting not allowed" error
message, and some clients understand that. But I can see your point about
rejecting the message with an autoresponder too. The advantage of the
former method over the latter is that it works even if the user uses a
munged address.
> OTOH, I can see an argument against. These are very specific texts,
> written in a specific language (and you deprecate that practice further
> down). I am toying with the idea of making the "For your newsgroups
> file:" optional with a "but you SHOULD always put it in" for backwards
> compatibility. That leaves the way open to get rid of it in a few years
> time. Is will not be necessary once everybody is putting it all inside
> an application/news-groupinfo. But if you are going to go that way in
> the long term, then putting in "Moderator contact address:" and
> "Moderator submission address:" would be a Bad Thing now.
> So is there support for making "For your newsgroups file:" optional as
> suggested?
I'm in favor of that, if we're going to be stuck with the MIME parse
anyway. The name of the section already dictates its contents.
Downgrading the MUST to a SHOULD for backwards compat makes a lot of sense
to me; it means that people can drop the practice when it's no longer
necessary without being non-compliant.
> As to requiring Mime in servers, I do not see this as a problem. Surely
> all control message processing is going to be hived off into a separate
> and watertight part of the software, that processes them at leisure and
> independently of the rest of the server's activities.
True.
[ propagation rules for newgroup messages ]
> Yes, what you state is my understanding (except that issuers may
> sometimes add other groups to ensure more widespread propagation). But I
> don't see this mentioned anywhere in our current draft. Would you like
> me to say something on this?
Not sure. In general, we haven't talked about propagation rules, and it's
a bit outside the scope of the draft; on the other hand, it *is* an
interoperability concern that affects the article format, since it affects
what people put in the Newsgroups header of newgroup messages. And people
have had a hard time convincing people not to do things like put
news.admin.hierarchies in the Newsgroups header of all their control
messages for some obscure hierarchy that the people carrying only news.*
don't want.
>>> NOTE: It is entirely proper for a serving agent to retain the
>>> group until all the articles in it have expired, provided that
>>> it ceases to accept new articles.
> I think CNews currently gives this behaviour (and it needs some quite
> tricky code to do it properly). But, as others have pointed out, the
> practice should be encouraged, and it does not fall out naturally from
> the "obvious" way of implementing it.
Well, I don't personally find the above very useful; I'm quite content
with the whole group going away, including all of its articles,
immediately. But I won't really argue a NOTE, and there's nothing that it
says that I disagree with. I suppose it's true that it's somewhat
inobvious.
[ mvgroup ]
> But as to overviews, what ARE the implementation problems? Is it
> sufficient to recalculate the complete overview for the affected
> group(s)? I presume most software provides that facility, if only to
> mend the overview file when it has got broken.
Yeah, but it usually requires pausing the server to do. But expanding
that facility and finding a way to do it without pausing the server would
probably be sufficient for handling the overview changes when moving a
group. I suppose one could just use the existing overview, but I'm rather
hesitant to do that.
>> Ew... I wouldn't want to touch an implementation of this. Any way you
>> do it will cause serious client-side weirdness for users who were
>> reading both groups.
> Well that is why is says "MAY", backed up by some pretty unpleasant
> "MUST"s. OTOH, I guess that the users are going to complain bitterly if
> it isn't done :-( . Do you want me to put in a NOTE warning that users
> should not harbour such expectations?
A NOTE pointing out that there basically is no sane way to do this and
preserve the full semantics of NNTP article numbers from both groups may
be in order, although that's a bit outside the normal scope of our draft.
>>> NOTE: Some serving agents that use an "active" file permit an
>>> entry of the form "oldgroup xxx yyy =newgroup", which enables
>>> any articles arriving for oldgroup to be diverted to newgroup,
>>> and users already subscribed to oldgroup to receive articles
>>> from newgroup instead.
> Nevertheless, it seems agreed that the behaviour would be a Good
> Thing. So do we leave it in in order to encourage implementors to try?
> It is, after all, only a NOTE.
I'm in favor of leaving it in. I think it's closer to the right thing to
do than what INN 1.7.2 does. (Maybe a later version of INN does more the
right thing; I'd check, but unfortunately don't have time to hunt for that
code just at the moment.)
[ checkgroups scope ]
> But somebody else says it will (the feature is not much use without it).
> CNews does not do it at all AFAIK. But seems like the feature is useful
> and should remain.
I'm definitely in favor of it.
> The body of the message has the Content-Type
> "application/news-checkgroups". It asserts that the newsgroups it lists
> are the only newsgroups in the specified hierarchies. If there is an
> invalidation, it asserts that the hierarchies it names no longer contain
> any newsgroups.
> However, I think we could now legitimately ask whether the
> 'invalidation' feature might not be better removed altogether. I think a
> checkgroups message with a checkscope for the obsolete hierarchy and an
> empty list would now do all that is needed.
Did I miss a definition of what an invalidation is supposed to be? I
still don't really understand the concept.
>>> NOTE: The checkgroups nessage is intended to synchronize the
>>> list of newsgroups stored by a serving agent, and their
>>> descriptions, with the lists stored by other serving agents
>>> throught the network. However, it would be inadvisable for the
>>> serving agent actually to create or delete any newsgroups
>>> without first obtaining the approval of its administrators for
>>> such proposed actions.
>> If it's authenticated, why not, if the server is so configured?
> Have you never seen a checkgroups in which the issuer had inadvertently
> left out half of the hierarchy?
So you put a consistency check into the checkgroups processing and refuse
to automatically process a message that affects more than 5% of the
hierarchy or something. I don't think it's a good idea to say servers
shouldn't act automatically on authenticated checkgroups if they only
affect a handfull of groups; given how busy most news administrators are,
it would probably be much better if existing software did this.
> But the nice thing about putting it in an application/news-checkgroups
> is that people are more likely to understand that application types
> should have a rigid syntax, and moreover there is the opportunity to
> make it a multipart/mixed with an extra text/plain part if you want to
> put in some human-readable commentary as well.
True.
> OK, I would like to hear some more opinions on this, since you are
> proposing a departure from what is _believed_ by most people to be
> current practice. I was not aware that third-party cancellers were
> currently using their own From headers. And what does the Sender check
> in INN actually do?
I'd say that 50-60% of the servers out there that honor cancels perform no
checks on cancel messages whatsoever, since it's a performance hit, it's
meaningless for pre-cancels anyway, and it's no longer the default in
current versions of INN.
If the cancel arrives before the article, and cancel verification is
turned on, INN doesn't honor the cancel. This is generally not what you
want at all for spam cancels, and spam cancels frequently arrive before
the article. This is one of the major reasons why people turn it off.
If the article arrived before the cancel *and* cancel checks have been
specifically turned on, INN takes the Sender: header of the cancel, or the
From: header if there's no Sender:, and compares it to the Sender: header
of the article, or the From: header if there's no Sender:, and only honors
the cancel if they match. Third-party cancellers therefore generally put
the From/Sender of the article they're cancelling into the *Sender* header
of their cancel.
The entire thing is basically meaningless, and I'm going to eventually rip
the whole check out of INN completely rather than just having it an
off-by-default behavior; the only question is whether I'll propose doing
that now or wait until we have some sort of real authentication system.
-- Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>