Subject: Re: #1047 permitted constructs - a list

From: Richard Clayton <[email-masked]>
Date: Wed, 1 Feb 2006 09:15:42 +0000

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>
>Richard Clayton wrote:
> 
>> systems will still create tails like
> 
>>         !highwayman.com!richard
> 
>> since that was the way you could write back to
>> [email-masked]
>
>Yes.  But it's a case of "no news is bad news" for any system
>styling itself with <path-legacy> name "richard". 

there is no such system (trivial to check by inspection) and the wording
that was agreed means that there will be no such systems in the future

> Can we now
>please stop to pretend that all legacy names are completely
>harmless ?

this one is

>> There's no need for a SHOULD here (making existing working
>> clients only "conditionally compliant") merely for specious
>> tidyness.
>
>IBTD, as Russ explained it a "local part" news.clara.net would
>be a horrible idea, and users need to know that it's horrible.

provided that the injection agent adds "POSTED" then there will be a
separation between the part of the Path: that is being used to improve
the efficiency of the flood-fill algorithm and the part of the Path:
that provides some traceability beyond the injection agent machine

>> Usenet works really well with people putting email local
>> parts at the end of Paths ... they don't in practice clash
>> with either UUCP names or machine/domain names -- leastwise
>> if they do, no-one notices
>
>Exactly the latter is the problem:  noone notices.

perhaps because it never happens ?

>  If they'd
>do it _intentionally_ to exclude news.clara.net let them play.
>
>But if they don't know what they are doing it's a trap.  It's
>the purpose of a standard to prevent foreseeable harm as far as
>possible, and "SHOULD NOT use <tail-local>, or where required
>use a dummy not-for-mail" could help.  

I don't think the injection agent is in a position to understand the
traceability information in the Path: part of an article that is given
to it -- and therefore it should not be messing around with it because
it will discard potentially useful information [the owner of
highwayman.com may be in a position to lart "richard" rather than "fred"
by examining the tail]

The injection agent can prevent harm by adding POSTED (so there is value
in doing that -- and you'll have noted that I haven't spoken against
that construct).

- -- 
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: Seth Breidbart <[email-masked]>
Date: Wed, 1 Feb 2006 13:17:59 -0500 (EST)

>>please stop to pretend that all legacy names are completely

There are people with username 'demon'.

Seth

---

From: Richard Clayton <[email-masked]>
Date: Wed, 1 Feb 2006 18:37:04 +0000

In message <[email-masked]>, Seth Breidbart
<[email-masked]> writes
>There are people with username 'demon'.

Then, almost two decades later, I will finally be able to read their
pearls of wisdom on Usenet.... just as soon as there is one path between
their machine and Demon Internet's which stops scanning the Path: header
field when the POSTED text is reached.

I look forward to it :)

- -- 
richard                                                   Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Feb 2006 12:55:00 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Not exactly related rant:  This path-issue puzzles me.  A Path
>is almost as essential as Message-ID, Newsgroups, and Control
>for NetNews.  What did the earlier incarnations of this WG do,
>if some of these essential UseNet concepts still aren't clear ?

The earlier incarnations of this WG were quite clear about the concept of
the <tail-entry>, right up to the moment yesterday when Russ dropped his
bombshell and told us that INN did not do what everyone else had assumed
up to then.

-- 
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, 2 Feb 2006 12:50:25 GMT

In <[email-masked]> Russ Allbery <[email-masked]> writes:

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

>> My understanding is that existing practice is for relayers to ignore
>> whatever comes after the last "!" (typically "not-for-mail") when
>> deciding whether not to send the article back to some site listed in the
>> Path. The reason being, of course, that historically that last entry
>> respresented a person rather than a site (still does, sometimes).

>INN certainly doesn't do this.  I don't know what other servers you may
>have been looking at to judge existing practice.

Well that is what Son-of-1036 tells you to do (and hence, not
surprisingly, what CNews does). And it is what our drafts have said for
the last nine years or so, and so I am amazed that nobody has nemtioned in
all that time that INN in fact did not do it.

<bareword>s as <path-identity>s are tricky things, and admins who want to
use them need to do "due diligence" (e.g. by examining lots of existing
Paths) to be reasonably sure they are unique. USPERO contains suitable
dire warnings against such perils, but the practice of using them is
widespread and is unlikely to go away.

However, senders are much less likely to use "due diligence" when choosing
their names, and if a sender decides to call himself "demon" and to
preload that into the tail of his Path, then there is not much we can do
about it except to say that <tail-entry>s MUST NOT be inspected by
relayers. In which case it would be better for INN to implement that.

The converse problem, where the last thing in the Path is actually a
site-name is, so you say, rare. Moreover, a relayer failing to look at it
will, at worst, send an article to a site which already has it. So the
safe solution is for the <tail-entry> always to be ignored, as our drafts
have always said.

>>> path-list       = 1*( path-identity [FWS] path-separator )
>>> path-separator  = [ path-diagnostic ] "!"

>>     Path: news.site4.exmaple!news.site3.exmaple!news.site2.example
>>           !news.site1.example!not-for-mail

>> rather than splitting the line _after_ a "!" at the end of the previous
>> line. On the basis of that, I have always tried to make my syntax that
>> way round, and resisted Frank's attempts to make it the other way.

>Yes, that's what the above does.  That's the whole point of the change.

Aaaaarrrrrgggggghhhhhhhh! That is ugly!.

1. We could have a rule that [FWS] was allowed before ANY "!" (or "!!").
2. Or we could have a rule that [FWS] was allowed after ANY "!" (or "!!").
3. Or we could have a rule which allowed both.

Morover, that would be consistent with folding conventions for other
headers that consist of comma- or WSP-separated lists.

But to say that [FWS] is only allowed in a place that is not even next to
a separator at all is bizarre. Moreover, splitting a <path-identity> and
its following <diagnostic> (if any) onto separate lines seems contrary to
all good sense, since they logically belong together.

And what is gained by making such a rule? We only got into this argument
because Frank claimed, wrongly, that the ABNF could not be written to
allow option #1 above. Nonsense. It is easily done.

The casual observer is just going to see a stream of "chunks" separated by
"!"s, and would be most surprised to learn that folding is not allowed at
_any_ "!".

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Feb 2006 13:06:02 GMT

>I look forward to it :)

