Subject: New USEPRO path-identity text

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 14:54:46 GMT

Following recent discussions, it seems agreed that IP addresses in
<path-identity>s are to be discouraged, and that arbitrary names are to be
dioscouraged even more. I have therefore modified the proposed USEPRO
texts to take account of this. Comments?

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers.  To ensure that a <path-identity> provides a unique identity
   for the news-server concerned, it should be one of:
 
   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record, which SHOULD identify the actual host inserting
      this <path-identity> and, ideally, should also be "mailable" (see
      below).
 
   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] which SHOULD, according to the routeing tables [Ref needed]
      identify the actual host, as above. This option SHOULD NOT be used
      if an FQDN for that host is available.
 
   3. A fully qualified domain name (FQDN) associated with an "MX"
      record, which MUST be "mailable".
 
   4. An arbitrary name believed to be unique and registered at least
      with all other news-servers receiving articles directly from the
      given one. The news-server administrator is responsible for
      choosing an appropriate name (and must bear the consequences of an
      inappropriate choice). This option SHOULD NOT be used unless the
      earlier options are unavailable (e.g. because the host in question
      is not connected to the Internet).
 
        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within a <path-identity>,
        but only within an <IPv6address>.  It would therefor be unwise
        to choose, as the arbitrary name, anything composed solely of
        hexadecimal digits.
 
   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@<FQDN>" and
   "news@<FQDN>", in conformity with [RFC 2142].

   For an injecting agent prepending to a Path header (7.2.2), the
   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
   and if the agent offers its services to the general public the form
   "abuse@<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).

-- 
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: Bruce Lilly <[email-masked]>
Date: Mon, 4 Jul 2005 13:33:30 -0400

On Mon July 4 2005 10:54, Charles Lindsey wrote:
>    Injection-Info and Xref headers.

Header fields.

>    An injecting agent MUST identify 

What about Xref?

>    headers.

Header fields.

[...]
>       3986] which SHOULD, according to the routeing tables [Ref needed]

Whose "routeing [sic] tables"?  My routing tables point here for the IP
address 127.0.0.1; if yours also point here, you have a problem. Likewise
for IP addresses which cannot be routed (RFC 1918).
 
>       if an FQDN for that host is available.

For IPv6 and the Path field, and unless Frank's or John's suggestions
for replacing colons are used, there is an interoperability issue,
therefore s/SHOULD NOT/MUST NOT/, at least for IPv6.
  
>       record, which MUST be "mailable".

Perhaps combine with #1, probably also allow CNAMEs.
 
>       given one.

But not registered with senders?

[...]
>    For an injecting agent prepending to a Path header (7.2.2), the

field

>    Injection-Info header (F-3.2.14).

field

---

From: Richard Clayton <[email-masked]>
Date: Mon, 4 Jul 2005 19:44:42 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
><path-identity>s are to be discouraged, 

yes

>and that arbitrary names are to be
>dioscouraged even more. 

if they are not traditional, then yes

>I have therefore modified the proposed USEPRO

you have put a SHOULD NOT against UUCP names ... reducing the level of
compliance of some of the oldest systems there are :(

this provision seems unnecessary since they aren't creating a problem

>      is not connected to the Internet).

ie: the last sentence is unnecessary and doesn't follow from Harald's
proposal (see thread starting with <URL: http://www.imc.org/ietf-
usefor/mail-archive/msg01573.html>)

- -- 
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"

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 4 Jul 2005 14:51:31 -0400 (EDT)

>      is not connected to the Internet).

