Subject: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Feb 2006 14:12:36 +0100

Current text:

   The "posting-account" <parameter> identifies the source from which
   that news server received the article.  For security reasons, it
   SHOULD be in a cryptic notation understandable only by the
   administrator of the news server.

   The "sender" <parameter> identifies the mailbox of the verified
   sender of the article (alternatively, it uses the token "verified" to
   indicate that at least any addr-spec in the Sender header field of
   the article, or in the From header field if the Sender header field
   is absent, is correct).  If a news server can verify the sender of an
   article, it SHOULD use this <parameter> in favor of the "posting-
   account" <parameter>.

After reviewing discussion, a proposed alternate text:

   The "posting-account" <parameter> identifies the source from which
   that news server received the article, in a notation that can be
   interpreted by the news server admin. This notation can include any
   info the admin deems pertinent, such as the authorized and/or
   authenticated identity of the poster. In order to limit the exposure
   of personal data, it SHOULD be given in a form that can't be interpreted
   by other sites.

   The "sender" <parameter> identifies a mailbox that the news server
   believes can be used to reach the user posting the article. There is
   no implied relationship between the "sender" parameter and the "From"
   or "Sender" header fields of the article.

   It is a matter of local policy whether to include the "posting-account"
   <parameter>, the "<sender>" parameter, both, or neither.

I'm skeptical myself about the "posting-account" hiding; real hiding would 
mean encryption with a server-specific key, and would have to add salt into 
the encryption to prevent matching posting-account between different 
messages, which would make it indistinguishable from "logging-data". 
Anything less than that is just protection against people who don't really 
want to attack you.

Thoughts?

                       Harald

---

From: Richard Clayton <[email-masked]>
Date: Mon, 20 Feb 2006 13:37:38 +0000

In message <[email-masked]>,
Harald Tveit Alvestrand <[email-masked]> writes

>  of personal data, it SHOULD be given in a form that can't be interpreted

Usenet is a public medium where people make public statements. If you
wish to have more privacy than hiding behind a cyberspace identifier
[and that is considerable] then you can purchase service from someone
who provides it.

viz: I don't see the reasoning for the SHOULD rather than MAY, but it is
reasonable to draw attention to the issue

I certainly agree with recasting the text as a privacy issue rather than
a "security" issue.

>  or "Sender" header fields of the article.