Yes, but it has never been suggested that relayers are expected to detect
that ".POSTED" and stop reading the Path at that point. Current ones don't,
and I guess that detecting ".POSTED" would eat up more cpu cycles than
just carrying on to the end (this code is in a time-critical part of any
relayer).

Moreover, there are specialized things that come _after_ the .POSTED that
relayers may need to be interested in, such as "cybercancel". So the only
safe thing is to stop looking when you find an item that has no "!" after
it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Feb 2006 12:17:04 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:
> 
>>> tail-entry       = path-identity [ "!" tail-local ]
>>> tail-local       = *( path-nodot "." ) path-nodot

>Right or wrong, it's strict 1036, and Russ said that paths
>without local-part at the end are common practice.  If that
>works somehow today, it will continue to work tomorrow.

That most certainly is NOT strict 1036.

1036 actually contradicts itself (no surprise there) by saying that the
thing after the last separator ("!") might be the name of a site or it
might be the name of the sender, and there is absolutely no way to tell
which. That is a problem which Son-of-1036 tried to fix.

But NO-WAY does 1036 allow a "!" inside of the name of anything (it would
plainly be ambiguous), so how come your syntax above is trying to allow a
"!" inside the <tail-entry> (which is, by definition, the thing that comes
_after_ the last "!"). Your syntax makes no sense at all.

Moreover, Russ did not say that "paths without local-part at the end are
common practice". He actually said (or has said now) that they are a most
UNcommon practice (in spite of 1036).  Moreover, since a relayer that
ignores a genuine <path-identity> creates only marginal harm, it would be
safer to ignore that uncommon practice than to run the risk that the
sender's name in a <tail-entry> might match something.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Feb 2006 13:06:02 GMT

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Feb 2006 12:17:04 GMT

---

From: Richard Clayton <[email-masked]>
Date: Thu, 2 Feb 2006 17:31:18 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>that ".POSTED" and stop reading the Path at that point.

If you don't suggest that, then so far as I can see, the feature has
zero purpose whatsoever and I withdraw any support for it.

> Current ones don't,

Well indeed -- it's a new feature.

Of course if we stopped trying to create new features we'd be done
quicker.  However, this one did seem to have a small amount of merit

    unlike the traceability stuff where we're only pressing on because
    of Russ's observation that people kept re-inventing the feature and
    doing it badly -- so there's some limited sense in at least trying
    to do it once and for all [and right] : not because it will be
    useful very often, but because it will prevent further re-inventions
    and hence reduce the risk of future damage

>just carrying on to the end (this code is in a time-critical part of any

not if you code it right ! [and note that the leading "." makes it easy
to feed into a separate path]

>relayers may need to be interested in, such as "cybercancel". 

If it was me issuing the cybercancels, I'd do a deal with my local
injector not to put in a .POSTED entry at all :)

However, if it's felt that people have to look at all of the items on
the path (which would include people's names, the names of their own
machines and a whole lot of other crud put there by their posting agents
then I suddenly stop seeing the point of POSTED).

