From: John Stanley (stanley@peak.org)
Date: Thu Jun 06 2002 - 14:15:33 CDT
Henry Spencer (henry@spsystems.net):
> Actually, I made the comments in question *after* said deadline,
Yep. And now you chastise me for commenting after said deadline. Pot,
kettle. Pick your own color.
> But you clearly had at least one issue with draft 07,
> and you didn't say anything at all before the deadline -- why not?
I shall not waste my time searching the archive for all the times I
commented on this section of the draft long loong long before "said
deadline". Perhaps you weren't a part of this group at the time the
discussion took place. It doesn't matter, I said it before the deadline, I
am refreshing the group-memory now.
> I was merely responding in kind to your accusation that I hadn't read
> the draft. "Oh kettle, thou art black."
I said "please read the draft." Whining about someone else not
commenting before an artificial deadline is not "in kind" with a
suggestion to read the draft you yourself were making late comments on.
It is being hypocritical.
> A rather imprecise language, that, unless great care is taken.
You apparently missed the point I made the last time that NOW is the time
to take great care, and complaining that the language is imprecise is a
waste of time. If it doesn't say what it is intended to say, change it.
That's what this group is SUPPOSED to do. You seem to be admitting that
you agree the language is imprecise and "quirky", yet you reject any
discussion about changing it -- to the point that you deny it ever took
place.
>> So, tell me, for whom is "joe@bite.me.you.damn.spammers" an address?
>It is an address for everyone,
It is not an address for me. Try sending email to it and see if I get a
copy. It may be a string that meets the formal syntactic definition of
address as found in the appendix, but most people you ask won't call it an
address if it doesn't work.
> When Charles asked for any remaining comments on an intended-to-be-final
> draft, nothing was heard on the matter.
It was heard before, it is being heard again. Claiming that nothing was
heard is simply ridiculous, unless you simply weren't listening.
> Certainly; note the word "primarily".
So your argument that we don't need to fix the broken bits because the
implementors are the "primary" target was what? If it is broken, fix it.
Don't tell me that it's ok for it to be broken because users aren't
supposed to read it.
> Or it might not, depending on whether the relevant DNS servers are up and
> accessible from my machine at the time.
You've still not shown why it matters. Why does your news server care what
appears in the From header of the article?
> It's even possible that your
> registration for the .spammers TLD is supposed to go through tomorrow
> and you're just anticipating it a bit.
My what? Sorry, you've got me mixed up with someone else.
> Why do you believe there is a sharp distinction between the two?
Because there is? I dunno, maybe because I can see the distinction and you
cannot?
> The only address that is
> *guaranteed* munged rather than forged, without domain-specific
> knowledge, is one that ends in .invalid.
Ummm, no. I can provide two examples that disprove your statement without
breaking a sweat. joe@example.com and joe@[192.168.0.1].
joe@bite.me.spammers is also an example of munged, since there is no
.spammers TLD and no likelyhood there ever will be one, and there is not
one now.
> To take an example that our esteemed editor will recognize, if the user
> wants to learn more than the "Informal Introduction to Algol 68" will
> teach him, he needs to read the Algol 68 Report...
So, if someone wants to know more than this hypothetical tutorial tells
him about news headers, he'll read the Algol Report? I asked a specific
question about what he would read, and you came back with this Algol
stuff, so I assume that's your answer.
> A tutorial author has a non-trivial job to do, not just in deciding what
> (if anything) to leave out,
Yes, he does. So what document do you think he is going to look at when
deciding what to put in, and what document is the user going to go to when
he finds the tutorial lacking? Algol Report?
> That is why a user should be reading a tutorial, not a standard.
The user should read whatever it is he thinks will help him find the
answer to the questions he has.
For the one true definition of what the Sender header is and when it is
used, he must go to the standard. Our proposed standard tells him that
the Sender header is used ONLY when the From header is not the entity who
is responsible for posting the message. But the injecting agent can add
one when the entities are the same but using a different email address. So
which is right, the standard or the injecting agent? By definition, the
standard is right. That makes the injecting agent wrong. Why do you have a
problem saying that explicitely in the standard?
> What, exactly, constitutes "the user's explicit action"?
Ummm, putting an address in the From header, whether he's doing it
manually for a specific article or has programmed his news agent to insert
it in all articles by default. Is that really such a hard concept? Did you
REALLY not understand what action I was referring to?
> It is not
> trivial for the software to decide whether a user is deliberately using an
> unreplyable address,
The software doesn't have to decide anything. The user put it there, leave
it alone. End of decision.
> or whether this is just the result of a typo
Do you always support the idea that software "spelling checkers" should
operate without final user approval? That's what you are arguing here, if
it is ok to "fix" a "typo" for the user when he has entered his address
and then post it without asking if the fix is correct.
> On thinking about this, it occurs to me that there is a reasonable way to
> accommodate your wishes. We forbid injectors to silently supply further
> address information... if, and only if, the address in the From header
> ends in ".invalid".
You can accomdate my wishes if you do something that is explicitely
outside what I've told you my wishes are. What a novel argument. Please
don't try telling me what my wishes are again.
> That is, after all, the *only* definitive proof --
The only proof necessary that what is in the From header is what the user
wants to put there is the fact that it appears there. If the user did not
want it there, he would not have put it there, and he would have fixed it
prior to submitting the article. Now, yes, of course, the user may have
made a mistake, but the software cannot know this and should not be
guessing.
> You can ask, or you can refuse the
> article, but you can't silently add address information. But only if the
> user has *explicitly* indicated his intentions, by using the .invalid
> TLD.
You were doing so well, until the last clause.
There are many reasons for putting something other than an email address
known by the injector in the From header, only one of which is to put no
valid email address at all in the message. The user may put any of his
other email addresses in the From header and meet the requirements of this
standard. The injector MUST NOT second guess the reasons the user put this
address there. When the injector second-guesses him, it violates this
standard: specifically the definition of the Sender header.
Why do you have a problem making this violation a MUST NOT, instead of
approving it? Maybe if you stuck to this issue instead of how you have
forgotten this discussion was brough up before the deadline or Algol, we
might make some progress.
Matt Curtin (cmcurtin@interhack.net):
>> It should not have "quirks of wording".
> Agreed. Nevertheless, we've got such issues, including the definition
> a brand new vocabulary for standards documents, e.g., OUGHT.
And:
> If something stupid is happening, we can deal with said stupidity in a
> subsequent document, deprecating the stupidity.
~
No, if this draft says something stupid, the time to deal with it is NOW,
not after everyone ignores it because it is wrong. And not after the
damage is done to those users who got surprised by broken injectors
posting spammable addresses for them without their approval.