Subject: Re: Shame vs Engineering, also NEW conformance criteria

From: John Stanley <[email-masked]>
Date: Mon, 8 Aug 2005 11:19:25 -0700 (PDT)

I:

>considered a part of the private nets) like 10.*, 192.168.*, etc. He's 
>just refused to refer to the addresses as "routable".

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

> Not at all. I had something in about routing tables at one stage,

"Routing tables" is not the same concept as "routable" and "non-routable."

10.* and 192.168.* are non-routable because they are defined that way,
because they are assigned as "open addresses" that anyone can use. That 
does NOT mean that they will not appear in someone's routing table, simply 
because a large organization that is using the 10.* netblock may very well
have routers within their network that will certainly contain 10.* 
addresses in the routing tables. 

But 10.* addresses are not supposed to be routed outside the organization 
that is using them, which is why they are called non-routable. When they 
hit the "wide open Internet", they aren't supposed to be routed.

The opposition to the phrase "routing tables" was specific to that concept
and not to "routable" in general. Don't pretend you did say "routable"
just because you used the phrase "routing tables".

>While I was about it, I changed "working email address" to "deliverable
>email address". If you think that too is broken, then you must also agree
>that RFC 2142 is broken (which it is, but not for that reason).

Charles, I will not jump through your hoop nor agree with you on things 
that I do not agree. Please stop putting words in my mouth.

You cannot logically say anything more than "syntactically correct" and 
have an adequate reflection of reality. There are too many sites that 
filter using RBL et. al. to ever pretend that any email address you 
mandate is going to be deliverable, and adding in the automated abuse 
responders that deliver the email to nothing more than the bit bucket 
after saying "Thanks for the gumball, Popeye" makes it even sillier to 
pretend. 

And weren't you the fellow who so sweetly referred to my proposed
expansion of the definition of followup as "smoke and mirrors" and "trying
to change reality"? And now you pretend you can order sites to do things
they already refuse to do based on existing standards? What, one rule is
ignored so you think everyone will jump up and obey the new one just
because Charles said so?

>If, as you are so keen to point out, RFC 2142 is to be regarded as a
>standard, and if it states that certain addresses derived from the Path
?"must" be deliverable, then it would seem that RFC 2142 has redefined the
>meaning of the Path header.

We are not the RFC2142 working group, it is not our task to rewrite 
RFC2142. Just as RFC2142 may have overstepped its limits by trying to add 
a purpose to the path header, we would overstep our limits by redefining
an address defined in RFC2142.

>My view, however, is that RFC 2142 is such a shambles ...

Yes, we know. You don't know what a top level domain is. You want us to 
rewrite RFC2142 under the guise of a news standard to help all those poor 
ignorant people who cannot figure out how to complain about something.

If you want a new RFC2142 I suggest you join the RFC2142 working group, or 
get it created so you can work your magic in the correct place. This is 
USEFOR. We deal with news.

>that we would be
>better deciding for ourselves exactly what we want regarding those
>various addresses,

When what you want is a direct contradiction to an existing standard, no.

>Eh? I understand "everybody" to include "implementors", and I expect
>"everybody" to be able to find whatever usenet/news/abuse addresses we
>finally agree to mention.

And I expect "everybody" to be able to find whatever addresses RFC2142
specifies, because it really isn't that hard and even in the remote chance
there is a failure, there is no harm to the news system.

Since "top level domain" is so hard to grasp, here's a simple algorithm 
you can use: 

	1. A = FQDN of the host you want to complain about
	2. Append "abuse@A" to the To: line of your mail agent
	3. If A contains just one dot, send the mail, exit.
	4. Remove from A the leftmost dotted component. E.g.
	   a.news.example.com would become news.example.com.
	5. Append a comma to the To: line of your mail agent.
	6. Goto step 2.

I assume, of course, you are able to understand that "abuse@A" means
to replace "A" with the contents of the variable A. And I also assume
that you understand the difference between an example ("E.g.") and
"In other words" ("I.e."), so you know that this algorithm isn't limited 
to addresses in the example.com domain.

