From: Henry Spencer (henry@spsystems.net)
Date: Thu Jun 06 2002 - 15:47:24 CDT
On Thu, 6 Jun 2002, John Stanley wrote:
>[assorted uninteresting snarling omitted]
>
> > 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".
Yes, and it had been long loong long forgotten by the time draft 07 rolled
around, and when Charles asked for any remaining problems, you said
nothing. We discussed many different issues, often inconclusively; that
did not automatically leave all of them on the agenda as needing action.
The whole point of a "last call" is that forgotten or unresolved issues
should be raised then. You didn't.
> ...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.
Yet later in the same mail, *you* referred to it as an address. Even you
don't seem to really subscribe to the narrow meaning you claim the draft
should use for this word. I see no point in discussing this further; the
existing wording is consistent and clear, even if it does not match the
usage you sometimes prefer.
> > 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?
My news *software* cares; the server is only one part of the software.
Specifically, the followup agent cares, because it may want/need to use
mail for a response. Our standard is not just about servers.
> > 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.
I didn't think it very *likely* that you'd be registering a .spammers TLD,
but the theoretical possibility existed -- it is one reason why someone
might legitimately use a domain that didn't seem to exist at the moment.
The point is that the apparent nonexistence of the domain proves nothing.
> > 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].
The former you are correct about; my statement was slightly (but only
slightly) too emphatic. The latter is wrong, since news articles might be
local to an organization in which 192.168.0.1 was a legitimate internal
address.
> > 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?
No, he'll read our standard. (Note the word "example" in what I wrote.)
And he will have to read it carefully, as one has to read any standard,
since it is not a tutorial. In particular, he is well-advised to skim the
standard for material relevant to his topic, since it isn't necessarily
all in one place.
> ...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.
*If* it cannot determine that the entities are the same. This sort of "to
the best of its ability" caveat is always implicit -- there is no way the
software can ever be sure it has complete knowledge of the mapping between
humans and online identities, so any decision it is asked to make, it must
make despite uncertainty.
> > 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?
The action you are *now* referring to doesn't convey *any* implication
that the address is invalid and is being inserted for spam prevention,
which is what we seemed to be talking about. Many people explicitly
insert a From-header address for other reasons -- e.g. because they have
multiple addresses and want to use the same one everywhere -- which don't
imply any aversion to the insertion of Sender. (For example, I have done
so at times.) The original *point* of Sender was to identify the actual
poster in such cases.
If you want to argue that the Sender header should be abolished, you
need to say that more explicitly.
>> 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't] accomdate my wishes if you do something that is explicitely
>outside what I've told you my wishes are.
I was attempting to address your actual wishes, not your perhaps-imperfect
expression of them. It seemed to me that your wishes were for a way to
suppress the addition of valid addresses, in cases where you are taking
care that the From header does not contain one. There is a standard way
to do the latter -- address ending in .invalid -- which is useful
precisely because it permits easy detection of such cases by software.
Here we have a case where both existing practice (insertion of Sender) and
your wishes (no insertion of Sender) could be accommodated by exploiting
that easy detection.
> Why do you have a problem making this violation a MUST NOT, instead of
> approving it?
Because I don't think it's a violation, and you haven't convinced me that
it is.
Henry Spencer
henry@spsystems.net