The X-Trace header line (whatever that's now called) tells you which
machine did the injection. There's no value I can see in putting it
somewhere else as well. If there is such a value, then could you remind
us what it is?

>So the only

or as we programmers call it, "end of line"

- -- 
richard                                                   Richard Clayton

---

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

Charles Lindsey <[email-masked]> writes:

> UNcommon practice (in spite of 1036).

That's more emphasis than I think I used.

> Moreover, since a relayer that ignores a genuine <path-identity> creates
> only marginal harm, it would be safer to ignore that uncommon practice
> than to run the risk that the sender's name in a <tail-entry> might
> match something.

If people want to require a non-site tail entry, I have no particular
objections to that, but I do think that it's at least worth a warning that
not all existing software is going to parse the Path that way.

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

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Feb 2006 10:30:34 -0800

Charles Lindsey <[email-masked]> writes:

> the last nine years or so, and so I am amazed that nobody has nemtioned
> in all that time that INN in fact did not do it.

Yeah, it says something, doesn't it?

> However, senders are much less likely to use "due diligence" when
> choosing their names, and if a sender decides to call himself "demon"
> and to preload that into the tail of his Path, then there is not much we
> can do about it except to say that <tail-entry>s MUST NOT be inspected
> by relayers. In which case it would be better for INN to implement that.

This is all find and grand and all, and I don't even really disagree
(although I have even less time to work on INN than I had a year ago), but
there's a lot of existing software out there.  Again, can I strongly
recommend against assuming that anyone writing news software has even
*heard* of Son-of-1036, let alone implemented it?

> Aaaaarrrrrgggggghhhhhhhh! That is ugly!.

I sort of liked it.

> a separator at all is bizarre.

That isn't what it says.  I think you need to look at the grammar in
context again.  It says that if you have a Path diagnostic, you have to
keep it together with the site that it's diagnosing, and otherwise you can
split before any path separator.

Now, I can see the argument that we should also allow [FWS] between a
!.SEEN diagnostic and the Path entry from that site, in case both are
fairly long, but shoehorning that into the ABNF is a bit beyond me this
morning.

> Moreover, splitting a <path-identity> and its following <diagnostic> (if
> any) onto separate lines seems contrary to all good sense, since they
> logically belong together.

I was under the impression that diagnostics come *before* their
corresponding path-identities, not after.  Please remember, ABNF is not a
specification for how to construct the Path, just a specification for how
it should look; don't draw conclusions from what's grouped in the ABNF.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Feb 2006 10:34:14 -0800

Charles Lindsey <[email-masked]> writes:
> Frank Ellermann <[email-masked]> writes:

>> Not exactly related rant:  This path-issue puzzles me.  A Path is
>> almost as essential as Message-ID, Newsgroups, and Control for NetNews.
>> What did the earlier incarnations of this WG do, if some of these
>> essential UseNet concepts still aren't clear ?

> The earlier incarnations of this WG were quite clear about the concept
> of the <tail-entry>, right up to the moment yesterday when Russ dropped
> his bombshell and told us that INN did not do what everyone else had
> assumed up to then.

The key word being "assumed."  That assumption was buried deep enough into
the discussions that I didn't notice it until the other day.  When I
noticed it, I thought "that doesn't sound right" and went and checked.

If you want me to go check something like that, you've got to either bring
the assumption prominently to my attention or (ideally) ask.  Also, I'm
human and sometimes I miss things (like large portions of the Path
discussion, which has for years been so far off in the weeds that I've
largely ignored it).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Feb 2006 00:10:59 +0100

Richard Clayton wrote:

>> it has never been suggested that relayers are expected to
>> detect that ".POSTED" and stop reading the Path at that
>> point.
 
> If you don't suggest that, then so far as I can see, the
> feature has zero purpose whatsoever and I withdraw any
> support for it.

+1
 
> there's some limited sense in at least trying to do it once
> and for all [and right] : not because it will be useful very
> often, but because it will prevent further re-inventions and
> hence reduce the risk of future damage

With now up to four kinds of POSTED, naked, combined with SEEN,
combined with MATCH, and combined with MISMATCH, and Harald
asking for "votes" about a list of keywords in USEPRO I "vote"
to get rid of that crap, no <diag> at all, copy either 1036 or
s-o-1036 - permissible <tail-entry> vs. mandatory <tail-entry>.

> The X-Trace header line (whatever that's now called) tells
> you which machine did the injection. There's no value I can
> see in putting it somewhere else as well.

+1

>> the only >safe thing is to stop looking when you find an
>> item that has no "!" after it.
 
> or as we programmers call it, "end of line"

End of header field:  "end of line" doesn't work with optional
folding _before_ "!".  The consequence of putting this "comma"
at the begin of the next line (instead of at the end of line).

                              Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Feb 2006 00:48:41 +0100

Russ Allbery wrote:

> sometimes I miss things

I certainly missed or never noted that this is a critical
difference between s-o-1036 and 1036.  Checking it again,
even RfC 850, the predecessor of 1036, had this:

| Normally, the rightmost name  will  be  the  name  of  the
| originating  system.   However,  it is also permissible to
| include an extra entry on the right, which is the name  of
| the  sender.   This is for upward compatibility with older
| system.

RfC 850 was published 1983.  The "permissible" local part is
now an adult.  <sigh />
                             Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Feb 2006 01:30:42 +0100

path            =  "Path:" SP *WSP path-list path-poster *WSP CRLF
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-diagnostic =  diag-match / diag-mismatch / diag-seen / diag-obs

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."     diag-identity
diag-mismatch   =  "!.MISMATCH." diag-identity
diag-obs        =  "!" 1*( path-nodot "." ) path-nodot

diag-identity   =  path-identity / IPv4address / IPv6address

path-poster     =  path-identity [ "!" path-nodot ]

path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

label           =  alphanum [ *( alphanum / "-" ) alphanum ]
toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Feb 2006 11:58:45 GMT

>not all existing software is going to parse the Path that way.

Yes, I have made a Note to mention that in USEPRO.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Feb 2006 11:53:56 GMT

>>>field when the POSTED text is reached.

As a matter of interest, I have just posted an article with 'demon' at the
end of the Path to misc.test (message id <[email-masked]>).
It probably won't prove much, but it would be interesting to hear whether
it arrives at demon's servers, or whether any demon customers have
problems with it. As an afterthought, I have also included demon.service
and demon.test in the Newsgroups.

>> >>Yes, but it has never been suggested that relayers are expected to
detect >>that ".POSTED" and stop reading the Path at that point.

>zero purpose whatsoever and I withdraw any support for it.

Its primary intent was always to assist in the detection of malpractice,
and there is some existing usage of it for that purpose (but not with our
presently proposed notation).

If some implementor likes to use it to shorten his search of the Path,
then he is welcome to do so, but I don't think we can assume that all
implementors are going to do that.

>to feed into a separate path]

Yes, the leading "." would help. But the simplest algorithm is still to go
along the Path and every time you encounter a "!" you take the chunk of
stuff since the last "!" and see if it occurs in the relevant part of your
'sys' file.

>somewhere else as well. If there is such a value, then could you remind

It is possible (in rare cases of reinjection) for there to be two .POSTEDs
in the Path. The Injection-Info header, as currently defined, is SHOULD
include, rather than MUST. And it is simpler for someone looking for
malpractice to look for all the evidence in the one place.

---

From: Richard Clayton <[email-masked]>
Date: Fri, 3 Feb 2006 12:42:50 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>end of the Path to misc.test (message id <[email-masked]>).

you also appear to have cross-posted it to demon.service, which isn't a
test group :(

It's rather poorly designed as a test -- since you need to concentrate
on which peering arrangements actually use the !demon! tag :(

Hence it turned up just fine -- doubtless to confuse the denizens of
demon.service no end :(

   Newsgroups: misc.test,demon.service,demon.test
   Path: news.demon.co.uk!mutlu.news.demon.net!peer-uk.news.demon.net!ki
   bo.news.demon.net!aotearoa.belnet.be!news.belnet.be!news.germany.com!
   feeder.ecngs.de!ecngs!feeder2.ecngs.de!212.23.6.68.MISMATCH!zen.net.u
   k!hamilton.zen.co.uk!193.60.199.26.MISMATCH!feed4.jnfs.ja.net!jnfs.ja
   .net!peernews.mcc.ac.uk!news.mcc.ac.uk!clerew!demon
   From:  "Charles Lindsey" <[email-masked]>
   Subject: Path <tail-entry> test
   Message-ID: <[email-masked]>
   X-Newsreader: NN version 6.5.2 (NOV)
   Date: Fri, 3 Feb 2006 11:21:29 GMT
   Lines: 23
   Xref: news.demon.co.uk misc.test:301438 demon.service:41973
   demon.test:5167

etc

>Its primary intent was always to assist in the detection of malpractice,

then it will fail, just like the other schemes for such detection

>implementors are going to do that.

if this is added (and I'm rapidly failing to see that it is valuable)
then it is essential to prescribe its semantics!  saying "you might like
to use it" is just asking for trouble :(

>stuff since the last "!" and see if it occurs in the relevant part of your

you're changing emphasis. First you were discussing efficiency and now
you are discussing "the simplest algorithm". Sometimes the two things
align, but not always :(

>in the Path. 

and the value of this re-injection is what ??

>The Injection-Info header, as currently defined, is SHOULD
>include, rather than MUST. 

So do you envisage the POSTED being "MUST" or "SHOULD" ?

>And it is simpler for someone looking for

and that place is the logs of the machines through which the article
passed. No trust should be placed elsewhere :(

- -- 
richard                                                   Richard Clayton

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Feb 2006 12:23:27 GMT

>it should look; don't draw conclusions from what's grouped in the ABNF.

You can argue that the identity followed by the diagnostic is the
interesting pairing, since that is what is added by one site (and
presumably that site then decided that the line had now gotten long enough
for a further fold).

Or you can argue that the diagnostic and the following identity is the
interesting pairing, because those two refer to the same site (or not in
the case of a MISMATCH).

My view is to let the relaying implementor worry about it by allowing the
fold in either place.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Feb 2006 10:54:50 GMT

>on which peering arrangements actually use the !demon! tag :(

Wouldn't be the first time someone has misused demon.service :-( . I sent
it there in the hope that it might uncover a few cases where the !demon!
tag would be relevant, though I do not understand the particular
circumstances in which that tag can cause problems well enough to be sure.

>then it will fail, just like the other schemes for such detection

Hence the word "assist".

>you are discussing "the simplest algorithm". Sometimes the two things

Maybe. What I described is roughly what present implementations do AIUI.

>and the value of this re-injection is what ??

We discussed this 18 months or so ago, and it appeared that such
reinjection currently happens in occasional peculiar but justifiable
circumstances (such as complex pieces of gatewaying or some situations
where an article was injected at multiple sites), and that we therefore
needed to write our protocols to be resilient to it.

>So do you envisage the POSTED being "MUST" or "SHOULD" ?

AS USEPRO is currently written, it is MUST, but if anyone wants to review
that when we come to discuss USEPRO, then fine. In any case, even a MUST
will take time to be implemented widely enough to be relied upon.

>passed. No trust should be placed elsewhere :(

Sadly, few sites will divulge the contents of their logs to outside
enquirers, and is would appear that such unwillingness to divulge
correlates highly with the blackness of the site's hat :-( .

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 10:06:17 +0100

--On tirsdag, januar 31, 2006 15:11:46 +0100 Frank Ellermann 
<[email-masked]> wrote:

> 6 tail-entry       = path-identity [ "!" tail-local ]
> 7 tail-local       = *( path-nodot "." ) path-nodot

I think tail-local is syntactically indistinguishable from a path-identity. 
I don't think that's a problem (USENET has worked for a long time with it 
being indistinguishable), but we might want to point it out in prose.

Also - in the case of "demon" accepting a submission from user "joe", do we 
want the path to be

demon!.POSTED!joe
demon!.POSTED!joes-laptop!joe

or something different?

I don't think insisting that non-Usenet machines have valid and 
discoverable names that are path-identities and don't clash with the 
path-identity of a news-server is a Good Thing....

                    Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 16 Feb 2006 11:12:20 GMT

>or something different?

Either of those if fine and such examples are seen regularly. It is up to joe.

>path-identity of a news-server is a Good Thing....

If joe wants to cause mischief by using the identity of a well-known news
server, then there is no way we can stop him (though the presence of
.POSTED may make it harder for joe to do so in the future).

The actual utility of such examples is more likely to appear when there is
a substantial local network behind some firewall, with the .POSTED only
being added to those (publicly available) articles which emerge outside
the firewall.

I agree that the syntax of the tail-entry may as well be the same as the
syntax of a path-identity.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Feb 2006 11:54:51 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Tveit Alvestrand wrote:

>Yes, mostly.  Some cases of this <tail-local> won't match
>a <path-identity>.  In a later wannabe-improved proposal
>(see below) I simlified it to...

>| path-poster   =  path-identity [ "!" path-nodot ]

>| path-identity =  ( 1*( label "." ) toplabel ) / path-nodot
>| path-nodot    =  1*( alphanum / "-" / "_" )    ; legacy names

>...with <path-poster> as rightmost entry in the <path>,
>A new name to avoid any confusion with older <tail-entry>
>concepts.

Changing <tail-entry> to <path-poster> will not if itself achieve
anything. Either way, the syntax you have given is plain WRONG.

The <tail-entry> is BY DEFINITION what comes after the last "!", and
therefore it cannot possibly have a "!" in it. It is NOT and NEVER HAS
BEEN the whole of what was present at the time the article was offered to
the injector (and it cannot be so, because of the occasional possibility
of reinjection).

So anything to the left of the last "!" is always a <path-identity>, or
maybe a <diagnostic>, whether it was placed there before or after
injection. So that includes "joes-laptop".

>ACK, either we pick what INN and 1036 do (= "permissible"),
>or we pick what s-o-1036 and Usefor drafts proposed, i.e.
>"mandatory" with a conventional "not-for-ail".

No, INN does not do what 1036 prescribes because 1036 contradicts itself
and does not prescribe anything (or it prescribes both, or however else
you choose to describe the mess).

So I would be in favour of following s-o-1036, as our drafts have always
done, and hope that INN will conform in due course (though little actual
harm appears to have arisen from the present INN).

>Therefore I think we should get a poll / ticket / decision
>about this point, some kind of #1047-a maybe:  Stick to
>1036 or adopt s-o-1036 for the right end of the <path> ?

Please, no new tickets. This is part of #1047.

>At the moment I think that !.POSTED is at best hopeless,
>useless, redundant, a bad idea, and dead.  So I'd say...

On the contrary, of the diagnostics currently envisioned, I think .POSTED
is the one most likely to catch some Bad Guys (certainly it will catch more
than .MISMATCH). So leave it be. It causes no harm, and may even provide
for special treatment of the pre-injection part of the Path at some future
date (modulo reinjection niggles when there would be two of them). Richard
seems to envisage such usage, but it will be a long time before it is
widely enough implemented to be able to rely on its presence.

>1  demon!joes-laptop
>2  demon!joes-laptop!joe
>3  demon!joes-laptop!not-for-mail
>4  demon!added-by-demon-2-0-0-127-adsl.example!not-for-mail
>5  demon!added-by-demon-2-0-0-127-adsl.example

>...for the 1036 variant.  All five cases for an article
>posted at demon.  For the s-o-1036 variant just strike
>cases (1) and (5).

No need to strike any of them. Perhaps "joes-laptop" really is the guy's
name. Whatever, it just gets ignored by relayers in the s-o-1036 variant.

And the "added-by-demon" examples should really have started with a ".",
since their intent was evidently diagnostic.

>Cases (1) up to (3) are from a system styling itself as
>as joes-laptop.  Case (4) and (5) are a situation where
>demon makes up a tail entry based on reverse DNS.

No, they are NOT part of the <tail-entry>. As written, #4 will get
treated as a normal <path-identity>s by s-o-1036 systems (indeed by all
current systems).

>JFTR, "we" decided, right or wrong, that constructs...

>6  demon!127.0.0.2!not-for-mail
>7  demon!127.0.0.2

>...are formally "illegal".  IPv4 is no <path-identity>,
>it matches only <diag-obs> in my latest propsal.  With
>that (7) is a "syntax error", there's no <path-poster>.

#6 MUST be accepted (though maybe not generated - though I believe only
one major site currently inserts such things). I don't really care whether
#7 is legal or not. It is certainly not worth a single line of extra
syntax to force it one way or the other.

>In (6) "not-for-mail" matches <path-identity>, that's
>syntactically fine, but semantically of course crap.

>I don't think that this subtlety could cause harm, but
>we _could_ "legalize" the IPv4 case in <path-poster>:

>- path-poster   =  path-identity [ "!" path-nodot ]
>+ path-poster   =  diag-identity [ "!" path-nodot ]

><diag-identity> allows <path-identity> plus IPs.  Ugly
>like hell, for months we tried to limit <diag-identity>
>and especially IPv4 to <path-diagnostic>, and here it
>would pop again outside of <path-diagnostic>.  At least
>only in <path-poster> and not elsewhere in the <path>.

You are inventing problems where none exists. Your <diag-identity> IS a
<path-diagnostic>. If people want to use such things, they should put a
".SEEN" into it (anything else should just be legacy).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 02:14:25 +0100

> I don't think that's a problem (USENET has worked for a
> long time with it being indistinguishable), but we might
> want to point it out in prose.

The convention would help to avoid real legacy names like
"demon" instead of "not-for-mail".  I don't care what we
pick, you could put your hat on and toss a coin... <g>

If the outcome is "mandatory" the proposed syntax as shown
above is of course wrong.  This is a tricky part of #1047
with some consequences for the ABNF, the prose, and USEPRO.

1  demon!joes-laptop
2  demon!joes-laptop!joe

The ambiguity "is it <diah-obs> or <diag-identity> ?"
is clear for (7), only <diag-identity> works at the end
of a <path>.

For (6) it's really ambiguous as far as somebody thinks
that "not-for-mail" is a legacy name.

Maybe that question could be "#1047-a-a", do we want to
screw up your <path-diagnostic> plan for this IPv4 case ?

It's of course possible to tune this, so that at least
IPv6 is again strictly forbidden within <path-poster>.

The other open question could be a new "#1047-b", do we
want to get rid of !.POSTED

I'd say "yes", it's like the weird LTRU-stars, if there
is no progress for some time it was already screwed up.

For certain values of "some time", weeks in LTRU, years
here.  Last known state without a !.POSTED added below.

                        Bye, Frank

; ------------------------------------------------------------------#

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 23:37:00 +0100

Charles Lindsey wrote:

> Changing <tail-entry> to <path-poster> will not if itself
> achieve anything. 

Sure, I changed the name because it reflects what 1036 says:

| Normally, the rightmost name will be the name of the
| originating system.  However, it is also permissible to
| include an extra entry on the right, which is the name
| of the sender.  This is for upward compatibility with
| older systems.

Translated to:

> Either way, the syntax you have given is plain WRONG.

It's the 1036 prose in ABNF, interpreting "name of the sender"
as syntactically the same as "legacy name", i.e. <path-nodot>.

Of course it's "wrong" if you want s-o-1036 instead od 1036,
I've said this later in the quoted article:

# If the outcome is "mandatory" the proposed syntax as shown
# above is of course wrong.  This is a tricky part of #1047
# with some consequences for the ABNF, the prose, and USEPRO.

> The <tail-entry> is BY DEFINITION what comes after the last
> "!",

Yes, that's why I renamed it for the 1036 idea with another
definition, see above.

> So anything to the left of the last "!" is always a
> <path-identity>,

The left side of <path-poster> as shown _is_ a <path-identity>,
(or there's only a <path-identity> - different case)

> or maybe a <diagnostic>, whether it was placed there before
> or after injection. So that includes "joes-laptop".

A <path-poster> or <tail-entry> made up by the news server is
still a <path-poster> or <tail-entry>, not a diagnostic.  

The path cannot end with ....!.SEEN.x.y.z!not-for-mail  
Or maybe it could, but that would be a new idea for me (?!?)

> I would be in favour of following s-o-1036, as our drafts
> have always done, and hope that INN will conform in due course

That would go to Appendix B "differences from 1036". 
  
> little actual harm appears to have arisen from the present
> INN

It would be hard to see any harm.  We'd also need not-for-mail
as convention to keep the harm as limited as it apparently is.

And not in USEPRO, users could be tempted to "improve" this
not-for-mail if they don't see that it's no nonsense.  I didn't
know this until Russ mentioned what INN does two weeks ago.
 
> Please, no new tickets. This is part of #1047.

#1047 is apparently too big to tackle it in one piece.  It's
not necessarily better to have three new instead of one old
ticket, but we didn't make a decisive progress with #1047 :-(

> So leave it be. It causes no harm, and may even provide for
> special treatment of the pre-injection part of the Path at
> some future date

Sorry, when we arrived at three or four !.POSTED combinations
it was too much for me.  I'd opt to kill it, it is redundant,
the old NNTP-Posting-Host is visible in the new Injection-Info.

> it will be a long time before it is widely enough implemented
> to be able to rely on its presence.

I'm not that optimistic about the future of Usenet.  Maybe if
folks adopt a new text format, Wiki formatting or even HTML.

>> 5  demon!added-by-demon-2-0-0-127-adsl.example
[...]
> And the "added-by-demon" examples should really have started
> with a ".", since their intent was evidently diagnostic.

See above.  If the syntax says <path-poster> and what you see
is <path-poster>, then it is <path-poster> no matter who put it
there.  If you want another possibility you need another syntax.

>> Case (4) and (5) are a situation where demon makes up a tail
>> entry based on reverse DNS.
 
> No, they are NOT part of the <tail-entry>.

With your definition !added-by-... in (5) is the <tail-entry>,
stuff to the right of the last "!".  The rest of the confusion
is just again 1036 <path-poster> vs. s-o-1035 <tail-entry>.

Note that (4) is as expected ambiguous with the 1036 idea, and
you said that you want s-o-1036.  Russ wanted 1036, I tried to
reflect his ideas in syntax.  We can't have a syntax that tries
both at the same time.

> As written, #4 will get treated as a normal <path-identity>s 
> by s-o-1036 systems (indeed by all current systems).

We've heard that that's not the case, INN treats not-for-mail
as legacy name, only because there is no such system it works.

>> 6  demon!127.0.0.2!not-for-mail
[...]
> #6 MUST be accepted (though maybe not generated - though
> I believe only one major site currently inserts such things).

Okay, the 127.0.0.2 is <diag-obs>.  For the 1036 syntax and INN
that would result in the known not-for-mail "system", no harm.

> I don't really care whether #7 is legal or not.

Let's say illegal and skip the tricks needed to "legalize" it.

                      Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 20 Feb 2006 11:53:00 GMT

>Charles Lindsey wrote:

...

>  path-poster   =  path-identity [ "!" path-nodot ]

Yes, but that does not even reflect RFC 1036. The <path-identity> there is
no different from any other <path-identity> in the RFC 1036 Path (i.e. it
is a candidate for examination and refusal to propagate by relayers -
which is exactly how INN will currently treat it). Therefore, nothing is
gained by putting it inside a separate <path-poster> item since it implies
no semantic difference.

In all current usage (1036, s-o-1036, INN, whatever), it is ONLY what
comes after the final "!" that is, or is not, treated differently. I see
no reason whatsoever to change that. So if we define what comes after the
final "!" as the <tail-entry> (just to give it a name) then we can make
some special rule about it (like for relayers to ignore it as in
s-o-1036). My view is that we should follow s-o-1036, as our drafts have
always done, but if you wanted to follow INN, then all you would need to
do would be to remove the <tail-entry> from the syntax entirely, because
that is how INN treats it.

>Yes, that's why I renamed it for the 1036 idea with another

Yes, but your definition achieves nothing, so what is the purpose of it?

>Or maybe it could, but that would be a new idea for me (?!?)

Why ever not? If a diagnostic can appear at other places in the Path, why
can it not appear there? It is certainly clearer than
...!added-by-demon.x.y.z!not-for-mail, and even ...!.SEEN.bill!fred might
make some sort of sense. Either way, it does no harm so the syntax need
not forbid it (USEPRO might not allow it, but that is another matter).

>That would go to Appendix B "differences from 1036". 

Possibly. Not so much a "difference" as "removal of an ambiguity".

>as convention to keep the harm as limited as it apparently is.

"not-for-mail" already _is_ the convention (unless Joe prefers to put
"joe"). Actually, <empty> after the final "!" would also work with current
sotware, I suspect, so we might allow that.

>the old NNTP-Posting-Host is visible in the new Injection-Info.

The three or four !.POSTED conbinations were your invention, not mine, so
they hardly form an argument for not having .POSTED. They are clearly a
nonsense. If we need that effect, then we allow more than one diagnostic
after each <path-identity>. If we don't, then we restrict it to one. You
keep telling me to KISS, and yet you persist in introducing complicated
new features to what is otherwise a straightforward syntax.

>is <path-poster>....

Which seems to me like a good argument for not saying anything at all
about <path-poster>.

>reflect his ideas in syntax.  We can't have a syntax that tries

I don't think Russ necessarily wanted 1036 - he just pointed out that INN
did not implement s-o-1036. As I said above, if you want to define it that
way (which is Not 1036), then you just omit the <tail-entry> entirely.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Feb 2006 15:09:09 +0100

> Yes, but that does not even reflect RFC 1036. The
> <path-identity> there is no different from any other
> <path-identity> in the RFC 1036 Path (i.e. it is a
> candidate for examination and refusal to propagate
> by relayers

It surely says that paths aren't empty and dont't end
with "!".  We want an optional <path-diagnostic> to the
right of all later <path-identity>, but not here to the
right of the very first <path-identity>.

> nothing is gained by putting it inside a separate
> <path-poster> item since it implies no semantic 
> difference.

That's not the case, see above, no diagnostic after the
"originating system", as 1036 puts it.

> In all current usage (1036, s-o-1036, INN, whatever),
> it is ONLY what comes after the final "!" that is,
> or is not, treated differently.

Current usage has no <path-diagnostic> as we want to
define it.  There's an off-by-one error either in my
or in your thinking.

> My view is that we should follow s-o-1036

Yes, that's clear, and in theory it should be enough to
remove the square brackets in my <path-poster> to move
from "1036 permissible" to "s-o-1036 required".

But you say it's not, one of us must be wrong.  Won't
surprise me if it's me, but lets get a third opinion.

I just don't get why the very first <path-identity>
needs !.MISMATCH or !.SEEN or !! (= match), all that
might be to its right is "not-for-mail" or similar:

There can't be any (mis)match for say "not-for-mail".

> Yes, but your definition achieves nothing, so what

Finding out who's right... ;-)  No, seriously, it's
just what I thought how <path-diagnostic> should work,
between peers,

> Why ever not? If a diagnostic can appear at other places
> in the Path, why can it not appear there?

Yes, that's the question,

> Either way, it does no harm so the syntax need not forbid
> it (USEPRO might not allow it, but that is another matter).

Simplified we have  *( entry "!" ) tail  in the s-o-1036 ABNF.

Now Russ opted for an optional tail as in INN and 1036.  For
that I couldn't say  *( entry "!" ) [ tail ]  in the syntax,
Russ certainly did NOT propose that a path might end with "!".

And that's the reason why I extracted the required rightmost
<path-identity> getting  *( entry "!" ) entry [ "!" tail ]

I don't prefer 1036-style, but it's the only way to get it
right.  A better name for the <path-poster> is <path-orig>,
but it's not the same as <tail-entry> for s-o-1036-style.

  [s-o-1036 style]
 
> Possibly. Not so much a "difference" as "removal of an

Okay, but difference is difference whatever the reason is.

> "not-for-mail" already _is_ the convention

Of course, in practice, but not yet in the USEFOR draft.

> (unless Joe prefers to put "joe").

That Joe should get a clue why that's a really bad idea:
 
IMO "not-for-mail" is a SHOULD.  Can't let him try "demon"
with no hint that this is a bad idea (unless he wants it).

> Actually, <empty> after the final "!" would also work
> with current sotware, I suspect, so we might allow that.

See above, my gut feeling was that this is a non-starter.

Could be wrong.  Note that in one of your earlier proposals
that could be an isolated "!" in the last line of a folded
path.

> three or four !.POSTED conbinations were your invention,
> not mine

No.  I asked if you need just two (posted-1 and posted-2).

You said there are three or four combinations, seen-posted,
match-posted, mismatch-posted, only posted.  At that moment
Richard saw that POSTED is cargo-cult and should be deleted,
and I second this, POSTED R.I.P.

> yet you persist in introducing complicated new features to
> what is otherwise a straightforward syntax.

There never was any path-syntax passing Bruce's test, but I
hope that he would be hard pressed to tackle what I tried to
extract from what Russ and Harald apparently want to express.

> I don't think Russ necessarily wanted 1036 - he just pointed
> out that INN did not implement s-o-1036.

He'll tell us.  Removing two square brackets in my proposal
and renaming <path-poster> to <path-orig> is simple enough.

                           Bye, Frank

---

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

> right of the very first <path-identity>.

I think I'd like to see

....injecting-server!.POSTED.fifth-modem-from-the-left-in-rack-2!joe

as a legal construct.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Feb 2006 16:32:09 +0100

> as a legal construct.

What's the "joe" here ?  I assume it's one of the permissible
user names in 1036, in other words a case of "not-for-mail".

But there never is a "not-for-mail" without <path-identity>
at the moment, i.e. today we'd have an injecting-server!joe
or maybe leaf-node!joe (?)

The <path-identity> and the <tail-entry> are a unit.  They
come from the same system.  There's no reason why a system
should add <path-diagnostic> about itself to the path.  The
"unit" was <path-poster>, now I renamed it to <path-orig>.

What you like to see apparently comes from an injecting-server.
It has its very own header field Injection-Info to add such
details, so why do it in the path (again) ?  That's redundant.

Assuming that you still want it, redundant or not:

Then it's in a position where _other_ diagnostics make no
sense at all.  So we could have an optional !.POSTED here
in the <path-orig>, in s-o-1036 style (mandatory tail):

 path-orig = path-id [ "!.POSTED" diag-posted ] "!" path-nodot

Actually we'd also want <diag-obs> here for IPv4, I skip
that detail, the important point is:  No SEEN, no (mis)match
at this place in <path-orig>.

That kills at least the two / three / four weird combos of
POSTED with other diagnostics.

For the very obscure reinjection case we might get POSTED
elsewhere in the path, but if it started in the right way
(not combined with SEEN etc.) it stays in the right way,
it's a proper alternative for a normal <path-diagnostic>.

Is that how you want it ?  Syntax added below, bye, Frank

path            =  "Path:" SP *WSP path-list path-orig *WSP CRLF
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-orig       =  path-identity [FWS] [orig-diagnostic] "!" orig-tail
orig-tail       =  path-nodot                    ; not-for-mail

path-diagnostic =  diag-match / diag-mismatch / diag-seen / diag-obs
orig-diagnostic =  diag-posted / diag-obs

diag-posted     =  "!.POSTED"    diag-identity

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Feb 2006 17:02:36 +0100

[...]
> path-orig       =  path-identity [FWS] [orig-diagnostic] "!" orig-tail

Sigh, it doesn't fit into one RfC line this way.  Any good idea
for another name instead of <orig-tail>, but one char. shorter ?

Or could the "!" go to the begin of <orih-tail> ?  Testing:

; [...]

path-orig       =  path-identity [FWS] [orig-diagnostic] tail-entry
tail-entry      =  path-nodot                    ; not-for-mail

Not the same style as for <path-list>, but maybe acceptable (?)

We're at 26 ABNF lines from <path> to <alphanum> with seven
blank lines.  Without the !.POSTED it was four lines shorter.

But actually <tail-entry> should get its own line if it's not
only an optional <path-nodot> legacy name (as in 1036-style),
so the complete !.POSTED overhead (in ABNF lines) is three.

                         Bye, Frank

---

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

Charles Lindsey <[email-masked]> writes:

> I don't think Russ necessarily wanted 1036 - he just pointed out that
> INN did not implement s-o-1036.

If we're going to include Injection-Info, I prefer treating all Path
entries other than diagnostics as Path entries and not overloading the
field for injection information.  The latter is primarily useful to avoid
a new header, and I believe that's why Brad originally proposed the
complex injection syntax.  If we have a new, complex header to put that
information in, the only point in also putting it into the Path is to
carry extra trace information for reinjection.  And that purpose is
probably better served by renaming the original Injection-Info header.

> As I said above, if you want to define it that way (which is Not 1036),
> then you just omit the <tail-entry> entirely.

Yes.  A note mentioning the not-for-mail bit is worthwhile given existing
practice.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 11:46:15 GMT

>"unit" was <path-poster>, now I renamed it to <path-orig>.

No, I don't think so. The <tail-entry> ("joe") comes from the user agent.
The first <path-identity> usually (but not inevitably) comes from the
injecting agent. And if the injecting agent does not see any "joe" in what
it receives, then it adds a "not-for-mail" itself just to keep the syntax
happy.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 11:26:32 GMT

...

>might be to its right is "not-for-mail" or similar:

It's syntactically harmless, though maybe semantically meaningless. So not
worth extra syntax just to prevent it.

>There can't be any (mis)match for say "not-for-mail".

But there might be a (mis)match for "joe".

>Russ certainly did NOT propose that a path might end with "!".

No, the one thing you cannot have is an *optional* tail, because there is
no way to tell whether the last item is a tail or an identity. So either
there is *always* a tail (as in s-0-1036, and it is to be ignored by
relayers), or there is *never* a tail and the last thing is always a
path-identity (maybe with a diagnostic) and relayers take it into account.

>That Joe should get a clue why that's a really bad idea:

No, it is NOT a bad idea. It is a fairly common practice, and once upon a
time might even have provided a working UUCP email address.

>with no hint that this is a bad idea (unless he wants it).

No, not a SHOULD, but a warning that some current software might not
ignore it.

>See above, my gut feeling was that this is a non-starter.

OK. Just a suggestion.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 11:56:51 GMT

>complex injection syntax.

Agreed that there is some redundancy here, it is convenient to be able to
glance quickly through the Path header to spot the point in injection. The
additional cost of .POSTED is small, and it causes no harm.

>  If we have a new, complex header to put that

But that cannot be relied upon. Even insertion of the first
Injection-Info is opnly a SHOUld as things stand.

>Yes.  A note mentioning the not-for-mail bit is worthwhile given existing

I agree that if we follow s-o-1036 (tail-entry to be ignored by relayers),
then a NOTE pointing out some diversity of current practice is in order
(probably in USEPRO), together with mention of "not-for-mail" (which is
alread done in USEPRO).

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 11:40:01 GMT

>....injecting-server!.POSTED.fifth-modem-from-the-left-in-rack-2!joe

Meaning "we (injecting-server) injected this, and we got it from
fifth-modem-from-the-left-in-rack-2". But in that case, surely
"fifth-modem-from-the-left-in-rack-2" is actually the <path-identity> of
the apparatus that fed it to you (I presume it was injecting-server's rack
and not joe's rack).

So surely what you meant was more like

....injecting-server!.POSTED.joes-laptop!joe

or more likely

....injecting-server!.POSTED.123.234.345.456!joe

in which case injecting-server is asserting that is was the injecting
agent, and also that it came from joes-laptop or from 123.234.345.456 (in
the sense of "SEEN").  But in that case, you might also want to assert
that it didn't come from joes-laptop (in the sense of "MISMATCH").

So wouldn't it be simpler to allow

....injecting-server!.POSTED!.SEEN.joes-laptop!joe
or
....injecting-server!.POSTED!.SEEN.123.234.345.456!joe

(i.e. allow more than one diagnostic), and then you can construct all the
bizarre special cases that you could ever dream of.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 13:35:56 +0100

Charles Lindsey wrote:

> if we follow s-o-1036 (tail-entry to be ignored by relayers),
> then a NOTE pointing out some diversity of current practice
> is in order (probably in USEPRO), together with mention of
> "not-for-mail" (which is alread done in USEPRO).

We also need it in USEFOR - only clueful folks will look into
USEPRO.  The minimal approach is an ABNF comment:

Maybe too minimalistic, how about "The <tail-entry> SHOULD be
the lower case string not-for-mail as explained in [USEPRO]" ?

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 13:56:02 +0100

> No, I don't think so. The <tail-entry> ("joe") comes from
> the user agent.  The first <path-identity> usually (but not
> inevitably) comes from the injecting agent.

Interesting, that's different from the explanation in 1036.

And reflects what s-o-1036 says.  But even in the s-o-1036
model it's clear that there can't be any case of (mis)MATCH
for <tail-entry> "joe".  Joe is supposed to be a user, not
a feed.

If we say !.POSTED  or !.POSTED.diag is for users / posters,
and !.SEEN.diag or (mis)MATCH is between relays, all should
be clear:  No "double-diags".
                              Bye, Frank

---

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

>the lower case string not-for-mail as explained in [USEPRO]" ?

No, "not-for-mail" is the default that you write (or somewhere in the
software writes for you) if you choose not to use your name "joe". But it
has not been suggested that using names such as "joe" should be
deprecated.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Feb 2006 14:10:29 +0100

> software writes for you) if you choose not to use your name "joe". But
> it has not been suggested that using names such as "joe" should be
> deprecated.

It's more like "required" than "suggested" after I learned that
1036 servers would interpret it as "site 'joe' already has the
article".
                             Bye, Frank

---

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

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>the lower case string not-for-mail as explained in [USEPRO]" ?

looking at the very last item in the Path for 26,125,927 articles from a
couple of summers ago ...  here's the top 40 (note that I've upper cased
them to ensure case insensitivity in the matches I made [doesn't make
all that much difference if case insensitive])

19096174  NOT-FOR-MAIL                73.09%
 1317084  TJUBBS                       5.04%
  631392  TK2MSFTNGXA03.PHX.GBL        2.42%
  231491  CPMSFTNGXA06.PHX.GBL         0.89%
  225470  TK2MSFTNGP11.PHX.GBL         0.86%
  217073  TK2MSFTNGP13.PHX.GBL         0.83%
  215733  TK2MSFTNGP09.PHX.GBL         0.83%
  208797  TK2MSFTNGP10.PHX.GBL         0.80%
  194575  TK2MSFTNGP12.PHX.GBL         0.74%
  191901  ROBOMOD                      0.73%
  164954  CPMSFTNGXA10.PHX.GBL         0.63%
  150967  KKCITY                       0.58%
  136417  CLARINEWS                    0.52%
  135656  TK2MSFTNGP15.PHX.GBL         0.52%
  110554  SPAMCANCEL                   0.42%
  101004  USENET                       0.39%
   90221  TK2MSFTNGP14.PHX.GBL         0.35%
   89158  TK2MSFTNGP08.PHX.GBL         0.34%
   80567  MAIL2NEWS                    0.31%
   80379  WRETCH                       0.31%
   76426  NANKAI                       0.29%
   71106  CHAINSAW                     0.27%
   66658  WEBX                         0.26%
   64050  NIUSY.ONET.PL                0.25%
   54217  YTHT                         0.21%
   49287  SMTH                         0.19%
   48169  FORMOSA                      0.18%
   48126  CIS_NCTU                     0.18%
   44988  NEWS                         0.17%
   41496  THERE.IS.NO.CABAL            0.16%
   41198  MAPLE                        0.16%
   32528  KIMOWEBBBS                   0.12%
   32395  BBS.OPENFIND.COM.TW          0.12%
   31336  PTT                          0.12%
   30351  SIMFARM                      0.12%
   29634  MIRRORPOST                   0.11%
   28339  HIT                          0.11%
   27314  TK2MSFTNGXA02.PHX.GBL        0.10%
   26794  KIMOBBS                      0.10%
   26505  DRN                          0.10%

           ... remainder ...           6.07%

we can see that not-for-mail is common, but far from universal. Is there
really an overriding reason here for a SHOULD (making a quarter of all
articles non-conformant) ?

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"