Subject: Path header delimiters

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 9 Apr 2005 21:06:31 GMT

Our Chair has ruled that this matter it still open, so here is a summary
of where I think we are at.

Many years ago, when this WG was first formed, we were concerned that
malefactors regularly preloaded the Path header with all sorts of sites
(usually culled for some other article), in an attempt to disguise the
point at which it had been injected. We therefore proposed to modify the
Path header so that relaying agents would be able to make the following
assertions when they add a new path-identity to the Path-header:

#1  I am the injecting site.
#2  I have checked the identity of the previous site, and I believe the
    path-identity inserted by that site to be correct.
#3 I have checked the identity of the previous site, and I do not believe
    the path-identity claimed by that site; here is what I believe to be
    the true identity of that site.
#4  I have made no checks on the identity of the previous site.

The Path header is to News as the sequence of Received headers is to
Email, and Received headers currently convey much the same information,
and very useful they are when trying to trace the origin of some spam or
other malefaction. I think we are still agreed that such a feature in the
Path header is desirable - the point at issue is how to convey this
information in a backwards compatible manner.

The original suggestion was to introduce the delimiters '%', '/', and '?'
in addition to the usual '!', it being apparently the case that RFC 1036
already allowed all these characters, and many more, to be used as
delimiters, and it appeared that existing implementations did indeed
accept them. However, RFC 1036 is somewhat vague on exactly what the
allowed set of characters was.

A few months ago, Bruce Lilly pointed out that maybe some implementations
were not so accomodating, and pointed to the implementation of BNews
(written by the author of RFC 1036) which actually accepted a rather small
set. Following from that, various alternative schemes were proposed, as
follows.

In the following running example
    injector.com always uses #1
    new-site.com always uses #2 or #3
    good-site.com always uses #2 or #3
    old-site always uses #4
    dodgy.com was a bogus identity actually inserted by mallet.com

A. Current draft:
-----------------
 
Uses '%' for #1, '/' for #2, '?' for #3 amd '!' for #4
 
Path: good-site.com/mallet.com?dodgy.com!old-site.com!
      new-site.com/injector.com%not-for-mail
 
B. Henry's proposal <http://www.landfield.com/2004/Jul/0236.html>:
------------------------------------------------------------------
 
Uses '@' for #1, ',' for #2, ' ' for #3 amd '!' for #4, since it is clear
from RFC 1036 that all of those are intended to be usable as delimiters.
 
Path: good-site.com,mallet.com dodgy.com!old-site.com!
      new-site.com,injector.com@not-for-mail
 
Observe that the ' ' delimiter turns up rather conveniently as a separator
between the correct and bogus identities of mallet.com. One would need to
discuss whether FWS as well as SP should delimit this case.
 
C. The Diablo scheme
--------------------
 
I still have not been able to find documentation on this, but from
observed instances it appears to work as follows:
 
Path: good-site.com!mallet.com.MISMATCH!dodgy.com!old-site.com!
      new-site.com!injector.com.POSTED!not-for-mail
 
I see 2 problems with this one:
 
