Subject: Re: You can't win!

From: John Stanley <[email-masked]>
Date: Thu, 11 Jun 2009 11:55:52 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>There is a third possibility, which I have seen in action: ignores
>>application/news-transmission header altogether and posts entire
>>encapsulated message as the body of a new article with locally-generated
>>headers.

>That is what would happen if there were also a Newsgroups header in the
>top-level email (and correctly so).

1. There was no "newsgroups" header in the "top-level email".

2. "Newsgroups" as a header is undefined in email and as such should be
    ignored. Rather, it is now multiply defined in practice and cannot be
    relied upon for anything. The attempt at implicitely defining it in
    USEPRO 3.5.1 "Forwarding Messages to a Moderator" is stepping outside
    the scope of USEFOR by defining an email header without actually
    defining one. RFC2076 covers this dichotomy.

3. The HUMAN reading and approving the email was presented with an
    encapsulated news message as the "body" of the submission, which
    differs from unencapsulated submissions in that it contains the headers
    for the news message, including any "references" headers that MUST be
    maintained in followups. That should be a red-flag to anyone actually
    looking at the submission.

>Or are you saying that it knows the intended newsgroup because it was
>emailed to that group's submission address. In which case might it not
>happily post and spam emailed to that address? That would be seriously
>broken too :-( .

Yes, it knows the intended newsgroup because it was mailed to the 
moderators submission address. The newsgroups header in email should be 
ignored because it has no well-defined meaning. This points out exactly 
why encapsulation should be the only defined means of forwarding messages 
to a moderator from a news agent. That USEPRO promotes ambiguous behaviour 
is a bug, not a feature.

SPAM is not an issue; if the moderator chooses to approve spam that 
appears in that mailbox, it is an issue of the moderator's good sense, not 
adherence to RFC.

(The ambiguous nature of "newsgroups" in email comes not because 
newsgroups is not defined in news, it comes because there are multiple 
entry methods for email sent to the moderator's submission address. If you 
could ascertain that a certain email MUST have originated as a submission 
to a moderated group via a news agent, the ambiguity would dissappear. 
Since any email in a moderator's mailbox can come from any source, you 
can't ascribe ONLY a news-specific meaning to Newsgroups in that email. 
You must ascribe the EMAIL meaning, which is "none".)

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 15 Jun 2009 13:03:41 GMT

>    looking at the submission.

Ah! So it was a human, who should have known better, and not some broken
script :-( .

>to a moderator from a news agent. That USEPRO promotes ambiguous behaviour 

Yes, we are all agreed that encapsulation is a _much_better_ way to
submit articles to a moderator.

But, unfortunately, the ghastly method of just putting a Newgroups (etc)
in the email is so widely used currently, and moreover a large number of
moderators are totally unaware of the 'proper' way to do it, that this WG
decided, some way back, that is was better to retain that ghastly method
rather than suddenly to break what was actually working reasonably well.

My message, which started this thread, was just to point out that adding a
Content-Type: message/news-transmission could actually break some
currently-working encapsulation-safe moderators' scripts, contrary to what
we had earlier assumed, and contrary to what USEPRO currently implies.

AND to ask whether anybody wanted to tweak our current wording during
AUTH48, which is our last chance to do so. But I hear no such suggestions
so far from this list.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            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