Now, explain why this algorithm is not sufficient to find the already 
mandatory abuse reporting address for any FQDN.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Aug 2005 12:03:43 +0200

> mandatory abuse reporting address for any FQDN.

it generates a lot of junk mail to [email-masked], but I suppose you've 
already understood and accepted that....

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 9 Aug 2005 10:55:40 GMT

>	5. Append a comma to the To: line of your mail agent.

So in the case I gave (wapping.cs.man.ac.uk), that would result in sending
your complaint to:

   To: [email-masked],[email-masked],[email-masked]

That is the machine-gun approach (you can be pretty sure that at least one
will hit the target). Indeed, cs.man.ac.uk will reach the proper place.
man.ac.uk will in fact reach someone with no responsibility for the server
is question, but who might prod the person who was. And the man at ac.uk
would be mightily pissed off if everybody followed your algorithm and he
found himself being copied on every complaint ever made about any student
in the UK.

And your algorithm still does not implement what RFC 2142 calls for, which
is the "top level domain". Which of those is the top-level domain and why,
when you are supposed to be sending to the TLD only, are you sending to
three addresses?

-- 
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: Richard Clayton <[email-masked]>
Date: Tue, 9 Aug 2005 14:30:19 +0100

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

>when you are supposed to be sending to the TLD only, are you sending to

this is rapidly going entirely off-topic, especially since the chair may
decide the consensus is to drop all this stuff...

however I am assured that  <m@im> (that's the 'Isle of Man' in the Irish
Sea) is a working email address, and that a number of other TLDs have MX
records, and working addresses to go with them !

that said, I can imagine a lot of software would not accept it (either
through the application of heuristics or the ABNF syntax in RFC2821
which apparently requires two components -- though I don't believe that
this was an intentional change from earlier....)

it should be noted, I suppose, that parsing  ...!demon!... will yield an
unsendable-to  abuse@demon  (though your system may apply some
heuristics and turn that into [email-masked] (if you live
inside example.com)) ...  but the last thing we need is a rule that says
you can use UUCP name unless it matches a country code...

... this area isn't broken and works passably well IME. Why aren't we
leaving well alone, documenting what is done and not bothering to
transcribe other RFCs?

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 09 Aug 2005 21:46:37 +0200

Richard Clayton wrote:

> this is rapidly going entirely off-topic

As indicated by the Subject, but it's actually funny.

> I am assured that  <m@im> (that's the 'Isle of Man'
> in the Irish Sea) is a working email address

It fails with the "at least one dot" rule in RfC 2821,
2821bis will try to fix this.  At the moment it's an
SMTP syntax error, "working" or not.

> I don't believe that this was an intentional change
> from earlier....

John confirmed that the "one dot" rule was intended.
Catch host names assuming some kind of default domain.

The 2821bis syntax will allow a trailing dot for this
case and FQDN = TLD.

> the last thing we need is a rule that says you can
> use UUCP name unless it matches a country code...

<g>  Indeed.  As far as I'm concerned we could "upgrade"
this stuff to state-of-the-art 1994 and s-o-1036, pseudo-
domain UUCP or die, "demon", die.  Dito one or more "wolf",
"cafe", "dead", "beef", and similar stoneage monsters.

We're declaring 100% of all user agents as "obsolete" -
assuming that not one UA gets 2231 right - so why are we
so shy with this "traditional name" crap ?

Let's say "MUST FQDN" and be done with it.  Those who
don't use a FQDN are non-conforming, ready.  And maybe
allow UUCP as pseudo-domain.  I promise I'll scream if
somebody mentions BITNET.  This is the 3rd millennium.

                  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 10 Aug 2005 15:34:35 GMT

>leaving well alone, documenting what is done and not bothering to

But "passably well" is hardly an ideal state of affairs. However, some
advice in USEAGE on the way that both users and implementors should handle
these matters (based around the algorithm that we discussed) would
probably suffice to keep things running smoothly.