Subject: Re: New USEPRO path-identity text

From: John Stanley <[email-masked]>
Date: Mon, 11 Jul 2005 15:58:09 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>RFC 1918 make a clear disticntion between the words "public" and "private"
>as regards IP addresses,

But does not define "publicly recognized". Most people publicly recognize 
192.168.0.1 as a "private" address, but they also publicly recognize 
224.something as multicast, too. 

> Again, I would welcome alternative wordings - 

Except from me, it would seem. 

>Yes. Usenet's a minefield. Always has been. So what's new?

We have no business telling an admin to do something and then saying
if he does it he is responsible for all the bad things that happen. Either 
don't tell him to do it, or don't put the blame on him for the bad things 
that happens when he does it.

>However. Bruce is bending my ear to the effect that we MUST provide some
>mechanism to ensure the uniqueness of these names, 

I don't see where we ever demand that they be unique. Certainly not in the 
section that deals with defining a path-identity in USEFOR. And we 
certainly don't tell someone how to guarantee they be unique when we say 
that they only SHOULD use one of the four suggested methods. So neither
unique by mandate nor unique by design. 

An outstanding request for explanation still stands:

   and if the agent offers its services to the general public the form
   "abuse@" that FQDN MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).

I'm still waiting for an explanation of why we are overriding RFC2142 in 
this matter. Why is RFC2142 not sufficient, and what interoperability 
issue is involved to justify this "MUST"? The news server 
"a.b.example.com" will insert a.b.example.com into the Path, but RFC2142 
requires that only [email-masked] be valid. What interoperability issue 
exists to justify another mandate from us?

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Jul 2005 10:01:30 GMT

>this matter.

I am still waiting for an explanation of where you think what I have
written overrides RFC 2142.

>Why is RFC2142 not sufficient, and what interoperability
>issue is involved to justify this "MUST"?

Because RFC 2142 is badly written, and it is not clear whether the common
names that it defines MUST be provided, or whrther some of them (and if so
which ones) are optional. It uses undefined words like "must" in some
places, and "MUST" in others.

Hence the wording I wrote is intended to remove those uncertainties by
specifying MUST for the injectng agent and SHOULD for all other agents in
the Path (the same as it has been in all our drafts for the past 5 years
or so).

> The news server 
>requires that only [email-masked] be valid.

No, RFC 2142 says that "only the organization's top level domain [is]
required to be valid", but since it nowhere defines what is meant by "top
level domain", that tells us precisely nothing. And where do you get that
"only" from? Even if "example.com" is the TLD, it is still clear that
[email-masked] and [email-masked] are both valid, and even
encouraged.

Even though RFC 2142 is described as "Standards Track", it is unusable as
a standard and, as Ned has recently pointed out on this list, it should
really have been a "BCP". That is how I have always tried to treat it,
giving specific rules for use on Usenet, and ensuring that they were
within the spirit of RFC 2142, even though it is impossible to discern the
letter.

-- 
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: Frank Ellermann <[email-masked]>
Date: Wed, 13 Jul 2005 03:10:47 +0200

Charles Lindsey wrote:
 
> RFC 2142 says that "only the organization's top level domain
> [is] required to be valid", but since it nowhere defines what
> is meant by "top level domain", that tells us precisely
> nothing.

It's defined in RfC 2181 chapter 6 "zone cut" and chapter 7
"SOA RRs", and you normally should get it get by something
like `nslookup -q=ns a.b.example.com`

The SPF adventure was a kind of brainwashing...  Or in other
words, we don't need to mention abuse@ at all, unless it's a
note with a pointer to RfC 2142.

The MUST [email-masked] is utter dubious, just get rid
of it, or replace it by what 2142 does:

| Note:  Supporting the address abuse@<hostname> is a good
| idea, even if that's only required for the top level domain
| of the authoritative zone, see also [RFC2142] and [RFC2181].

> it is still clear that [email-masked] and
> [email-masked] are both valid, and even encouraged.

Sure, but we have news@ and usenet@ and the "complaints-to" or
whatsitsname parameter of the injection-info, the details of
the abuse@ mailbox as specified in 2142 are irrelevant for us.

It really is no MUST for a subdomain, and with two guaranteed
adresses plus optional addresses we don't need the abuse@ MUST.

                       Bye, Frank

---

