Subject: Injection-Info and <sender>

From: Russ Allbery <[email-masked]>
Date: Tue, 17 Jan 2006 10:10:03 -0800

Having reviewed the current text in the light of the current discussion, I
think that the "sender" attribute of the Injection-Info header is a
mistake and should be removed completely.  "posting-account" is
sufficient for tracing purposes and can be an addr-spec if some site
really wants it to be (and that violates a SHOULD, which after a some
consideration I think is correct).

If a site really wishes to enforce putting an e-mail address for the
poster known to that particular site into a header (such as for
internal-only news servers inside an organization), it can enforce the
contents of the Sender header by rejecting messages with a Sender header
set to something other than what it wants and adding a Sender header to
posts that don't have it.  Usually this is a bad idea; I don't see any
particular purpose served by adding a new machinery in the standard for
doing something that's only appropriate in a few edge cases.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 20:08:59 +0100

Russ Allbery wrote:

> Having reviewed the current text in the light of the current
> discussion, I think that the "sender" attribute of the
> Injection-Info header is a mistake and should be removed
> completely.  "posting-account" is sufficient for tracing
> purposes

ACK so far, that was also my impression.

> and can be an addr-spec if some site really wants it to be

I considered "verified" / 9*( ALPHA / DIGIT / "+" / "/" / "-" )
to preserve "verified" somehow, but that's probably a bad idea.

> it can enforce the contents of the Sender header by rejecting
> messages with a Sender header set to something other than
> what it wants
[...]
At least we don't explictly support Resent-*, so it's either
Sender or "single-From" without Sender.

> and adding a Sender header to posts that don't have it.
> Usually this is a bad idea;

Also known as 2476bis 8.1 "MAY add Sender".  For the complete
horror trip visit SenderID-PRA, two appeals so far, and I push
for an escalation to the IAB.
                                Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 18 Jan 2006 16:49:13 GMT

>consideration I think is correct).

OK, that is certainly a valid position to take. And I agree that it would
not often be used, because that information is not available to most
injectors.

But would you be willing to include an "authentication" parameter, for use
with SASL authentications (which will surely become wqite common once the
new NNTP spec comes into use)? Again, they might or might not be email
addresses, but at least a person who does not wish to expose himself too
far can negotiate some pseudonym for his authentication identity.

>doing something that's only appropriate in a few edge cases.

Posters are currently supposed to include a Sender header when RFC 2822
says they should. I have no great problem with an injecting agent adding
it if it not already present (USEPRO currently permits it, but USEAGE
could address whether it is a GOOD THING or not).

-- 
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: Russ Allbery <[email-masked]>
Date: Wed, 18 Jan 2006 11:01:43 -0800

Charles Lindsey <[email-masked]> writes:

> But would you be willing to include an "authentication" parameter, for
> use with SASL authentications (which will surely become wqite common
> once the new NNTP spec comes into use)? Again, they might or might not
> be email addresses, but at least a person who does not wish to expose
> himself too far can negotiate some pseudonym for his authentication
> identity.

As previously discussed, I'm happy to have two separate fields defined in
Injection-Info, one for the authentication identity and one for the
authorization identity.  I do expect that this will come up.

I believe they should both have the same language about how the value
SHOULD be encrypted.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 19 Jan 2006 07:48:27 +0100

Russ Allbery wrote:

> As previously discussed, I'm happy to have two separate
> fields defined in Injection-Info, one for the authentication
> identity and one for the authorization identity.  I do expect
> that this will come up.

> I believe they should both have the same language about how
> the value SHOULD be encrypted.

One option would be to allow only B64 characters, and then let
servers do whatever they like.  For that we'd say B64-encoded
version of something that SHOULD be encrypted, or similar.  Bye

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 19 Jan 2006 13:02:36 GMT

>authorization identity.  I do expect that this will come up.

Hmm! I thought earlier discussions indicated that 'authentication' was the
one we really wanted, so I would like to hear a good reason why we might
want to provide both.

>I believe they should both have the same language about how the value

Not so clear what you mean there. Are you saying that the injector
MAY/MIGHT/SHOULD map the supplied SASL authentication string into
something not obviously related to it, with a 1:1 mapping so that a given
authentication identity always showed up as the same string when it was
shown in an Injection-Info header? That would make it much the same as the
"posting-account" parameter IMO, so what would be the point of having a
separate "authentication" parameter in that case?

---

From: Russ Allbery <[email-masked]>
Date: Fri, 20 Jan 2006 11:34:11 -0800

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> As previously discussed, I'm happy to have two separate fields defined
>> in Injection-Info, one for the authentication identity and one for the

> Hmm! I thought earlier discussions indicated that 'authentication' was
> the one we really wanted, so I would like to hear a good reason why we
> might want to provide both.

