Subject: Re: ISSUE: 3.2.14 : <sender>

From: John Stanley <[email-masked]>
Date: Mon, 16 Jan 2006 13:53:27 -0800 (PST)

Russ Allbery <rra@xxxxxxxxxxxx>:

>Sites should have some protocol-defined place to put a local identity into
>the headers if they wish to do that for tracing or accountability purposes
>under their local site policy.  Whether that be an e-mail address, a
>username, a UID, or some encrypted, base64-encoded string should be
>entirely up to the local site policy, its privacy policy, and so forth.

Of course. And such a place exists. It's called the "Message-ID". It is a
globally unique identifier applied to each article either before or as it 
is injected. Any site that feels a need to track users against the 
articles they post can do so trivially by recording 
message-id/authentication pairs locally, plus whatever other information 
they deem reasonable or necessary or even just convenient.

>The information in Injection-Info should not be the same information as
>>From or Sender semantically.  It should be site-specific poster identity
>information in whatever form is convenient and useful for that site.

Let's take that to an extreme, ok? I'll run a server that uses 
authentication for it's readers, and I'll let you have an account there. 
Now, _I_ think the "convenient" form for your identity information is to
put in the unencoded ascii for your username AND password. That's 
convenient for me, but perhaps not so convenient for you. Oh, by the way,
I didn't bother telling you I was doing that before you posted your last 
article. It wasn't convenient for me to do so. Are you happy about this?

Once you accept that 'convenient and useful for the server admin' aren't 
the sole criteria here, we can start to talk about the other criteria like 
privacy and security. A site is free to record anything it wants about the
articles its users post in its own database, in whatever format they want 
to record it. It is when they decide to release user information to the 
public that they cross the line. Injection-Info that contains user 
information crosses that line.

>If it happens to have the form of an e-mail address, well, that's an 
>interesting coincidence from the perspective of the standard, but not 
>something that software is allowed to draw automated conclusions from.

We've just had the discussion in this list about spammers sending junk 
email to MESSAGE IDs because they look like an email address (and yes, 
even though I didn't say "me too" at the time, I've seen a considerable 
amount of spam sent to message ids on my own systems), so why you think 
that spammers (and worse) won't jump on the Injection-Info header as a 
source of verified information is beyond me.

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>But we are not proposing to "modify" any header. We are discussing what
>should be in the Injection-Info at the time it is _created_.

If the Injection-Info header says "here's who really posted this article", 
then it is a de-facto change to the meaning of the other headers. Whether 
or not the contents of the other headers changes, their meaning changes.

>Exactly so. If the entity that posted the article possesses an email
>address (like what would have been put in the Sender header, if present)
>AND if the injecting agent has the ability to determine that (or some
>such) address, then it can go in the Injection-Info as a 'sender'
>parameter.

The question is not CAN it do so, but SHOULD it be allowed to do so. If an 
injection agent is going to say "that's not the real sender, here's who 
really sent this..." then it MUST know that information (not just guess),
and even if it KNOWS it is still a privacy and security issue. AND 
irrelevant as well, since the email address had nothing to do with 
injection, and thus has no place in an Injection-* header.

>If neither of those prequisites applies, then the injecting
>agent will have to use something else.

No, there is no "have to" involved here.

>It is for the injecting agent's admin to decide (and pros, cons and
>privacy implications are discussed in USEAGE).

If we are not the group deciding the contents and meanings of headers, why
are we spending all this time discussing the contents and meanings of the
headers? Yes, sir, we do have a say in prohibiting user identification
being placed in Injection-* headers. It is NOT for the injecting agent's
admin to decide the meaning of the news headers.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 16 Jan 2006 15:04:33 -0800

>> Sites should have some protocol-defined place to put a local identity
>> into the headers if they wish to do that for tracing or accountability
>> purposes under their local site policy.  Whether that be an e-mail
>> address, a username, a UID, or some encrypted, base64-encoded string
>> should be entirely up to the local site policy, its privacy policy, and
>> so forth.

> Of course. And such a place exists. It's called the "Message-ID". It is
> a globally unique identifier applied to each article either before or as
> it is injected. Any site that feels a need to track users against the

