Draft specification for future X-Trace header

[Russ Allbery]

Marco d'Itri <md at linux.it> writes:
> On Jul 06, Olaf Titz <olaf at bigred.inka.de> wrote:

>> I don't. If I, at my gateway, insert the original MID at a point likely
>> to survive further gating, then I can compare the message against the
>> known ID when it loops back to my site. The only expectation here is
>> that the new header goes through the gateways unmolested

> Now I understand. But I think loop detection should not be an hack on
> top of X-Trace, just invent a new header (like the X-Gateway header used
> by FTN gateways).

I'm with Marco on this one; I don't see a lot of value added by putting
this into the X-Trace semantics.  A lot of people are already using
X-Gateway or something similar, and you really only need to be able to
recognize your own headers; it's not particularly important for most loop
detection to be able to recognize other people's.  (Generally, either you
don't want to recognize them or by the time you recognize them it's too
late and you've already looped at least once.)

> It's not, because you can start from the last Received header and trace
> the path of the message until you find the forged one. You can't do that
> with X-Trace becase the order of headers is undefined.

And since you're dealing with systems using POST, news systems tend to
rearrange the headers quite arbitrarily on a POST.  INN is guilty of this.

> Right now I'm concerned with abuse reporting.

Yeah, I really don't see much utility in multiple X-Trace headers.  If
you're a large enough site to have a hard time tracking down the origin of
a single post without having X-Trace information, you're certainly large
enough to get a peering connection rather than feeding your outgoing news
via POST.  If you're a small individual site, you don't need to generate
your own X-Trace headers in the first place.

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