From: Steve Walker <[email-masked]>
Date: Wed, 13 Jul 2005 18:39:27 -0500

> the abuse@ mailbox as specified in 2142 are irrelevant for us.

I agree, the (X-)Complaints-To header fills any real world needs. 
  Anything else is redundant and a waste of time.

Steve.

---

From: Steve Walker <[email-masked]>
Date: Wed, 13 Jul 2005 18:56:28 -0500

> unique by mandate nor unique by design. 

As a side note of something in the real world, we stamp several 
path stamps.  We first stamp a non-FQDN name that tells us what 
reseller the post is from.  We then stamp a general 
nntpserver.com stamp and then we stamp a machine-specific stamps 
all the way out.  I've never had any problems with pathstamp name 
space collisions.  It seems to me that a non-existent problem is 
being solved, IMO, "if it's not broke, don't fix it"...

If two sites use the same pathstamp one will just change.  It 
doesn't break anything outside of the two sites so why should the 
protocol for message format care.  If anything, this is more a an 
NNTP article routing issue and the only way to solve it is to set 
up ICAN style registry of Usenet sites, which I think no one wants.

Steve.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Jul 2005 10:18:36 GMT

>like `nslookup -q=ns a.b.example.com`

Right. I just downloaded RFC 2181, and it is an interesting read. However,
it is of no help in the present discussion, because there are usually
several zone cuts in a given FQDN. You cannot require an ordinary user to
be familiar with the minutiae of the DNS system before he can complain to
an abuse@ address.

Here is an example:

Suppose you have an article which, as evident from its Path or its
Injection-Info, was injected by

	wapping.cs.man.ac.uk

You want to complain about it. Supposing that RFC 2142 is all you have to
go on, and supposing that there is no mail-complaints-to in the
Injection-Info, what then is the correct abuse@ address to use, and why?
Or, to put it another way, what is the "top level domain" of the relevant
organization?

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Jul 2005 10:47:01 GMT

In <[email-masked]> Steve Walker <[email-masked]> writes:

>path stamps.

Yes, a lot of sites seem to do that, and I asked recently whether we should
write it into out standard that it was allowed (MAY) to do that.

>  We first stamp a non-FQDN name that tells us what 
>reseller the post is from.

Though that adds quite a bit to the length of the Path. The current
proposal for the USEPRO draft is that when you have established where it
is from, you check it against what the previous site put in the Path, and
if it agrees you just use a "!!" as the <path-delimiter> instead of the
usual "!". That saves wasting Path space.

>  We then stamp a general 
>all the way out.

Yes, that is the sort of "double stamping" that could be useful, since it
singles out the domain at which you guarantee that "news@", "usenet@" and
"abuse@" will work.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Jul 2005 23:38:58 +0200

Charles Lindsey wrote:
 
> Suppose you have an article which, as evident from its Path
> or its Injection-Info, was injected by

> You want to complain about it. Supposing that RFC 2142 is all
> you have to go on, and supposing that there is no
> mail-complaints-to in the Injection-Info, what then is the
> correct abuse@ address to use, and why?

Now, as 2142 says, there MAY be [email-masked] 

OTOH I'm an RFCI-fan (not alway, but often), and therefore
I'd check `rxwhois -a wapping.cs.man.ac.uk` (-a for "abuse"):

wapping.cs.man.ac.uk not found at .rfc-ignorant.org or .multi.surbl.org
whois -h whois.abuse.net wapping.cs.man.ac.uk
[email-masked] (for cs.man.ac.uk)
[email-masked] (for cs.man.ac.uk)

Without rxwhois I'd try `nslookup -q=ns wapping.cs.man.ac.uk`:

[...]
| Autorisierte Antworten können gefunden werden in:
| cs.man.ac.uk
[...]

So that also says [email-masked]

> what is the "top level domain" of the relevant organization?

What you get with nslookup -q=ns (otherwise you are already at
the "top level domain").  Not exactly straight forward, but it
is the rfc-ignorant.org listing policy for its abuse zone, and
for a _manual_ complaint I want a clear way for an escalation
up to ICANN's WDPRS (whois data problem report system) if it's
a gTLD (not in this ac.uk example).

But I'd avoid to waste time with an [email-masked],
because I couldn't submit it to RFCI.

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Jul 2005 23:46:56 +0200

