Subject: Re: New USEPRO path-identity text

From: John Stanley <[email-masked]>
Date: Tue, 19 Jul 2005 09:44:55 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Exactly. If we write the "simple minded rules" into the draft, then
>everybody will know exactly what is expected of them.

Until you justify the CHANGED rules you aren't supposed to just simply
"write them into the draft". The fact that you repeatedly DO write your 
own version of rules into the draft is not a feature of this process, it 
is a bug. 

I'll ask again, but I don't expect you'll answer: what is the
interoperability issue that is being created by RFC2142 and solved by your
proposed "MUST", and what is the reason for changing how RFC2142 has had
it spelled out for so long? RFC2142 is explicit in contradicting you; now 
YOU be explicit in justifying the contradiction.

Until you can answer those questions satisfactorily, you have no right to 
just "write into the draft" whatever new rules you think ought to exist.

And no, your assertion that idiots won't know how to send complaints
unless we change the rules is simply ludicrous. And this pretense that
"it's written in the draft" is a justification for the change is even more
ludicrous.

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

NO! If you want the specific rules of RFC2142 changed it is YOUR 
responsibility to justify it, not everyone else's to keep you from doing 
it.

Alexey, Harald, prime example of unilateral changes that meet no other 
criteria than "Charles thinks it ought to be this way". Is this how the 
draft editor is supposed to operate, and does it please you? (Those 
are rhetorical questions, I already know the answer.)

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Jul 2005 14:31:05 GMT

>own version of rules into the draft is not a feature of this process, it 

The CHANGED rules (as you call them) were written into the draft about 5
years ago, and even passed unscathed through a Working Group Last Call (an
argument you are fond of using when it suits your purpose).

>proposed "MUST",

Perhaps it is the same interoperability issue that justifies defining
"postmaster" in RFC 2821 with a "MUST". It is related to fighting security
issues, and breaches of security count as "harm" in my book.

-- 
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: Wed, 20 Jul 2005 13:49:54 -0400

> issues, and breaches of security count as "harm" in my book.

RFC 2821 doesn't *define* postmaster "with a MUST"; it simply states that
a system handling mail via SMTP MUST provide a well-known mailbox as a
means of communication with the operators of that mail-handling system.
It is not itself a security issue, and RFC 2821 section 4.5.1 specifically
permits blocking mail to postmaster under some security-related conditions.

Invoking 2821 is a bad analogy -- 2821 provides for a mailbox on a mail-
handling system.  The analogy for Usenet would be a site-specific newsgroup
rather than a mailbox.  Because of the way news is distributed, that would
not be terribly useful.

You still haven't answered John's question, viz. what is the specific
interoperability issue with RFC 2142?

In addition, requiring Usenet sites -- some of which are not on the
Internet -- to support mail -- a separate set of protocols -- is
questionable, and you have used the "Usenet is not the Internet" argument
when it has suited your purposes.

---

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

>means of communication with the operators of that mail-handling system.

That is not how it is written in RFC 2821 (for example, RFC 2142 is not
even mentioned).

But if that is what RFC 2821 is doing, then that is exactly what my text
is doing for the mailboxes "news", "usenet" and "abuse". "news" and
"usenet" are entirely analogous to "postmaster"; "abuse" is slightly
different because RFC 2142 is less clear as to what domain name it is to
be used with. Therefore the text gives some more detail of that, and also
gives situations where those addresses need not be provided (just as RFC
2821 does for "postmaster").

And what you have written above implies that you accept that the "MUST" in
RFC 2821 is justified, even though you have not indicated any
interoperability issue. Therefore I do not see how you could fail to
accept the same thing in my entirely analogous text.

I grant you that what I have written is not _exactly_ what RFC 2142 says
(but neither is RFC 2821). Is is in some aspects stronger and in some
aspects weaker, and if people want to promote of demote the various
instances of "should", "SHOULD" and "MUST", then that is a legitimate
subject for discussion.

>questionable ....

That does not seem to have stopped RFC 2142 from "requiring" it (at least
in lower case). But in fact I have specifically NOT required it for
relaying sites in general, for just the reason you give. I have only
proposed that MUST for injecting agents, and that only because those are
the ones that people really need to be able to contact, and therefore it
is not an unreasonable imposition to expect them to establish some ability
to receive internet mail. But if people want that MUST demoted to SHOULD,
then that can be discussed.