From: John Stanley (stanley@peak.org)
Date: Sat Jun 08 2002 - 17:21:40 CDT
> Note "that address" and "is valid". Sure sounds to me like you were
> calling it an address, the only doubt being whether it's valid.
Fine. Boo hoo. You caught me using your terminology. I did it while
disproving your statement that we need some method of telling at a glance
that an address (your word) is invalid. I simply pointed out that the
only "glance" your server needs is going to tell it the answer.
> Since you didn't seem capable of grasping the notion that the deadline was
> for *objections* -- such as yours -
Stooping to insult when your memory gets had? My objection to this part of
the draft was made a very long time before the "deadline". This problem
did not appear in draft 7, it has been there for a long time, and has been
brought up before the last call. If discussing it cannot take place after
last call, then sir, you are as guilty as anyone else, since you are here.
But you're being too successful at sidelining the discussion from the
issues instead. Let's deal with those, shall we?
> I see nothing in what the 5.2 note allows that would violate that MUST
> NOT. The MUST NOT deals with articles that are found unacceptable, not
> with articles that are deemed to require addition of some headers (as
> quite explicitly permitted by 8.2.2 step 10).
It is complicated, so I'll use small words. Your "deemed to require
addition of some headers" is another way of saying "not acceptable as
submitted." If the article were acceptable without the addition of these
optional headers, there is no requirement to add them. Why is the article
not acceptable without their addition? Well, it's not because the article
violates this standard. The From-content contains a legal address,
according to this standard.
Oh, but maybe the From-content isn't the person actually posting. That
might require a Sender header, yes? Oops, 6.2 does not require the header,
it says only what it means when it IS present (not MUST BE), and
additionally says it SHOULD NOT be present unless the sender (lower case)
is different from the poster. Well, the injecting agent can know that,
right? No, once again, "not knowing they are the same" is not sufficient
proof that they are different, and all the injector can know is that it
doesn't know.
The only reason "some headers" are required to be added is because of SITE
POLICY. The "deemed to require addition of some headers" boils down to
"this article violates site policy because the From-content is not the one
known True address for the person I think is posting the article, so site
policy says I will add a Sender header (or an optional Injector-Info
header)."
Under 8.2.2, step 5, we say:
5. If the article is rejected, or is otherwise incorrectly formatted
or unacceptable due to site policy, the posting agent SHOULD be
informed (such as via an NNTP 44x response code) that posting has
failed and the article MUST NOT then be processed further.
So, this article is unacceptable due to site policy -- injector cannot
determine that the From-content correctly identifies the poster.
(Remember, nothing in this draft makes it standards-policy that this must
be done, so it can ONLY be site policy). The posting agent SHOULD be
informed (not mandatory), but then "the article MUST NOT then be processed
further".
Now, I don't know what kinds of things YOU think "processed further"
includes, but I certainly think that "adding Sender header" or "adding
Injector-Info with user email address" is "processing", and certainly the
actual injection would be. And I'll point out that step 10 follows step 5,
which to most people would be "further processing" compared to step 5.
MUST NOT.
There. Do you see the contradiction yet? In one place we say "you may" and
in another "you MUST NOT".
Here's another one. Let's assume some draconian interpretation of the
standard such that an implementor thinks that .invalid is a requirement
for any From-content that the injector cannot otherwise verify. Let's make
it a standards-policy for legal values. Someone posts without .invalid,
and it does not match the One True Address the injector knows about. Now
step 4 of 8.2.2 applies, and the injecting agent MUST reject the article.
It contains a header which, according to this strict interpretation, does
not "have legal contents". It MUST be rejected. It cannot be fixed.
So now, under the actual rules, the injector MUST NOT inject articles that
violate site policy, and under the strict rules that require .invalid on a
munged address it MUST BE rejected because it has an illegal header
content. There is no wiggle room for fixing articles.
So, here's the remaining questions. Why is an explicit permission to do
something that is later explicitely prohibited not being removed from this
draft? Why is your "followup-agent" caring what appears in a header that
it is not responsible for generating and has rather simple rules for
testing for validity, and why does this standard have to bend over
backwards to support such nonsense?
Why is it improper to remove this erronious statement prior to IETF
action? Why must it now go to the IETF as a formal complaint?
And the last question is, how many more times will you try to sideline
this discussion?