Charles Lindsey wrote:
 
> the sort of "double stamping" that could be useful, since it
> singles out the domain at which you guarantee that "news@",
> "usenet@" and "abuse@" will work.

It doesn't:  news@ and usenet@ MUST work for all FQDNs in the
path, that's what usepro-03 says, and I think it's fine, and
for abuse@ see RfC 2142.
                            Bye, Frank

---

From: Steve Walker <[email-masked]>
Date: Fri, 15 Jul 2005 17:27:32 -0500

> path, that's what usepro-03 says, and I think it's fine, and

I have over 30 news servers and each one has it's own path stamp. 
  Are you saying that Usepro says I have to setup email on every 
sub-domain?  If so that's just stupid and not likely to happen. 
Email works for the top level domain and that's more than enough 
considering there is also an X-Abuse-Report header stamped.

Steve.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 16 Jul 2005 01:24:17 +0200

Steve Walker wrote:

> I have over 30 news servers and each one has it's own path
> stamp.   Are you saying that Usepro says I have to setup
> email on every sub-domain?  If so that's just stupid and not
> likely to happen.

With 30 servers you're also able to setup 2 * 30 aliases and
maybe 30 MX records, if that's how you like it.

> Email works for the top level domain and that's more than
> enough considering there is also an X-Abuse-Report header
> stamped.

| The prepended <path-identity> MUST be an FQDN  mailable
| address (a-5.6.2).

That's hopelessly obsolete, I lost track with the changes
for the <path-identity>, but IIRC that part was undisputed.

Nobody says that you'd need 30 smtpds to do it.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Jul 2005 11:17:22 GMT

>path, that's what usepro-03 says, and I think it's fine, and

No, USEPRO DOESN'T say that. It says "ideally should", not MUST.

It is RFC 2142 that says "MUST" (or rather "must") for that case.

It is is "double stamped", with

    [email-masked]!nntpserver.com!...

then a net savvy person would see at once that "[email-masked]" was
the address to use (I think usenet@ and news@ at net-savvy people, such as you find on this list,
can probably look at a domain name and form a pretty good opinion, just
from their general knowledge of the conventions used to construct domain
names, as to what is going on (and even then, they come up with different
results).

But for an innocent who does not even recognise that it is an academic
institution, and that "cs" stands for "computer science", and who has never
heard of 'whois' or 'nslookup', you need a simple rule that anybody can
apply, such as "look at what appears in the Injection-Info, or in front of
the 'POSTED' in the Path, and stick "abuse@" in front of it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Jul 2005 11:17:22 GMT

then a net savvy person would see at once that "[email-masked]" was
the address to use (I think usenet@ and news@ are for net-savvy people).

Non-net-savvy people should only need "abuse@", and then only to the
injecting agent. With double stamping, they would see:

    [email-masked]!nntpserver.com!POSTED!not-for-mail

so you simply tell them to "use whatever is to the left of the 'POSTED'".

re for net-savvy people).

Non-net-savvy people should only need "abuse@", and then only to the
injecting agent. With double stamping, they would see:

    [email-masked]!nntpserver.com!POSTED!not-for-mail

so you simply tell them to "use whatever is to the left of the 'POSTED'".

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Jul 2005 11:06:36 GMT

>considering there is also an X-Abuse-Report header stamped.

What USEPRO currenty says is that all 30 "ideally should" be mailable
(what USEPRO eventually says is what we are currently discussing).

OTOH, RFC 2142 says that you "MUST" (or "must") create 30 MX records
pointing to some suitable SMTP host (that is for news@ and usenet@).

So we are weaker there.

OTOH, for an injecting agent, USEPRO currently says you MUST create such
an MX record (or have the A record listen to port 25), and you MUST
provide abuse@ as well as the other two (modulo a complaints address in
Injection-Info).

So we are stronger there, because RFC 2142 only requires abuse@ at the
"top level domain" (figuring out which is the "top level domain" is left
as an exercise for the student).

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jul 2005 19:20:54 +0200

Charles Lindsey wrote:

>> news@ and usenet@ MUST work for all FQDNs in the path,
>> that's what usepro-03 says, and I think it's fine, and
>> for abuse@ see RfC 2142.

> No, USEPRO DOESN'T say that. It says "ideally should", not
                                vvvv            vvvvvvvv
