Draft specification for future X-Trace header
rra at stanford.edu
Wed Jul 12 08:06:23 UTC 2000
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
> 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
> 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/>
More information about the inn-workers