Rather than "must bear the consequences" (response: "Make me") I
prefer "will bear the consequences" (response: "Oops, I'd better
rethink that choice").

What does "registered [at least] with" mean?  Why does it matter?
(NNTP thinks those _sending to_ me should know my name(s) for
efficiency, but those _receiving from_ me don't have to care who I
claim to be today, do they?)

This appears to say (but doesn't) that the "arbitrary name" isn't an
FQDN that doesn't qualify under (1) or (3), but is used with
permission of the owner of the namespace.

Seth

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Jul 2005 05:07:54 +0200

Charles Lindsey wrote:

> Comments?

> "A" or "AAAA" record, which SHOULD identify the actual host

Why only SHOULD, isn't it a !MISMATCH! otherwise ?

> An encoding of an IP address - <IPv4address> or <IPv6address
> [RFC 3986] which SHOULD, according to the routeing tables
> [Ref needed] identify the actual host, as above.

Maybe delete ", according to the routeing tables [Ref needed]".

Why not a MUST, nobody's interested in an "identity" 127.0.0.1.

> 3. A fully qualified domain name (FQDN) associated with an
>    "MX" record, which MUST be "mailable".

Why did you swap (2) and (3) ?  What's the effect of (3) wrt a
!MISMATCH! ?

>| NOTE: The syntax permits the colon character (which, prior
>| to this standard, was a <path-delimiter>) within a
>| <path-identity>, but only within an <IPv6address>.  It would
>| therefor be unwise to choose, as the arbitrary name,
>| anything composed solely of hexadecimal digits.

   NOTE: The syntax permits the colon character within an
   <Ip6address>, and the colon was handled as <path-delimiter>
   in [RFC 1036] before [s-o-1036].  It would therefore be
   unwise to choose, as an arbitrary name, four or less
   hexadecimal digits, or any name matching an <IPv4Address>.

> "usenet@<FQDN>" and "news@<FQDN>"

<FQDN> is no defined term.

> "abuse@<FQDN>" MUST also be available

<FQDN> is no defined term.  Better get rid of abuse@, the RFCI
rule is that abuse@ must only exist at the "zone cut", and we
will not discuss the finer points of nslookup -q=ns or -q=soa.

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 19:49:12 GMT

>if they are not traditional, then yes

But can you tell me how to define "traditional" as a technical term?

>compliance of some of the oldest systems there are :(

Maybe having used a name for many years past and having it known as yours
to myriads of sites is a sufficient reason for violating a SHOULD.

>this provision seems unnecessary since they aren't creating a problem

And there is Bruce asking me to make it a MUST :-( .

OK, I need to hear more opinions on this one.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 20:45:08 GMT

>Why only SHOULD, isn't it a !MISMATCH! otherwise ?

Yes, but MISMATCHes happen (they SHOULD NOT, of course).

Note that this text is describing how sites should identitfy *themselves*
in the Path. The business of checking and recording MISMATCHes comes
later on in USEPRO.

>Maybe delete ", according to the routeing tables [Ref needed]".

I think something needs to be said there (because what an IP address
identifies within an intranet may differ from what it identifies from
outside, on the public Internet).  Obviously, it was the "public" routing
tables that were meant, but I am still not sure how to express that.

>Why not a MUST, nobody's interested in an "identity" 127.0.0.1.

It's the same as the SHOULD in #1.

>Why did you swap (2) and (3) ?  What's the effect of (3) wrt a

I swapped them to bring the two cases where you identified an actual host
together. What happens in the case of an MX record when it comes to
detecting MISMATCHes is an interesting question. Usually, the actual host
will be a subdomain of the MX record, or something pretty close to that.
So a site that is doing MISMATCH checks will need to build a cache of all
the IP addresses used by the site which owns the MX record. It may be
possible to do that mechanically using reverse lookups, etc. But if the MX
record is not obviously related to the IP address, then either you need
some human assistance with building the cache, or you just label it a
MISMATCH anyway. I see that many of the MISMATCHes currently reported by
DNews sites are like that - they appear not to be MISMATCHes when you look
at them closely, but the admin of the receiving site never looked closely
:-( .

But more to the point, I think that text at least needs to say that the MX
record SHOULD give you a mailable address for the site that sent the
article. I would welcome suggestions for how to express that.

>   hexadecimal digits, or any name matching an <IPv4Address>.

There is no need to mention <IPv4address>es, becaue (see reply to Seth) #4
now excludes anything covered in #1-3. And I don't think it necessary to
mention 1036 etc explicitly, because it is stated elsewhere in the draft
that those were "prior to this standard". And it is not *our* syntax that
permits a colon character within an <Ip6address>. I now have:

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefor be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

><FQDN> is no defined term.

FQDN is defined under #1. But I seem to have omitted to make the change
promised in an earlier reply to you. I now have:

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@" that FQDN and
   "news@" that FQDN, in conformity with [RFC 2142].

and similarly for "abuse@".

>....  Better get rid of abuse@, the RFCI

Eh? Where do you get that rule, and what is a "zone cut"? What I have
written seems perfectly consistent with RFC 2142.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 19:56:20 GMT

>prefer "will bear the consequences" (response: "Oops, I'd better

OK, I buy that.

>claim to be today, do they?)

Yes, I think I got that back-to-front.

>permission of the owner of the namespace.

OK, I now have:

   4.   Some other (arbitrary) name believed to be unique and registered
        at least with all other news-servers sending articles directly
        to the given one. The news-server administrator is responsible
        for choosing an appropriate name (and will bear the consequences
        of an inappropriate choice). This option SHOULD NOT be used
        unless the earlier options are unavailable (e.g. because the
        host in question is not connected to the Internet).

That probaly still needs further work, particularly regarding the SHOULD NOT.

---

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

>Header fields.

Yes, Yes. That will get fixed when I do my grand trawl throught the whole
of USEPRO to change those cases.

>What about Xref?

I don't think it really matters for Xref, though one would normally expect
it to be the same. The MUST for the opther two cases is there to give less
scope for trolls and malefactors.

>for IP addresses which cannot be routed (RFC 1918).

It is clear that routers on the Internet are configured to route packets
to the sites which officially own the IP addresses as allocated by the
processes established by ICANN. What happens on private routers within
intranets is another matter of course. So the concept we need is clearly
there - just a matter of how to express it. I presume there exists some
RFC that specifies how it is all done, so I would be grateful if someone
can point me at it, or explain how best to get the intended concept
across.

>therefore s/SHOULD NOT/MUST NOT/, at least for IPv6.

No, I belioeve the general view here is that the possible glitch is so
minor that we do not need to say that. I have added a NOTE warning sites
to avoid the problem.

>Perhaps combine with #1, probably also allow CNAMEs.

No, because an MX record does not identify a host, though it ought to
identify the administrators of the host in question. Maybe that should be
expressed somehow.

As for CNAMEs, they have never been included in our earlier drafts, but I
see no reason why they should not be included in #1. Would anybody else
have a problem with that?

>But not registered with senders?

I think you may be right there, but I see somebody else has raised it, so
I will deal with it when replying to him.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 05 Jul 2005 19:32:12 -0700

Charles Lindsey <[email-masked]> writes:

> I swapped them to bring the two cases where you identified an actual
> host together. What happens in the case of an MX record when it comes to
> detecting MISMATCHes is an interesting question. Usually, the actual
> host will be a subdomain of the MX record, or something pretty close to
> that.  So a site that is doing MISMATCH checks will need to build a
> cache of all the IP addresses used by the site which owns the MX
> record. It may be possible to do that mechanically using reverse
> lookups, etc. But if the MX record is not obviously related to the IP
> address, then either you need some human assistance with building the
> cache, or you just label it a MISMATCH anyway.

I would expect most (successful) mismatch handling to be done via manual
configuration.  It's common practice to exchange path identities when
setting up peering relationships.  The path identity can then go into a
configuration file associated with the authentication information for the
peer and any peer that authenticates according to that information will
not be marked with mismatch if it uses that path identity.

That very simple system would be sufficient for the degree of security
warranted here.

> and similarly for "abuse@".

Given the amount of crap such mailboxes receive these days, I think you're
fighting a lost battle by trying to perpetuate RFC 2142.  It's a nice idea
that's very hard to implement in practice without taking up an immense
amount of time.  We stopped allowing external mail to
[email-masked] a while back (need to do something about the
backscatter as soon as I can find a free moment), and I think I'm the only
person left who even looks at [email-masked] (and I use an
incredibly aggressive killfile to process it).

I read news and usenet, after bogofilter, but I bet a lot of sites don't,
and it's getting increasingly hard to justify requiring it.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 05 Jul 2005 19:37:28 -0700

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

>>>    An injecting agent MUST identify itself with the same
>>>    <path-identity> in both Path and Injection-Info

> I don't think it really matters for Xref, though one would normally
> expect it to be the same.

The path-identity in Xref serves no protocol purpose and is only there as
a form of human-readable documentation and debugging information.
Accordingly, not using the same path identity can't actually break
anything.  I think it's a SHOULD to avoid confusion.

> there - just a matter of how to express it.

Why not just forbid RFC 1918 addresses?

> identify the administrators of the host in question. Maybe that should
> be expressed somehow.

Why are requiring that there be an MX record for the path identity rather
than just requiring that it be mailable?  Suppose I want to use for my
path identity the name of the system that handles mail for my domain, for
some obscure reason?  It doesn't need an MX record -- it *is* the mail
server.  Everything still works.

> As for CNAMEs, they have never been included in our earlier drafts, but
> I see no reason why they should not be included in #1. Would anybody
> else have a problem with that?

I'm in favor of making that change.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 05 Jul 2005 19:48:20 -0700

Russ Allbery <[email-masked]> writes:

> The path-identity in Xref serves no protocol purpose and is only there
> as a form of human-readable documentation and debugging information.

Oh... *heh*.  I just realized that using a Path identity of:

    example:34

as the path-identity in Xref could break various things in rather
interesting ways.  Mostly just because of simplified coding taking
advantage of the fact that colons do not appear in the path identity,
since it's frequently desirable to just quietly skip any malformed Xref
header entries, and once you've done that, why skip the path identity
specially rather than just letting the same code handle it?

No valid IPv6 address would have only a single colon, however.

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 5 Jul 2005 22:50:39 -0400 (EDT)

> Why not just forbid RFC 1918 addresses?

Not strong enough; what about sites that use other people's addresses
internally?  (Sure, they're not supposed to; but we don't want them
putting those addresses on the path even if they do.)

> Why are requiring that there be an MX record for the path identity
> rather than just requiring that it be mailable?  Suppose I want to
> use for my path identity the name of the system that handles mail
> for my domain, for some obscure reason?  It doesn't need an MX
> record -- it *is* the mail server.  Everything still works.

Does it?  Some mailers insist on MX records, and won't mail to A
records.  (That seems to be happening, anyway.)

Seth

---

From: Russ Allbery <[email-masked]>
Date: Tue, 05 Jul 2005 20:20:55 -0700

> records.  (That seems to be happening, anyway.)

Please do tell.  Such a mailer would be completely unable to send mail to
multiple systems that I run, including the mailing list management system
that hosts the IETF NNTP working group, but I have never heard a single
complaint.

Such a mailer would also be in blatant violation of RFC 2821:

   [...]
   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found instead, the resulting name is
   processed as if it were the initial name.  If no MX records are found,
   but an A RR is found, the A RR is treated as if it was associated with
   an implicit MX RR, with a preference of 0, pointing to that host.
   [...]

I have no intention of adding MX records for systems that don't need them.
It's just DNS noise.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 6 Jul 2005 00:24:44 -0400

> scope for trolls and malefactors.

BCP 14 says nothing about "trolls and malefactors".  The requirements
for use of MUST appear in BCP 14 section 6 (Frank, that's RFC 2119).

> I would be grateful if someone
> can [...] explain how best to get the intended concept
> across.

"Sites MUST NOT use an IP address except for diagnostic purposes in
conjunction with the MISMATCH keyword."

> No, because an MX record does not identify a host,

That unsupported assertion is a falsehood.  RFC 974:

   Each MX matches a domain name with two pieces of data, a
   preference value (an unsigned 16-bit integer), and the name of a
   host.  The preference number is used to indicate in what order the
   mailer should attempt deliver to the MX hosts, with the lowest
   numbered MX being the one to try first.

Note the words "host" and "hosts", the latter occurring in "MX hosts".

> though it ought to 
> identify the administrators of the host in question.

Having just finished claiming that MX records do not identify hosts,
you then proceed to make another unsubstantiated claim about "the
administrators of the host" -- which "host" would that be; the one
that the MX record supposedly has nothing to do with?

> Maybe that should be 

No, we should stick to truth and sensible statements.  And, we don't
need the department of redundancy department; since MX records are at
the very heart of mail delivery and the DNS is a rooted tree hierarchy,
of course the domain name associated with an MX host is "mailable"
and fully qualified.  The Instructions to Authors document says "To
simply specify a necessary logical relationship; the normal lower-case
words should be used" rather than capitalized BCP 14 keywords such as
MUST.

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 5 Jul 2005 23:41:14 -0700

>    numbered MX being the one to try first.

From this quote, I understand that an MX "domain" does NOT identify "a
host" but rather a semi-ordered "set of hosts", any one of which could be
the actual recipient of an email to the MX "domain".

Does you mean that only one of the hosts in such a "set of hosts" may run a
news relay?

-- 
Bill McQuillan <[email-masked]>

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Wed, 6 Jul 2005 09:00:46 +0200

Russ Allbery:

> [abuse@]
> Given the amount of crap such mailboxes receive these days, I think
> you're fighting a lost battle by trying to perpetuate RFC 2142.  It's
> a nice idea that's very hard to implement in practice without taking
> up an immense amount of time.

All mail to postmaster@ and abuse@, and then some, should be accepted.
But there can be no guarantee that it will all be read. With a
combination of RBL/DNSBL (not to SMTP-reject, but to tag the message),
and SpamAssassin, and limited whitelisting, for example, you can sort
that mail rather effectively. Any Sender should make sure to send from a
host that is known not to be listed in the important BLs.

A hole in this, is that spammers can start sending spam with postmaster@
between the recipients of all messages, for every domain of the other
recipients, to prevent RBL/DNSBL. So who uses RBL/DNSBL even for
messages addressed to postmaster/abuse/etc., has my blessing. There is a
very small risk that you will end up in the zones of
http://www.rfc-ignorant.org/ but that will most likely only happen if
you are unlucky with your choice of RBL/DNSBL-sources.

So no, I don't agree it's a lost battle. It shouldn't take up extra
time, as the line of defense is very much the same as with any other
address.

-- 
Grtz, Ruud

---

From: Russ Allbery <[email-masked]>
Date: Wed, 06 Jul 2005 00:36:00 -0700

> time, as the line of defense is very much the same as with any other

There's just almost no actual signal and an order of magnitude more junk.
I appreciate the desire to do the right thing, and I'm not speaking from a
perspective of what I do personally.  I'm just saying that from a
practical standpoint, I think the handwriting is already on the wall, even
if us clued folks can deal with the noise.

Given that we get maybe one legitimate message to postmaster every couple
of weeks, it's hard to justify the time and effort required to make it
readable.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 6 Jul 2005 09:06:50 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>But can you tell me how to define "traditional" as a technical term?

you don't -- what you say is something along the lines of what Harald
wrote; which was that the requirement is for uniqueness, that an FQDN is
the only thing that will now have a good chance of providing that
property; but that nevertheless some existing sites have a working
scheme, loosely based on the UUCP maps and that this means that they
have to ensure that their direct peers are aware of this

viz: you are more descriptive and less proscriptive

I can attempt words if you'd prefer; but Harald's already done that and
you don't seem to used many of them. Nevertheless I will try if you
think that it would be useful

>to myriads of sites is a sufficient reason for violating a SHOULD.

mayhap, but it still reduces the level of compliance that can be claimed
and since nothing has broken why is it necessary to, effectively,
disparage their activity ?

- --

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 6 Jul 2005 11:02:50 GMT

>configuration.

I agree. But sites with lots of peers might try to automate the process.
And they might also automate some procedure for dealing with peers who
suddenly start using a new path-identity without telling them (e.g. they
suddenly bring an additional server with a brand new IP address on
stream).

>amount of time.

Yes, abuse of abuse addresses is a great shame. But if some site somewhere
(especially an injecting agent) is configured in such a way as to be
causing loops or spews or whatever, then it is highly desirable for
someone to be able to mail usenet@ that site what is going on (because it
may not have noticed the effects itself). If that site does not accept
mail to the RFC 2142 addresses, they you have to start chasing it through
its peers, and that soon gets very complicated.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Jul 2005 17:12:26 +0200

Bruce Lilly wrote:

> BCP 14 section 6 (Frank, that's RFC 2119).

Yep, thanks.  

> "Sites MUST NOT use an IP address except for diagnostic
>  purposes in conjunction with the MISMATCH keyword."

So that's Harald's idea.  Okay, then extracting all IPs
from the <path-identity> syntax could make sense.  Maybe
we could also split "traditional name" from mailable FQDN:

FQDN is the normal ldh-string stuff as in 2396, at least
one dot, toplabel, no underscore, with news@ and usenet@.  

"Traditional name" has no dots, it can have underscores.
IP only to the left of !MISMATCH!, but not elsewhere (?)

>> an MX record does not identify a host,

It doesn't identify "the" host in question, only "a" host.
Actually a strange idea, why do we need to sanction this ?
Is it just another case of a "traditional name" ?

> of course the domain name associated with an MX host is
> "mailable" and fully qualified.

ACK, but I don't see the point of using the MX at all, if
that's a trick for UUCP hosts at most one of these hosts
behind the same MX can use it, otherwise they'd clash.  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Jul 2005 17:30:44 +0200

Russ Allbery wrote:
 
> The path-identity in Xref serves no protocol purpose and is
> only there as a form of human-readable documentation and
> debugging information.

You could (ab)use it to construct nntp-URLs.  It doesn't work
with my browser, maybe your UA can handle it:

Xref: news.gmane.org gmane.ietf.usenet.format:29444

<nntp://news.gmane.org/gmane.ietf.usenet.format/29444> or
<nntp://news.gmane.org/gmane.ietf.usenet.format:29444> 

Not a general concept, but essentially the same idea:

<http://article.gmane.org/gmane.ietf.usenet.format/29444>

> Accordingly, not using the same path identity can't actually
> break anything.  I think it's a SHOULD to avoid confusion.

Depends, you have some strange ideas about "Xref-slaving",
I have funny visions about nntp-URLs, and Charles wants a
"wildmat" in news-URLs only because you said it's cute ;-)

                       Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 6 Jul 2005 11:47:57 GMT

>putting those addresses on the path even if they do.)

Well it's a start. I now have:

   2.   An encoding of an IP address - <IPv4address> or <IPv6address> - 
        [RFC 3986] which SHOULD be a publicly recognized address [RFC
        1918] for the actual host, as above. This option SHOULD NOT be
        used if an FQDN for that host is available.

which I think is getting nearer, but probably still needs more work.

>records.  (That seems to be happening, anyway.)

I am sure I have read somewhere that, if you want your A record to receive
mail, you are supposed to create an MX record as well, although the A
record SHOULD work if you do not.

Looking further, I think it was RFC 2821 - section 5 seems the most
relevant.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 6 Jul 2005 11:55:15 GMT

>anything.  I think it's a SHOULD to avoid confusion.

Not entirely convinced, but I have now put such a SHOULD there:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers, and a serving agent SHOULD use the same <path-identity> in
   both Path and Xref headers.  To ensure that a <path-identity>
   provides a unique identity for the news-server concerned, it should
   be one of:

Are people happy with that?

   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record (or an equivalent "CNAME"), which SHOULD identify
      the actual host inserting this <path-identity> and, ideally,
      should also be "mailable" (see below).

Is that OK?

---

From: Russ Allbery <[email-masked]>
Date: Wed, 06 Jul 2005 09:21:48 -0700

> Depends, you have some strange ideas about "Xref-slaving",

Which doesn't use the path identity.

> "wildmat" in news-URLs only because you said it's cute ;-)

Charles (and I) want wildmat in news URLs because existing browsers
already support them and the behavior is useful.

---

From: Henry Spencer <[email-masked]>
Date: Wed, 6 Jul 2005 19:38:35 -0400 (EDT)

On Tue, 5 Jul 2005, Russ Allbery wrote:
> multiple systems that I run...

Alas, this seems to be for real... although fortunately it's not common. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Russ Allbery <[email-masked]>
Date: Wed, 06 Jul 2005 16:46:02 -0700

> Alas, this seems to be for real... although fortunately it's not common. 

Personally, I'm content for such broken software to simply lose when
attempting to contact a news server administrator to report problems.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Jul 2005 05:07:34 +0200

Russ Allbery wrote:

> Charles (and I) want wildmat in news URLs because existing
> browsers already support them and the behavior is useful.

IBTD.  It's very different from the original URL, and I've no
convincing ideas where I would want a subset of newsgroups in
a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

But all the other wild and woderful constructs in a news URL,
who needs this, which UAs support it ?  "?" has to be encoded
as %3E.  Comma, backslash, or exclamation mark are also very
different from RfC 1738, and maybe backslash must be encoded.

STD 66 is not exactly straight forward about some characters,
backslash is one of these cases where I'm not sure.  And it
is an unnecessary pain, no newsgroup name contains e.g. ? and
so \? and the six others \\, \!, \*, \, \[ \] are not needed.

                         Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Wed, 06 Jul 2005 20:18:00 -0700

> a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

Right, this is the part that I care about.

> as %3E.

Does it?  I thought it did too, but then when I looked I couldn't find any
provision that would actually require it.

> Comma, backslash, or exclamation mark are also very different from RfC
> 1738, and maybe backslash must be encoded.

Personally, I don't really care if all that stuff works.  I just want * to
work, and with the standard semantics, but including wildmat by reference
is a straightforward way of doing that without repeating the
specification.  As you say, I'm not aware of an implementation that
supports ?, !, or comma.

\ is not allowed in wildmats except as part of an INN extension, so you
don't have to worry about it for URLs.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 7 Jul 2005 11:00:41 GMT

>viz: you are more descriptive and less proscriptive

All right:

   4.   Some other (arbitrary) name believed to be unique and registered
        at least with all other news-servers sending articles directly
        to the given one. The news-server administrator is responsible
        for choosing an appropriate name (and will bear the consequences
        of an inappropriate choice). This option SHOULD NOT be used
        unless the earlier options are unavailable (e.g. because the
        host in question is not connected to the Internet), or unless it
        is of longstanding usage and cessation would be unduly
        disruptive.

That's a bit like Harald's reference to "existing" newsgroup-names with
all-digit components, and the like.

---

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

>for use of MUST appear in BCP 14 section 6 (Frank, that's RFC 2119).

But it says you may use MUST wording to avoid causing harm (such as
potential security problems).

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 07:55:58 -0400

> the actual recipient of an email to the MX "domain".

Each MX record identifies a host (by domain name) and associates an
integer preference value with that host for Mail eXchange purposes.

In a nutshell, mail delivery works with MX resource records as follows:
1. look up MX records for the domain name associated with a mailbox
2. each MX record identifies a host which accepts mail for that domain and
   gives a preference value
3. the sender removes its own host name if present in the list, then
   attempts to contact MX hosts in order of preference

Example:
# nslookup -sil -type=mx ietf.org. ns2.cw.net.
Server:         ns2.cw.net.
Address:        204.70.57.242#53

ietf.org        mail exchanger = 10 ietf-mx.ietf.org.
ietf.org        mail exchanger = 20 mx2.foretec.com.

That lists 2 MX records for the domain ietf.org.  The two MX hosts
are ietf-mx.ietf.org and mx2.foretec.com:
Name:   ietf-mx.ietf.org
Address: 132.151.6.1

Name:   mx2.foretec.com
Address: 65.246.255.50

> Does you mean that only one of the hosts in such a "set of hosts" may run a

No, but the uniqueness requirement and the desirability of making 
diagnostic checks (e.g. for MISMATCH) workable means that each
host needs to use its own host name (which also has an A record).

It probably wouldn't be a good idea to run a news relay and an
SMTP MX MTA on the same host anyway; both services use a lot of
resources.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 7 Jul 2005 11:43:35 GMT

>a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

A bit off topic for this group, but never mind.

"news:*.test" is the example I usually give.

>different from RfC 1738, and maybe backslash must be encoded.

There is no need to encode "?" according to my draft.

There is never a requirement to encode "\" in RFC 3986, and not for "," or
"!" unless some scheme goes out of its way to require it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 7 Jul 2005 11:47:35 GMT

>if us clued folks can deal with the noise.

I agree with Ruud. We should try to continue to support RFC 2142.

>of weeks, it's hard to justify the time and effort required to make it

Maybe that's because your mail service is so well run that nobody ever has
to complain about it :-) .

---

From: Richard Clayton <[email-masked]>
Date: Thu, 7 Jul 2005 12:56:59 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>        is of longstanding usage and cessation would be unduly

addresses my point, thanks

for preference I'd remove the second sentence altogether, it adds
nothing of any real significance

- --

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 7 Jul 2005 11:33:08 GMT

>we could also split "traditional name" from mailable FQDN:

It is clear that IP addresses DO occur in Paths for a variety of reasons,
and will continue to do so (and that will inevitably include IPv6
addresses when servers start to use them). These occurrences do not
necessarily indicate MISMATCHes, though I agree that a lot of them are
diagnostic. I doubt current relaying agents treat them any differently
than other path-identities (i.e. if you write in your "sys" file "do not
relay to this IP address", then an article with it already in its Path
won't get relayed).

So there is no interoperability that is going to arise to justify that
MUST NOT; so it seems like a classic case of SHOULD NOT to me - recipients
must not choke on them it they appear, but they still should not be used
because (nearly always) there are better alternatives.

But there is a general expectation throughout the Internet (reinforced by
provisions in many standards) that an IP address can be used in any
context where a domain-name can be used. It may be unwise, and cause for a
SHOULD NOT, but I do not think it should be forbidden entirely.

And the remote possibility of problems labelled "dead" or "beef" will
still be there, even if IPv6 addresses are only used for diagnostic
purposes, so the NOTE after #4 to warn against that is still needed.

>"Traditional name" has no dots, it can have underscores.

Actually, the syntax (both Harald's version or mine) is ambiguous; that
needs to be fixed (probably by a comment after ';' in the ABNF).

>behind the same MX can use it, otherwise they'd clash.

It's nothing to do with UUCP at all. If the actual entry in the Path is
"newshost-5.example.com", it may be that that actual host does not listen on
Port 25. Therefore the admin may well prefer to put just "example.com" as
his path-identity, where "example.com" is an MX pointing to
mailhost.example.com (which understands what to do with "news@",
"usenet@", and even "abuse@").

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 08:34:51 -0400

> potential security problems).

To be precise, it says "MUST only be used", not "may".   The cases where
an imperative causes harm is illustrated by the case of retransmissions.
Security matters are discussed in BCP 14 section 7, where the additional
onus is placed on a specification writer: "Document authors should take
the time to elaborate the security implications of not following
recommendations or requirements as most implementors will not have had
the benefit of the experience and discussion that produced the 
specification".  Note that the section 6 requirement discusses harm to
the Internet (retransmissions consume everybody's bandwidth), not harm
(security-related or otherwise) which might affect only a non-conforming
system.  Section 7 considerations apply to recommendations as well as
to imperatives.

When you wish to justify use of a BCP 14 imperative, kindly do so
in terms which BCP 14 covers in section 6, with documentary support
for any assertions that you make.  Lacking any supported justification,
at most a recommendation would be warranted.  If you wish to invoke a
security consideration, please also "elaborate the security implications",
preferably in the form of text suitable for inclusion in the document.

And the reason for "MUST" in the proposed text is...? [note that
Injection-Info's defined semantics are for tracing; it plays no role
in protocol or interoperability. also note that BCP 14 section 6
specifically states that imperative keywords "must not be used to try
to impose a particular method on implementors where the method is not
required for interoperability"]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 09:20:57 -0400

>         is of longstanding usage and cessation would be unduly

All wrong:
a) a belief of uniqueness and uniqueness are two different things.
   Uniqueness is supposedly a requirement, not a mere nicety.
b) "arbitrary" is incorrect; "a!b:c^d@e%f" won't work.
c) while you have added senders, you have removed receivers, and that
   could cause retransmissions, which is harmful. "neighbors" might
   cover both, but might warrant a full explanation at first use.
d) in the case of retransmission, the consequences are also borne by
   the receiving system, so "will bear the consequences" is incorrect
   as it stands.
e) being connected to the Internet is not a requirement for having a
   domain name, and the scope of our documents is the Internet, as it
   is supposed to be an Internet Standards Track specification for a
   format and protocol suite for use on the Internet; what non-Internet
   sites do or do not do is out of scope.
f) the last phrase is vague -- does 1 month count as "longstanding usage";
   it's longer than the TTL of most DNS responses?   In view of the
   uniqueness *requirement*, how much disruption constitutes "unduly
   disruptive"?  We are supposed to be writing a clear specification,
   and we cannot do so using such vague terms as vague is the opposite
   of clear.

We should restrict names to fully-qualified domain names for the purpose
of this specification.  The specification might warrant a note about
names associated with non-Internet sites that leak onto the Internet in
a Path field as the result of a link between a non-Internet site and an
Internet site.

We might possibly go so far as to make such Internet sites responsible
for the uniqueness of their connected non-Internet neighbors, and we
could do so for example by using '@' as the Path separator for Internet
sites, using '!' or '%' for UUCP sites connected to an Internet site,
':' for DECnet sites etc., which is basically how RFC 850/RFC 1036 paths
are formed.  For example, "FQDN.example.net!wolf!hither!yon" in Path,
considering @ as the Internet delimiter means that an article passed
onto the Internet at site FQDN.example.net, which received it from its
neighbor known as "wolf", etc. for tracing purposes.  For abuse-reporting
purposes, as there is no way to contact the administrators of "wolf",
"hither" or "yon" from the Internet, abuse complaint forwarding would
be handled by FQDN.example.com, who presumably knows how to contact
the administrators of "wolf", who presumably know how to contact the
administrators of "hither, etc.   While I could support something like
that, I think it goes farther than is necessary for an Internet
Standards Track specification, as abuse reporting is an operational
issue rather than a technical specification matter.  It might be
something for USEAGE.  If we intend to go that route, we should
consider the syntax, semantics, and protocol implications now, since
our immediate task is finishing the syntax and semantics document.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 13:58:08 -0400

> All mail to postmaster@ and abuse@, and then some, should be accepted.

Postmaster, MUST.  The others, maybe (RFC 2142 in 8 years at Proposed
hasn't gathered enough traction (a mere *two* implementations) to
advance to Draft).

None of which has any relationship to the Path field, and none of which
is necessary; the Injection-Info field has provision for indicating
where complaints should be sent, and if a site wants complaints to be
sent to "[email-masked]" rather than some mailbox with "abuse" in
the local-part, or to a mailbox with a local-part of "misbruik" instead
of "abuse", that's arguably their business.  If anybody actually goes
through the trouble to manually extract that optional information from
that optional field, they can send complaints to the suggested place.

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jul 2005 11:22:07 -0700 (PDT)

> hasn't gathered enough traction (a mere *two* implementations) to

I read less than nothing into this. The problem here isn't that there are
insufficient "implementations" of RFC 2142 - I can name at least a dozen
different mail system implementations that provide everything that's needed for
a site to conform to every recommendation RFC 2142 makes.

Rather, te problem is that RFC 2142 is misclassified as proposed standard when
it should be a BCP. It specifies operational policies for mail systems having
certain characteristics. It doesn't specify a protocol, message format, or
anything similar, and as far as I can tell it imposes no requirements on mail
system software that aren't already imposed by other standards-track documents.
This makes it next to impossible to construct a meaninfgul set of conformance
criteria, and absent such a set of criteria to measure implementations against
I see no way to advance the document to draft.

Of course it is a separate question as to whether or not the recommendations
RFC 2142 makes are actually Best Current Practice. I tend to think they're
pretty close, but others may disagree.

But given how contentious even the simplest mail system operational
specifications have become in the IETF, I can also understand there being
no interest in reclassifying this document or, if you believe it truly
belongs on the proposed-draft-full track, advancing it.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 15:52:55 -0400

On Thu July 7 2005 14:22, Ned Freed wrote:

> I can name at least a dozen

Maybe; one problem is that it's unclear exactly what is a recommendation
and what is supposed to be a requirement.  The document uses MUST and
RECOMMENDED (but w/o reference to RFC 2119), also "must" and phrases
like "need to".
[...]
[...]
> belongs on the proposed-draft-full track, advancing it.

In its present form, it cannot be advanced.  At minimum it would need a
new I-D with a normative reference to BCP 14 and a substantial rewrite
to clarify requirements vs. recommendations.  And that might or might
not warrant recycling at Proposed.  It would also need to have the
references classified into normative vs. informative and updated to
current documents (most are obsolete).  The security considerations
section would need work.

Reclassification as Historic would seem feasible...at one time there
was supposed to have been an effort towards bulk reclassification of
documents stuck at PS or DS ("cruft") to historic.

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jul 2005 12:58:04 -0700 (PDT)

> RECOMMENDED (but w/o reference to RFC 2119), also "must" and phrases

This document predates by a considerable margin the requirement that these
terms be precisely defined. (In fact it is pretty likely it was approved for
publication before RFC 2119 existed to refer to.)

This is also why the document didn't end up as a BCP - at the time it wasn't
entirely clear when to use BCP and when not to.

> In its present form, it cannot be advanced.

This is true of the majority of documents we deal with, if for no other reason
than the references need updating and splitting.

> At minimum it would need a
> not warrant recycling at Proposed.

The only thing that would warrant keeping this as proposed and not moving it to
BCP is if it came to specify an actual protocol or format. Since it specifies
nothing of the sort now it is axiomatic that this would be new material and
would require recycling. 

> It would also need to have the

> Reclassification as Historic would seem feasible...

I for one would strongly object to any such attempt. I believe this document
specifies useful operational policies.

> at one time there

When the effort started I predicted it would at best be marginally successful,
and I was proved right - only a few documents got reclassified. We have a large
number of documents for which the collective will to update doesn't seem to
exist, yet the documents clearly have a constituency behind them. I don't see
this changing, indeed, as the BS requirements continue to pile up, it is only
going to get worse.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 03:08:33 +0200

> A bit off topic for this group, but never mind.

Strictly within the Charter:

| The Group shall also aid and/or oversee the production of
| other Usenet related Internet Drafts and Standards.

For unclear reasons (maybe caused by a Reply-To: [email-masked])
one related article never made it to this list:

<http://article.gmane.org/gmane.org.w3c.uri/545/raw>

> "news:*.test" is the example I usually give.

That matches Russ' idea, integrate * into the syntax, which
is in theory backwards compatible with draft-gilman-news-02

> There is no need to encode "?"

It's "reserved" according to RfC 1738, 2396, 3986 (STD 66),
whatever that means.  And in fact my UA has its own ideas
about stuff like ?part=1.2 in conjunction with an article.

> There is never a requirement to encode "\" in RFC 3986

You have to read it several times to find that it simply
does not mention the characters DQUOTE, "<", ">", "\", "^",
"`", "{", "|", "}" - nowhere.  Whatever the rule for a "\"
might be,, it's the same as for "<", ">", DQUOTE etc.

                         Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 05:02:45 +0200

Charles Lindsey wrote:

> IP addresses DO occur in Paths for a variety of reasons

Rarely, as you found.  But if Bruce and others think that IPv6
is a serious problem, and if we don't want to ue the "replace
all colons by underscore" hack, getting rid of domain literals
completely is a option.

In the traditional sense as bang-path there should be no IPs,
or at least it would surprise me if that worked as expected.

> These occurrences do not necessarily indicate MISMATCHes,

That was apparently Harald's "diagnostic" proposal, but I doubt
that it would change anything for Bruce's dead::feed objection.

> there is a general expectation throughout the Internet
> (reinforced by provisions in many standards) that an IP
> address can be used in any context where a domain-name
> can be used.

Not in the mail world, they'd want at least square brackets.
John already rejected the dubious idea to relax the 2821bis
syntax in this context.  Otherwise, yes...

> I do not think it should be forbidden entirely.

...but apparently Bruce and others disagree.  My favourite
STRONGLY DISCOURAGED found in STD 11 is (again apparently)
not good enough for all.  I can't judge what's worse

But sometimes you say "a MUST declaring each and every
existing UA on the planet non-conformant is no problem",
so why is this IP in <path-idetiy> case different ?

> the NOTE after #4 to warn against that is still needed.

You could at least limit it to four or less hex. letters,
feedcafe is fine.

> Actually, the syntax (both Harald's version or mine) is
> ambiguous; that needs to be fixed (probably by a comment
> after ';' in the ABNF).

At the moment you both don't distinguish 2821-FQDN vs. any
traditional name (and the old 2821 syntax will be slightly
modifified in 2821bis).  Vague idea ignoring the IPs for
the moment:

  path-identity = hostname / obs-name
  hostname      = 1*( domainlabel "." ) toplabel
  domainlabel   = alphanum [ *( alphanum / "-" ) alphanum ]
  toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
  alphanum      = ALPHA / DIGIT
  obs-name      = alphanum *( alphanum / "-" / "_" )

With that syntax "mailable hostname" is clear, you could just
say news@<hostname> or similar instead of using ews@<FQDN>.

> If the actual entry in the Path is "newshost-5.example.com",
> it may be that that actual host does not listen on Port 25.
> Therefore the admin may well prefer to put just "example.com"
> as his path-identity, where "example.com" is an MX pointing
> to mailhost.example.com

Why doesn't he add MX or CNAME for this effect, or is this a
way to get a single <path-identity> for several hosts ?  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 08:20:50 +0200

Charles Lindsey wrote:
 
> We should try to continue to support RFC 2142.

No problem with chapter 1, but less obvious with chapter 2,
i.e. abuse@

If you have a <path-identity> news.example.com then it's
okay to expect [email-masked] 

  BTW, I never got the idea why it's usenet@ _and_ news@,
  and did the new RfC 977bis drop both addreses ?

Back to news.example.com, probably a host in the zone of
example.com, then RfC 2142 only demands [email-masked]
and [email-masked] might not exist.  That's also
the RFCI (rfc-ignorant.org) listing policy, see below,
we should not invent new abuse@ rules conflicting with
RfC 2142 and RFCI.
                     Bye, Frank

Listing policy <http://rfc-ignorant.org/policy-abuse.php>

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Jul 2005 10:52:25 GMT

>Rarely, as you found.

4% is hardly rare. The fact that it was made up of all sorts of different
usages does not alter the fact that it happened.

>But if Bruce and others think that IPv6

But I don't think you can suddenly chop off 4% of existing asage, and when
used for diagnostic purposes, IP addresses (including MISMATCHes) could be
considered quite sensible.

>that it would change anything for Bruce's dead::feed objection.

Indeed. Allowing them for diagnostic purposes does nothing for the
dead:beef problem, so if you are going to allow them for diagnostics, then
you may as well allow them for everything, but with a SHOULD NOT because
there are usually better ways. Indeed, I currently have SHOULD NOT for
both the IP and arbitrary-name cases, which is at least a consistent
approach.

>not good enough for all.

The "SHOULD NOT"s in the present text are actually stronger than your
"STRONGLY DISCOURAGED".

>You could at least limit it to four or less hex. letters,

Already done that. Perhaps it is time to repeat my whole text as it
surrently stands, in view of various recent changes:

 
   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] - which SHOULD be a publicly recognized address [RFC 1918]
      for the actual host, as above. This option SHOULD NOT be used if
      an FQDN for that host is available.

   4. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. The news-server administrator is responsible for
      choosing an appropriate name (and will bear the consequences of an
      inappropriate choice). This option SHOULD NOT be used unless the
      earlier options are unavailable (e.g. because the host in question
      is not connected to the Internet), or unless it is of longstanding
      usage and cessation would be unduly disruptive.

   "abuse@" that FQDN MUST also be available, unless a more specific

[I still think that mention of RFC 1918 needs more thought.  Also, is one
allowed to have a CNAME pointing to an MX record (RFC 2821 seems to think
so), in which case should I be mentioning CNAMEs in #3?]

>way to get a single <path-identity> for several hosts ?

It could indeed lead to a single <path-identity> for a farm of hosts (and
I don't necessarily think that is a bad thing). Alternatively, I suspect
that some servers actually insert two entries, one identifying the actual
host, and the other the MX record for contact. For sure, one often sees 3
or more entries from a given site, and I am not sure it always means it
actually passed through 3 hosts on that site.

Path: [email-masked]!example.com!newsin-3.example.com!...

Also, I suspect that some sites, such as "demon", add that as an arbitrary
name in the midst of the bunch, simply because there are thousands of
sites out there which wrote "demon" into their sys files yonks ago.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Jul 2005 10:13:28 GMT

>>        of an inappropriate choice). .....

>nothing of any real significance

Some people profess great concern that we have not provided a way to
enforce the uniqueness of these names.

That sentence is just a polite way of saying "Yes, we know that the
uniquesness is not enforceable. Tough!".

---

From: Richard Clayton <[email-masked]>
Date: Fri, 8 Jul 2005 12:12:57 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>enforce the uniqueness of these names.

it is of great concern ... which is why it isn't being recommended for
anyone who hasn't been using the name for decades... (or as someone
said, several months, by which time the drawbacks of an error will be
obvious or will be being lived with)

Once again I repeat my suggestion of stressing what is to be achieved
and removing (or toning down) the tedious detail about the myriad ways
of managing to reach the goal

>uniquesness is not enforceable. Tough!".

we could add similar sentences to almost every paragraph. However, since
the sentence is wrong (I expect the administrator has been told to use
the name by the people who set up the company in the late 1980s and see
no reason to change (and thereby annoy their customers)) and also since
they will not necessarily see any consequences of an inappropriate
choice (the users of the server may have slightly less propagation of
their articles, but may never realise) then the sentence would need
rewriting to be accurate...  hence my suggestion of dropping it.

- --

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Jul 2005 13:07:42 GMT

>>That s[last] entence is just a polite way of saying "Yes, we know that the

>rewriting to be accurate...  hence my suggestion of dropping it.

I don't see what is wrong. It is not our job to define precisely who is an
"administrator". So far as the standard is concerned it is whoever gets to
make the decisions, and if that goes all the way up to the Managing
Director of Thus plc (or Scottish Telcom, if they are still in the chain),
then that is their problem. If the administrator (he, they, it) becomes
aware that there is another site using the name "demon" (perhaps only in
some obscure hierarchy in Outer Mongolia), then he either has to persuade
the Mongolians to change, or he has to annoy his customers, or he has to
risk losing some articles. All that is part of "bearing the consequences".

Now we all know that there is NO One and Perfect solution to this problem.
There is No Cabal to fix it (and we don't want to establish no cabal).

However. Bruce is bending my ear to the effect that we MUST provide some
mechanism to ensure the uniqueness of these names, or alternatively we
MUST document the lack as a "known technical omission". I don't think we
can ignore the matter entirely, and the words I wrote were intended to
indicate the presence of a "known technical omission". But I am not wedded
to those words; if anyone can suggest some alternative way of pointing out
the limitations of the existing setup, then let us have it.

---

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

>No problem with chapter 1, but less obvious with chapter 2,

You should try reading news.admin.net-abuse.email (the corresponding
.news. group is mostly full of trolls and spam). The people there take a
very dim view of ISPs who do not provide the RFC 2142 abuse@ address. In
our case, we allow them to select a different abuse address in
Injection-Info, so there is no excuse for them not to provide the default
abuse@ if they have neglected to specify an alternative.

>  and did the new RfC 977bis drop both addreses ?

Pure history :-( .

>and [email-masked] might not exist.

Indeed, which is why, as an injecting agent, it SHOULD/MUST put
example.com as its path-identity.

However, it might make sense to put both (if it wants to record which
server belonging to its farm actually handled the article).

So should we allow a site to insert two <path-identity>s if it wants to?
That is currently sort-of deprecated, but is easily changed and would give
extra flexivility for various purposes (e.g. for "demon", who want to
continue using that name for histporical continuity). The only downside
would be that Path headers would be a little longer, so it should not be
done without good cause.

---

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

Pure history :-( .