| The prepended <path-identity> MUST be an FQDN mailable
| address (a-5.6.2).
                                ^^^^            ^^^^^^^^
Lines 1605 and 1606 in draft-ietf-usefor-usepro-03.txt

> [email-masked]!nntpserver.com!POSTED!not-for-mail

There's no "@" in a <path-identity> let alone in a host name.
This Internet-Draft will expire in August 2005.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 19 Jul 2005 10:32:13 GMT

>| The prepended <path-identity> MUST be an FQDN mailable

Those words apply to injecting agents only, NOT to all FQDNs in the path
as you claimed.

If you want them to apply to all FQDNs in the Path, that is another
matter, but it is not what our draft currently says, nor has said for
several years past.

And if you want that MUST for injecting agents to be demoted to SHOULD,
that too is another matter.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Jul 2005 06:47:35 +0200

Charles Lindsey wrote:

> Those words apply to injecting agents only, NOT to all FQDNs
> in the path as you claimed.

I've found the new usepro-04 two hours after that article, and
now I've deleted the old usepro-03.

> If you want them to apply to all FQDNs in the Path, that is
> another matter, but it is not what our draft currently says

Yes, s/,ideally, should/SHOULD/ in 2.3 case 1 (A or AAAA).

Dito in 2.3 case 3 (MX) just to get consistent requirements:
s/MUST be "mailable"/SHOULD be "mailable" (see below)/

> And if you want that MUST for injecting agents to be demoted
> to SHOULD, that too is another matter.

I'd remove the complete convoluted clause at the end of 2.3:

- and if the agent offers its services to the general public
- the form "abuse@" that FQDN MUST also be available, unless a
- more specific complaints address has been provided in a
- <complainto-param> of an Injection-Info header field (F-3.2.14).

Nobody knows to whom it offers its services.  What you want is
apparently "specify your abuse address in a <complaintto-param>
or support abuse@ if you are an injection agent".  IMO we don't
need this conditional and unclear abuse@ MUST, because there's
already an unconditional news@ / usenet@ MUST in the first part
of this statement:

| For an injecting agent prepending to a Path header field
| (7.2.2), the <path-identity> MUST be option 1 or 3 and the
| FQDN MUST be mailable,

Just truncate it there.  It's repeated in 7.2.2 clause 10, no
chance to get it wrong.

If you want to talk about the "top level domain" of the FQDN in
a <path-identity> (A, AAAA, or MX) in conjunction with RfC 2142
chapter 2 add a general note below the special MUST valid only
for the injection agent.
                        Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 20 Jul 2005 11:18:10 -0400

[...]
> > another matter, but it is not what our draft currently says

The specific text (which Charles has snipped) referred to "The prepended
<path-identity>".  As an injection agent doesn't prepend (there is at
injection no Path field) and relaying agents do prepend, I can make no
sense of Charles' comments.

> chapter 2 add a general note below the special MUST valid only

If the text is meant to apply to injection agents, then it should
avoid the word "prepend" and its derivatives and should clearly state
that it refers specifically to injection.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Jul 2005 14:21:57 GMT

>sense of Charles' comments.

You could perhaps have tried reading the actual text in USEPRO.

In fact, it is not necessarily the case that there is no Path present
prior to injection, as 7.2.1 makes clear.

The instructions given in USEPRO come in 2 steps:

9. If there is no Path already present, then you create one with a
<tail-entry> (typically "not-for-mail").

10. You then *prepend* the <path-identity> of the injecting agent,
together with a "POSTED", to the Path (which is now guaranteed to be
there by the previous step).

>that it refers specifically to injection.

Since the text in question is contained with a section entitled "Procedure
to be followed by Injecting Agents", that would hardly seem to be
necessary.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 12:30:55 -0400

> there by the previous step).

Charles, you have previously claimed that the text is not prescriptive --
that processing need not occur in discrete step in a specific order so
long as the end result is consistent; make up your mind.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Jul 2005 15:31:00 GMT

>long as the end result is consistent; make up your mind.

So? If you follow the steps in the order given, then you encounter a MUST
in Step 10 which tells you to prepend certain things.

If you choose to do things in a different order (for example by combining
Steps 9 and 10 into a single operation in circumstances where that is
possible), then those same things MUST still land up at the head of the
Path.