I don't think a news server can have beliefs... at least not in most
major religions :(

>  <parameter>, the "<sender>" parameter, both, or neither.

what you're really trying to say is that there can be two parameters
inserted -- one of which has the form of an email address that may or
may not work and the other of which has the form of values that can be
used to access account level authorisation...

... BUT only the "posting-account" will be of any use to the server
admin and the "sender" is essentially just a way of providing a constant
value that people can use in killfiles -- there's no way of anyone
ensuring that email will actually reach anyone :(

>Anything less than that is just protection against people who don't really 

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Russ Allbery <[email-masked]>
Date: Mon, 20 Feb 2006 11:15:25 -0800

>   of personal data, it SHOULD be given in a form that can't be
>   interpreted by other sites.

>   <parameter>, the "<sender>" parameter, both, or neither.

I'm opposed to including that sort of sender parameter.  If the server
wants to put in a Sender header, it should just do that, not stick the
equivalent in some other header.

So to me, the only one that's potentially useful here is the
posting-account parameter, plus an additional authentication-identity
parameter to hold the other identity.  I have no problem with the above
description of the field.

> I'm skeptical myself about the "posting-account" hiding; real hiding
> would mean encryption with a server-specific key, and would have to add
> salt into the encryption to prevent matching posting-account between
> different messages, which would make it indistinguishable from
> "logging-data".

The solution to that problem is to remove logging-data, which is not
clearly specified and probably in practice indistinguishable from
Message-ID.

Whether to really hide the identity or to maintain enough consistency
between posts from the same account to allow automatic EMP recognition
(thereby risking some privacy by creating a persistant identifier) is, I
think, a choice for the local administrator.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 13:24:41 GMT

>equivalent in some other header.

Generally speaking, a Sender header is put there by the user agent, not
the injecting agent (indeed, USEPRO currently forbids altering any Sender
header already present).

There is indeed a case (I don't buy it myself) for omitting this
parameter, but this is a privacy issue and is best discussed in USEAGE
(see mt reply to Harald).

>description of the field.

Authentication-identity is either a special use of the posting-account
parameter, or it belongs in a distinct authentication-parameter of its own
(I mildly prefer the latter).

>clearly specified and probably in practice indistinguishable from

No, the essential difference with the logging-parameter is that it just
identifies an entry in the servers log-file. So it it totally opaque to
the outside world and gives you no clue to the identity of the poster
unless you can persuade the ISP concerned to divulge the information or to
TOS the guy itself. Trouble is, ISPs who are reluctant to divulge or TOS
tend to attract the Bad Guys :-( .

>think, a choice for the local administrator.

The essence of the posting-parameter (as opposed to the logging-parameter)
is that such consistency would exist. The choice is indeed a matter of
local policy, but USEAGE is the place to discuss it in detail.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 13:10:46 GMT

>   administrator of the news server.

Yes, the word "cryptic" there was a bit misleading (mea culpa), carrying
overtones of cloak-and-dagger stuff :-( .

>   of personal data, it SHOULD be given in a form that can't be interpreted

Yes, that is better, but not quite there. The essential property is that a
given source will still lead to the same posting-account (so you can
killfile on it). So something like:

   The "posting-account" <parameter> identifies the source from which that
   news server received the article, in a notation convenient to the news
   server admin (and possibly related to some authorized and/or
   authenticated identity of the poster [Refer to SASL]), but not one
   that identifies the poster directly.

Observe that I have removed the "SHOULD", as suggested by Richard.

>   or "Sender" header fields of the article.

   The "sender" <parameter> identifies a mailbox that can be used to reach
   the poster of the article (which may or may not be the same as in the
   "From" or "Sender" header fields of the article).

And a bit more wording if we retain the "verified" form of this parameter.

>   <parameter>, the "<sender>" parameter, both, or neither.

Whilst it is right and proper to mention local policy and privacy here,
this applies to ALL the available parameters on this header, and not just
to these two. Moreover, it was agreeds long ago that detailed discussion
of this belonged in USEAGE, so all that is needed here is to say that
choice of parameters to include is a matter of local policy, but that it
has privacy implications which are addressed in more detail in USEAGE.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 23 Feb 2006 10:22:54 -0800

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

> the injecting agent (indeed, USEPRO currently forbids altering any
> Sender header already present).

Right, because you reject articles with headers you don't like rather than
altering them.  That doesn't change the overall point.

> (see mt reply to Harald).

Yes, but I'm not talking about that.

I realize that Sender is slightly ambiguous in practice, but the
information is also near-worthless, so I don't see why we care.  If a
particular site wants to use that header, they should go right ahead.
I'm not seeing the benefit gained by introducing yet another version of
it.

> unless you can persuade the ISP concerned to divulge the information or
> to TOS the guy itself. Trouble is, ISPs who are reluctant to divulge or
> TOS tend to attract the Bad Guys :-( .

I'm still failing to see the difference from Message-ID.

I don't suppose it really hurts anything, but it does strike me as rather
redundant.  Wouldn't it be better to encourage sites to be able to find
logs of messages by message ID, which is far more likely to be available
in practice?

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 19:19:01 +0100

Charles Lindsey wrote:

> a Sender header is put there by the user agent, not the
> injecting agent (indeed, USEPRO currently forbids altering
> any Sender header already present).

ACK, this isn't 2476bis option 8.1 or an experimental SenderID,
it's NetNews.

> There is indeed a case (I don't buy it myself) for omitting
> this parameter, but this is a privacy issue

I buy it.  Servers wishing to enforce a simple kind of "PRA"
(SenderID's "purportable responsible address") are free to do
it by rejecting articles they don't like.

If we kill the "sender"-parameter we also need no convoluted
explanation of its differences from "posting-account".  Just
saying that the latter is optional is fine, admins will know
what to do with it if they want it, "cryptic" or not.

                           Bye, Frank

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 23 Feb 2006 17:08:25 -0500

Frank Ellermann wrote:

> Russ Allbery wrote:
> Some sites like news.t-online.de have (or had) a X-Trace.
> Encoded in later versions.  They could determine the IP
> and maybe more from it, with that info they could find
> who posted, and then send a warning or TOS or what else.
> 
> Simplified, could be wrong, and I don't know the details.
> What they didn't have was a database of Message-IDs to
> users.  It's a huge ISP, and a big server, just using
> what works everywhere for them in X-Trace (encrypted) 
> was probably the smart thing.  <shrug />

Shrug?  That site is saying....

"I can't waste 100 bytes per message on my local logs
so I'll waste 100 bytes of SPOOL ON EVERY SITE that stores
articles injected here.  Oh, if you want me to store your
X-Trace headers for you, I guess so...."

Forgive me if I am not sympathetic to lusers[*] who actually
believe they eat free lunches.

Forrest

* - Real word alert: Sometimes admins are lusers too.  They
aren't too hard to spot on Usenet, in fact.  Technology hasn't
solved social problems, doncha know.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 23 Feb 2006 13:53:27 -0800

> Some sites like news.t-online.de have (or had) a X-Trace.  Encoded in
> later versions.  They could determine the IP and maybe more from it,
> with that info they could find who posted, and then send a warning or
> TOS or what else.

Oh, is this supposed to be the replacement for NNTP-Posting-Host
specifically?  Hm.  I'd be more inclined to put that into posting-account;
I'd rather put all of the identifying information in one place so that I
can encrypt it only once and not have to deal with multiple parameters.

> Simplified, could be wrong, and I don't know the details.  What they
> didn't have was a database of Message-IDs to users.  It's a huge ISP,
> and a big server, just using what works everywhere for them in X-Trace
> (encrypted) was probably the smart thing.  <shrug />

Yeah, but that sort of thing I was expecting to see in posting-account.
The description of logging-data is specifically "here's some cookie that
the site can look up in their logs," which message ID can already do.

> Apparently not there, they had some privacy trouble with the unencoded
> X-Trace, they wouldn't stick to it if it's redundant.

You're rather optimistic there.  :)

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 22:27:57 +0100

> it does strike me as rather redundant.  Wouldn't it
> be better to encourage sites to be able to find logs
> of messages by message ID, which is far more likely
> to be available in practice?

Apparently not there, they had some privacy trouble
with the unencoded X-Trace, they wouldn't stick to it
if it's redundant.  Maybe they just don't have a log
"Message-ID -> user".  This log would automatically
attract the attention of their privacy officer.  

We have privacy laws over here, companies MUST have
a privacy officer, and they MUST avoid to collect 
personal data whereever it's not required.  A kind
of "SHOULD NOT generate" for sensitive data, with a
good excuse it's of course possible.

                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 23:48:54 +0100

> You're rather optimistic there.  :)

Yes.  Generally I liked their server, about 2002..2004.

The unencoded format was a pain, it included a variant
of the account number, and everybody and his dog knew
how to derive a working mail address from it, or an URL
of user home pages, each with an auto-generated subpage
containing the real name and address...

...well, they were forced to encrypt this later.  Bye

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Feb 2006 10:39:44 GMT

>> users.

I don't think we can assume that servers will all be willing to index
their logs by Message-ID (sensible though that idea might be). It is an
implementation detail, and our standard cannot make assumptions about
implementation details.

>>  It's a huge ISP, and a big server, just using

>X-Trace headers for you, I guess so...."

Again, it may not be the most Usenet-friendly technique, but we can't
really stop servers doing it that way if they so choose. An implementation
detail, again.

Essentially, what I am saying is that if the same source of the article
produces (essentially) the same text for the parameter, then it is a
posting account, but if it produces a string of gibberish, different every
time (whether it is an index into the ISP's log, or an encryption of the
whole log entry), then it is a logging parameter.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Feb 2006 11:31:17 GMT

>specifically?

I think it was meant to be a replacement for *everything*.

>  Hm.  I'd be more inclined to put that into posting-account;

It might well be that the more paranoid ISPs would put everything into the
logging parameter, and have no other parameters. That would be allowable
under the rules as written, but not overly helpful to the rest of the
community.