No, authorization is the one that you really want.  Authentication
identity is rarely useful and mostly internal to the site, if it's
different (it usually won't be).  However, there are circumstances
involving role accounts where one might wish to provide both.  (Consider
newgroup messages posted through a news role account, for instance.)

> something not obviously related to it,

Yes.

> with a 1:1 mapping so that a given authentication identity always showed
> up as the same string when it was shown in an Injection-Info header?

A 1:1 mapping should not be required.  We can recommend it for improved
spam filtering, but it's not obviously the right thing to do from a
privacy standpoint and I don't think we're in a position to document (or
even determine) the right thing to do in general.  I'd rather leave that
decision to the local news administrator.

> That would make it much the same as the "posting-account" parameter IMO,
> so what would be the point of having a separate "authentication"
> parameter in that case?

To hold the authentication identity.  posting-account logically would be
the authorization identity.  (Well, I suppose it could be either, but if
it's supposed to be the authentication identity, we need another attribute
for the authorization identity.)

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 23 Jan 2006 12:05:58 GMT

>newgroup messages posted through a news role account, for instance.)

Hmmmmm! See http://www.imc.org/ietf-usefor/mail-archive/msg00934.html and
the messages in the thread immediately preceding it, from which I thought
we had agreed that "authentication" was the one we needed as a separate
parameter, and that the "authorization" would be better in the
posting-account (and would probably be related to the Sender: of the
article rather than the From:).

>decision to the local news administrator.

There is wording currently in USEPRO which encourages consistency in the
usage of Injection-Info parameters:

      ....  Each injecting agent SHOULD
      use a consistent form of the Injection-Info header field for all
      articles emanating from the same or similar origins.

Suppose there is some Troll who is causing problems in some group, and who
continuously morphs his identity so as to avoid killfiles, or to argue
with himself, or generally to cause mayhem.

It is exceedingly useful for others on the group to be able to recognize
his in his various guises (not necessarily to find his true identity -
whatever that means - but at least to establish that he was the same guy
as published earlier articles).

An Injection-Info header is one of the tools which, if consistently used,
can aid the detection of such trolls (for sure, many people currently
manage to deduce it based on the present headers, but the more information
provided by the injecting agent, the easier it becomes).

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 Jan 2006 09:09:24 -0800

>> involving role accounts where one might wish to provide both.
>> (Consider newgroup messages posted through a news role account, for
>> instance.)

> Hmmmmm! See http://www.imc.org/ietf-usefor/mail-archive/msg00934.html
> and the messages in the thread immediately preceding it, from which I
> thought we had agreed that "authentication" was the one we needed as a
> separate parameter, and that the "authorization" would be better in the

Oh, I see, you meant something else by "authentication is the one we
really want" than what I thought.  I thought you meant that in the sense
that it was the more important value, which isn't the case; you instead
meant that it was the one that should be a separate parameter.  That I
agree with, although really, the naming of the parameters is unimportant
to me as long as it's not horrible and as long as the document clearly
defines it.

The important bit is providing a place to put the authorization parameter,
encrypted, if the site wants to.  Providing an encrypted place for the
authentication parameter as well is possibly useful but not horribly
important to me.

>> privacy standpoint and I don't think we're in a position to document
>> (or even determine) the right thing to do in general.  I'd rather leave
>> that decision to the local news administrator.

>       articles emanating from the same or similar origins.

Yes, that's a SHOULD, which isn't a requirement.  The recommendation for a
consistent form is something that I think is on the borderline between a
SHOULD and a simple recommendation, although I would lean a little more
towards the latter due to the privacy issues involved.

> Suppose there is some Troll who is causing problems in some group, and
> who continuously morphs his identity so as to avoid killfiles, or to
> argue with himself, or generally to cause mayhem.
[...]

Yes, yes, I'm familiar with all this; this is old ground.  However, the
privacy issues are still important, and as has been painfully established
in other contexts, consistency of opaque identification is often
sufficient to penetrate a privacy shield.

I am considerably less interested in the use of Injection-Info for
killfiles (something that I frankly think is unlikely given the hideous
syntax that won't work with existing killfile tools) than I am in its use
for trace information, which should be the *primary* purpose.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 24 Jan 2006 15:32:04 GMT

>to me as long as it's not horrible and as long as the document clearly

OK, does that mean we now have agreement to go ahead and include it? You
and I appear to accept it. Any other comments?

And there is also your proposal to remove the semder parameter. I am not
enthusiastic about that, but if it is the general desire, then so be it.

>authentication parameter as well is possibly useful but not horribly

I think we agree that goes in posting-account, if the situation arises.

>for trace information, which should be the *primary* purpose.

I think people will want to try and use killfiles here, if their user
agents make it possible. So long as injectors don't make their
Injection-Infor headers needlessly complex, then it will propably be
possible. But I agree that it is not the primary purpose of this header -
just a useful fallout possibility.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 24 Jan 2006 12:52:06 -0800

>> The important bit is providing a place to put the authorization
>> parameter, encrypted, if the site wants to.  Providing an encrypted
>> place for the authentication parameter as well is possibly useful but
>> not horribly important to me.

> I think we agree that goes in posting-account, if the situation arises.

The authorization parameter, you mean.  Yes?