From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Sep 03 1997 - 08:43:30 CDT
Simon Lyall <simon@darkmere.gen.nz>:
>On Tue, 2 Sep 1997, Charles Lindsey wrote:
>
>> >1. Originator-Info header
>>
>> > The Originator-Info header provides a list of attributes which may
>> > be used to trace the originator of an article. The Originator-Info
>> ^^^^^^^^^^
>> > header used in news articles is a special case of the Header outlined
>> > in draft-newman-msgheader-originfo-01.txt .
>>
>> Perhaps "originator" should be "sender" here.
>It should really be "poster" since this draft is news orientated.
Then you will need to redefine the term "poster". Let us coin the term
"injector" (just for the nonce). Usually, the poster and the injector
are the same. But there are circumstances where they are not. If the boss
(who wrote the article, and expects to receive the credit in the From:
line) gets his secretary to submit it, which is which? More importantly, if
a person submits his article to a mailing list which is subsequently
gatewayed into news, then the gatewayer is clearly the "injector". Do you
want to rewrite the definition so that the gatewayer is also considered the
"poster"? That would be counter-intuitive, I think.
Note that it is the injector who is going to be attested to by the
Orginator-Info: header. Traditionally, both the secretary and the
gatewayer (and also the moderator) have been expected to put themselves in
the Sender: line (not that they always did). This was why I suggested
using the term "sender" in the various places. I could live with your use
of "poster" here, but only if you redefine its meaning accordingly.
>In theory each article should only ever pass through one injecting-agent,
>everything after that is a relayer of some sort. If you have more than one
>injecting-agent then you run the risk of things like moderators being
>mail-bombed. Obviously their should be an easy way for an injecting-agent
>to detect an article has already been "injected" and then deal with it
>from a relayers point of view (this might mean dropping it). I was
>thinking of just saying that the injecting-agent should check to see if
>the "Path: " was more than one element long or something similar.
>>
>> > An "Originator-Info" header MUST be generated by an injecting agent
>> > and included in every Usenet article. If it is already present when
>> > an injecting agent receives the article then it SHOULD be removed (if
>> > it is incorrect) and a correct version added.
>>
>> I think there will be problems with the requirement to remove this header
>> whenever a new one is generated. Consider an article that has meandered
>> through a variety of gateways, posting agents, etc...
>See above, the second agent should know that the article has already been
>injected and not remove the header.
Fine, if you are prepared to allow that, but in that case you need to
relax the wording. Remember that articles from mailing lists may already
have Originator-Info headers in them (assuming that drums adopts Newman's
proposal), and I should not be surprised to see Auth: headers turning up in
mail articles, either (drums or not). How about the following wording?
An "Originator-Info" header MUST be generated by an injecting
agent and included in every Usenet article UNLESS the article
already contains an "acceptable" Originator-Info header, such as
one that is already covered by a verifiable "Auth" header, or one
whose "server" attribute is consistent with the sender
{poster/whatever}, or that the injecting agent considers
trustworthy for some other reason. If the header is not acceptable
in that sense, then it SHOULD be removed and replaced with a new
one. Note: an article MUST NEVER contain two Originator-Info
headers.
Note that I said "verifiable" rather than "verified". I am not sure I want
to place such an onus on the injecting agent. If the signature in the Auth
is not one he is familiar with, then it will take considerably more than
the mythical 4ms to look it up in some global database of public keys.
>"auth-poster" ?
Just a thought here. It should always be the case that the injecting agent
knows who the posting(sending?)-agent was. To know the actual poster will
be difficult unless (s)he actually lives on the same site. Most often,
nowadays, the poster will be sat at some ghastly Windoze machine where the
concept of a particular "user" does not exist. In such cases, I presume it
should be using the auth-posting-agent (sp?) parameter rather than this
one.
>I just had a look at RFC2045 ( I assume you are refering to section 5.1
>?).
Yes
>The special tokens of "from" , "sender" , "reply-to" (I missed this
>one) and "approved" would be case-insensitive and have special meaning.
I am not sure about reply-to. At least one out of From: Sender: and
Approved: should be good in EVERY article. The only case where Approved
would be relevant would be for spam-cancellers who customarily "forge"
both the From and the Sender (perhaps unnecessarily), and assuming we
support Approved in place of X-Cancelled-By.
However, no-one really expects the Reply-To: to relate to the posting
agent in any particular way. It might be nice to know that it was a "real
address", but I do not expect injecting agents to be routinely bothered
with checking it. If all the other three are bad, then I doubt the
Reply-To would turn out to be good.
>> >3. Examples
>>
>> >Originator-Info: server="news.isp.example";
>> > server-contact="dave@isp.example";
>> > auth-author="from"; auth-method="nntp auth-info"
>>
I see in your latest example that you have removed the quotes from around
"news.isp.example". Whilst I would support this, special syntax would be
needed, because it is not supported by RFC2045.
>Do we need to seperately register each token, Since the header is not yet
>registered I would presume that these tokens could be included in the
>standard that officially creates it?
I don't think you beed to worry about the IANA until your RFC becomes
"standards-track" (or is getting pretty close to that stage). An exception
might arise if the public were being recommended to use some draft before
the standardisation process became complete, but you would have to ask
IANA about that one.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------- Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 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