Ideally, all servers should be able to just use the message ID to look up
information in logs, I agree.  In practice, that can be a pain in the
neck.  I see value in providing servers with an *optional* place to record
trace information.  Servers are going to do it *anyway* whether we
standardize a way or not (there is no standardized way now, and as a
result there are several dozen different unstandardized ways in use), so
it improves the situation for everyone to provide a standardized way so
that servers will stop screwing with other headers.  This is particularly
true because clients that need to do reinjection must be aware of what the
header is named.

> authentication for it's readers, and I'll let you have an account
> there. Now, _I_ think the "convenient" form for your identity
> information is to put in the unencoded ascii for your username AND
> password. That's convenient for me, but perhaps not so convenient for
> you. Oh, by the way, I didn't bother telling you I was doing that before
> you posted your last article. It wasn't convenient for me to do so. Are
> you happy about this?

Within the framework that we're discussing, I'm happy about it in the
sense that I think it's completely out of scope for us to care.  Local
means local.  It's absolutely none of our business what people decide to
put in such a field from a *protocol* standpoint.

It's obviously a stupid thing to do from a security standpoint, but it is
emphatically NOT the purpose of a standard to legislate against every
stupid thing that anyone could possibly do.  It is the business of a
standard to define fields and their uses, and when the use is "local
information used at the discretion of the server admin," it means exactly
that.

Taking your extreme to its obvious conclusion, we'd have to sprinkle the
document with things like "don't put user passwords into the body of
Usenet articles."  People get to figure out that sort of thing all by
themselves.

> the sole criteria here, we can start to talk about the other criteria
> like privacy and security.

If you want to write a separate RFC on how to choose trace information in
a way that protects privacy, that may very well be a useful document.
We're working on a document specifying the syntactic and semantic
structure of a news article, and shoehorning that sort of document into
this one would be a mess.  (And, to warn, I'm going to make exactly the
same argument when it comes up in USEPRO and USEAGE.)

> source of verified information is beyond me.

I don't think anything of the sort.

I also don't care when it comes to specifying the syntax and use of header
fields.

If your news server is putting things into Injection-Info that you don't
like, use a different news server.  Making rules in a standard about local
site behavior isn't going to change the real world.  I agree with you up
to the point of not wanting to see any *encouragement* for putting e-mail
addresses into the local authenticated identity field, and even
encouraging sites to use opaque identifiers, but beyond that there could
be any number of special circumstances and it is *really* none of our
business.

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

---

From: [email-masked] (Ralph Babel)
Date: Fri, 20 Jan 2006 13:51:01 +0100

Russ Allbery wrote:

> Ideally, all servers should be able to just use the
> message ID to look up information in logs, I agree.

Yes. Using Usenet (instead of /var/log) to store local
logging data is a waste of everybody's resources.

> I see value in providing servers with an *optional* place
> to record trace information. Servers are going to do it
> *anyway* whether we standardize a way or not [...],
> so it improves the situation for everyone to provide
> a standardized way so that servers will stop screwing
> with other headers.

Yes, unfortunately. But why should such a trace header
be restricted to the _injection_ server?

---

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

>> I see value in providing servers with an *optional* place to record
>> standardize a way or not [...], so it improves the situation for
>> everyone to provide a standardized way so that servers will stop
>> screwing with other headers.

> Yes, unfortunately. But why should such a trace header be restricted to
> the _injection_ server?

In practice, that's the only place that anyone really cares about.  The
other trace information goes into the Path header, and is mostly
irrelevant for tracing abuse unless things get to the point of wanting to
depeer a site (rare).

---

From: [email-masked] (Ralph Babel)
Date: Sat, 21 Jan 2006 17:50:52 +0100

Russ Allbery wrote:

> Ralph Babel wrote:
>
>> why should such a trace header be
>> restricted to the _injection_ server?
>
> In practice, that's the only place
> that anyone really cares about.

Would it hurt to call it "Trace" instead of
"Injection-whatever"? Or maybe even "Received"?

---

From: Russ Allbery <[email-masked]>
Date: Sat, 21 Jan 2006 11:16:37 -0800

> "Injection-whatever"? Or maybe even "Received"?

It wouldn't bother me in the slightest to call it Trace.  Received is
probably not a good idea since the format and contents are different (and
the Received header in e-mail is a mess that we don't really want to
emulate).