1: Any site which peers with injector.com (e.g. new-site.com) would
normally scan the received Path for occurrences of "injector.com", and
would send the article back to injector.com if it was not found (which, of
course, it isn't here because it recorded itself as "injector.com.POSTED").
 
2: It provides no distinction betwen cases #2 and #4, which rather defeats
the object of the whole exercise.

D. Another possible scheme
--------------------------

If you want to avoid all delimiters other than '!', and to overcome the
problems with the Diablo scheme, then here is one which relies on special
keywords "M", "MISMATCH" and "POSTED" in places where the current syntax
would expect a path-identity.

Path: good-site.com!M!mallet.com!MISMATCH!dodgy.com!old-site.com!
      new-site.com!M!injector.com!POSTED!not-for-mail

It makes the Path a little longer, but not unacceptably so, and assumes
that those keywords will never represent real sites.

E. A variant on scheme D
------------------------

Instead of the keyword 'M' to indicate case #2, just place two '#'
delimiters in succession, giving:

Path: good-site.com!!mallet.com!MISMATCH!dodgy.com!old-site.com!
      new-site.com!!injector.com!POSTED!not-for-mail

This avoids any delimiter other than '!', but it assumes that two
delimiters in succession will not cause any trouble. But it is clear that
RFC 1036 permits such usage, because it uses two delimiters in succession
in some of its own examples.

My own view is that we should adopt scheme E. It is much easier to
recognize what is meant, rather than having to remember exactly what '%',
'/', and '?' mean. In the discussion since I posted that last list of
outstanding issues, Frank Ellerman agreed that we should go with this
scheme (having carefully examined those examples in RFC 1036), and nobody
suggested anything different. So that scheme is the front runner at the
moment. I could easily propose modifications to the existing texts to
incorporate that scheme, but I don't want to embark on that unless we are
agreed it is the way to go.

So does anyone else want to comment, and can I assume that, if there are
no objections, we go with scheme E? 

-- 
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: Henry Spencer <[email-masked]>
Date: Mon, 11 Apr 2005 11:51:13 -0400 (EDT)

On Sat, 9 Apr 2005, Charles Lindsey wrote:
> RFC 1036 permits such usage...

This sounds good to me.

The one slight amendment I would suggest would be to use "AKA" -- Also
Known As -- instead of MISMATCH, making it a bit clearer just what's going
on.  (I struggled to find a concise way of writing "claimed to be", which
is the underlying idea, and this was the best I could think of.)  I support 
scheme E even if this suggestion is not accepted. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Apr 2005 20:56:47 +0200

Henry Spencer wrote:
 
> I would suggest would be to use "AKA" -- Also Known As --
> instead of MISMATCH

Two problems:  MISMATCH is already "common practice", and we
hope that no UUCP host MISMATCH existed, and that no TLD with
this name will be introduced.  For "AKA" I'm less sure, funny
host names are AI, IO, PH, PN, TM, and TW - in theory these
hosts could be news servers. 
                               Bye, Frank

---

From: Henry Spencer <[email-masked]>
Date: Mon, 11 Apr 2005 15:09:32 -0400 (EDT)

On Mon, 11 Apr 2005, Frank Ellermann wrote:
> Two problems:  MISMATCH is already "common practice"...

As a standalone item in the path content?  I think not.  There is some
vaguely-related existing practice of appending it to server names, which
might be considered a minor point in its favor.

> and we
> this name will be introduced.  For "AKA" I'm less sure...

We can quite reasonably have the same hopes for AKA.  Remember also that
it doesn't greatly matter whether AKA is potentially a valid server name,
because such a server can be known by a nickname (e.g. "news.aka") for
news purposes.  This would be a nuisance for its proprietors, yes, but not
a problem for the net as a whole. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Apr 2005 21:58:39 +0200

Henry Spencer wrote:

 [MISMATCH] 
> As a standalone item in the path content?  I think not.

Probably I was wrong, a quick check confirmed your version
".MISMATCH" added to the host name, not "!MISMATCH".

> This would be a nuisance for its proprietors, yes, but not

Also true, the former host TV apparently found a better name.
A potential host AKA after the introduction of TLD AKA could
also do this as news server.  Besides ...!news.aka!AKA!...
would be fun.

More fun:  Any news about publishing s-o-1036 as RfC 4036 ?
It's apparently not yet in the RfC editor queue.

Less fun:  Charles and I need a volunteer for some kind of
"rough consensus" about the names (sic!) of some msg-id ABNF
productions, could you please toss a coin or add a comment ?

                       Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Apr 2005 11:36:53 GMT

>might be considered a minor point in its favor.

You are damning it with faint praise :-) .

Actually, I think I prefer MISMATCH, not only because it is close to some
existing practice, but also because it is a conspicuous word that will
shout out at you "there is something fishy about this Path" whenever you see
it.

Anyway, it a minor detail as regards scheme E, which seems to be gaining
added consenus. Does anyone else want to play?

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 12 Apr 2005 12:59:52 -0400 (EDT)

> Anyway, it a minor detail as regards scheme E, which seems to be
> gaining added consenus. Does anyone else want to play?

Sure.  consensus++

Seth

---

From: Russ Allbery <[email-masked]>
Date: Tue, 12 Apr 2005 12:04:04 -0700

> added consenus. Does anyone else want to play?

Giving semantic meaning to a doubled delimiter makes me nervous, just
because that's something one generally doesn't do in protocols of this
type.  But that's just a vague, untargetted concern and I can't think of
concrete problems that it would solve.

It's the best solution I've seen so far, so I'm happy to go with it unless
someone comes up with something better.  I do think that this is an
important problem for us to solve.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Apr 2005 15:24:17 GMT

>important problem for us to solve.

OK, that makes it quite a smooth consensus compared to some we have had :-) .

I shall write some text to incorporate it next week (no time at the moment
- visiting grandchildren and a daughter getting married at the weekend).

---

From: Henry Spencer <[email-masked]>
Date: Mon, 18 Apr 2005 00:03:51 -0400 (EDT)

> More fun:  Any news about publishing s-o-1036 as RfC 4036 ?

Despite good intentions, I've been distracted and haven't gotten to the
point of making a submission.  Early next month, I hope.  (No chance
between now and then, too much to do.)

> productions, could you please toss a coin or add a comment ?

I've been hoping that stuff would sort itself out, because I haven't
been paying enough attention to have an opinion on it.

                                                          Henry Spencer
                                                       [email-masked]