Draft specification for future X-Trace header

[Russ Allbery]

Olaf Titz <olaf at bigred.inka.de> writes:

> 1. Purpose

> Any news system which an article crosses MAY insert an X-Trace header.

As mentioned elsewhere, I don't think we should encourage multiple
instances of the header.  I think it makes more sense to say that the last
injector wins.

> 2. Syntax

> header          = "X-Trace:" LWSP systemid *(LWSP item)
> systemid        = domain-name
> item            = ctoken | ntoken | comment
> ctoken          = ":" data
> ntoken          = data
> data            = (any data in base64 encoding)
> comment         = "(" *pchar ")"
> pchar           = (any printable character except "(" and ")")
> LWSP            = linear-white-space

> with the following meanings:
> systemid        = the hostname of the generating system. This MUST be the
>                   same name the system puts in the Path header.
> ctoken          = Data item which is suitable to compare against the ctoken
>                   parts of other X-Trace headers generated by the same
>                   system to detect multiple postings.
> ntoken          = any other data, usually only relevant to the local admin.
> comment         = readable comment.

Bleh.  I have to admit that this is pretty ugly, and I just know that the
first thing that Brad would say if he saw this is "why don't you just use
MIME named parameters?"  And he's got a point.

In other words, why not:

    X-Trace: g212.hadiko.de poster="7F0quBAr148=" trace="riniJg54iM4="

Then you don't need the colon to distinguish.  It's a bit more trouble to
parse, but it's also more general.

> For local postings, the injection point SHOULD generate a /ctoken/ which
> is the same for all postings of one user over a certain period of time
> (recommendation: about one day) and always different for postings by
> different users. To prevent privacy problems, this token SHOULD be
> encrypted or hashed.

Why should it only last for a day?  I know that my spam filters stop the
same spammer for a lot longer than that, sometimes (particularly for the
jobs spammers).

> 3.2. Mailinglist to news gateways

As mentioned elsehwere, I don't think this is all that useful.

> 3.3. Posting robots

> Bulk postings by legitimate robots (e.g. weather reports, NoCeM notices)
> SHOULD generate no /ctoken/ at all, to exempt these posters from
> rate-limiting done by comparing /ctoken/ values. Additional information
> MAY be encoded into /ntoken/ items.

This, on the other hand, is a pretty good idea.  I like this.

> 5. Other headers

> The header presented here includes the information present in the
> existing INN-type X-Trace header, the NNTP-Posting-Host and (possibly)
> NNTP-Posting-Date headers, the X-Complaint-To header (as comment) and
> the "<address>.POSTED" Path entries. Generation of these items may
> therefore be omitted.

It can't really replace the X-Complaints-To header when that information
is only in a comment, since comments can't be automatically parsed.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>