From: Simon Lyall (simon@darkmere.gen.nz)
Date: Tue Sep 02 1997 - 20:34:25 CDT
On Tue, 2 Sep 1997, Charles Lindsey wrote:
> Simon Lyall <simon@darkmere.gen.nz> wrote:
> >
> BTW, has this text been passed before Chris Newman, and do we know whether
> this idea is going to make it into the next drums draft?
I have not passed this draft onto anyone else apart from this list yet, I
was intending to forward it to Chris Newman for his comments and possibly
someone who is working on INN for their comments.
I have no idea if the drums people are including it in their draft, I have
not been in direct contact with them.
[ typos noted ]
> >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.
> Suppose the article was
> injected from a mailing list; then it is the gateway that you are trying
> to verify (it is up to the keeper of the mailing list to verify the
> originator). I note that Newman should also use the word "sender: here, as
> indeed he does elsewhere in his text.
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. Perhaps it was posted
> to a local newsgroup which was gatewayed to a mailing list which was
> subsequently gatewayed to a newgroup somewhere else.
> Suppose the first site created an Originator-Info header and signed it
> (along with other interesting headers and maybe the body) with an Auth:
> header. Now the next agent along the route is instructed to remove that
> Originator-Info header, whereupon the Auth: header becomes useless (and
> may as well be discarded as well - which would be a pity, since it
> contains valuable confirmation of the true origin of the article).
See above, the second agent should know that the article has already been
injected and not remove the header.
> >1.1. "server" attribute
>
> > The server attribute is the domain of the injecting agent that
> > is responsible for the article. An Originator-Info header
> > MUST include a server attribute.
>
> Newman has a nice phrase here which (paraphrased) speaks of "a server
> which the sender was authenticated to when the article was injected".
I originally kept this but it was felt that this should point to the
injecting agent. If another server did the actual authentication then the
auth-method could say something like:
auth-method="superauth by superauth.isp.example"
> >1.3. "server-contact" attribute
>
> > This attribute contains the preferred email address of the person
> > responsible for the injecting agent. When absent, usenet@<server> or
> > abuse@<server> as specified by RFC 2142 MUST be assumed, where
> > <server> is the value of the server attribute. This attribute is
> > optional and SHOULD NOT be included by RFC 2142 compliant injecting
> > agents.
>
> I think we have to fix on either "usenet" or "abuse" as the default. I
> suggest "usenet".
Since Brad has also pointed out that this may be used to mailbomb people I
will remove this and make a note about RFC 2142 further up.
> >1.4. "auth-author" attribute
>
> Perhaps it should be the "auth-sender" attribute.
"auth-poster" ?
> > This attribute contains the email address of the poster of the
> ^^^^^^
> sender
> > article. An Originator-Info header SHOULD include this attribute and
> > the server MUST ensure it is correct if it is included.
>
> > header correctly identifies the the poster. The server MUST
> > ensure this is correct if it is include.
> ^^^^^^^
> included
>
> I hope "From", "Sender" and "Approved" are case-insensitive. The
> syntax (borrowed from RFC2045 I believe) does seem to imply that.
I just had a look at RFC2045 ( I assume you are refering to section 5.1
?). The special tokens of "from" , "sender" , "reply-to" (I missed this
one) and "approved" would be case-insensitive and have special meaning.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
> >1.7. "login-token" attribute
>
> > The login-token attribute is used to allow the identity of the
> > sender to be traced without explicitly revealing that identity. It
> > contains site-specific information which may be used to recover the
> > identity of the poster. An Originator-Info header MAY include a
> > login-token attribute if the injecting agent does not wish to
> > explicitly reveal the identity of the poster
> ^^^^^^
> sender
> You uses "Sender" at the start of the rule OK. Newman uses "originator"
> here (he is wrong too).
I really think we should stay with poster since this is news orientated
and poster has special meaning for news. Perhaps we could point out in the
definitions that poster is usually equivilent to sender in mail.
> >2. ABNF for Originator-Info header
>
> > originator-info := "Originator-Info:" parameter *(";" parameter)
>
> The syntax pf <parameter> comes from RFC2045. Right?
>
No, I just left this as was in Newman's draft, I was going to do a proper
ABNF of the whole header later.
>
> >3. Examples
>
> >Originator-Info: server="news.isp.example";
> > server-contact="dave@isp.example";
> > auth-author="from"; auth-method="nntp auth-info"
>
> Are the quoted strings necessary in all these places? I can see a
> necessity for the auth-method, and perhaps for the domains and addresses
> (the RFC2045 sysntax seems to require that), but I hope that From, Sender
> and Approved could be regarded as tokens (they would have to be registered
> with the IANA).
I see what you mean. see above for my comments where you first make this
point. I'll rewrite with a few less quotes.
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?
-- Simon Lyall. | Looking for Work | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | MT.