From: John Stanley (stanley@peak.org)
Date: Thu Jan 03 2002 - 18:37:42 CST
Claus Frber (list-ietf-wg-apps-usefor@faerber.muc.de):
>If the spec does explicitly disallow this, ISPs will just ignore
>that and add the header anyway.
We cannot refuse to specify correct actions simply because we think some
people will ignore a prohibition. To do otherwise says it is acceptable
for this action to happen, and that is not true. This holds true for the
"Re: " part of a reply, and for playing guessing games with From and
Sender headers.
>That does not help implementors of Usenet software at all.
Yes, telling them explicitely that something is not permitted (and why,
should clarification wording be included) is helping them to avoid
thinking that it is a good idea or somehow acceptable to do what they are
intending on writing into code. Every author that does not do the wrong
thing because he saw the prohibition is helped by not having bug reports
sent to him complaining about his software misbehaving.
As for ISP's that deliberately go out of their way to rewrite news server
code to do something that is prohibited by the standard, well, we can't
stop them, but we certainly should not let them think they are doing
something they ought to be doing.
Seth Breidbart (sethb@panix.com):
>Clearly not the "same" problem as that first paragraph, since
>sometimes an injecting agent _can_ tell that the address does belong
>to the poster.
No, it is the same problem, same underlying incorrect implication.
Sometimes an injector MIGHT be able to know that an address belongs to the
poster, but so what? We aren't dealing with cases where it can, we are
talking about what it does when it cannot. That will be MOST of the time.
When it cannot tell, it should do NOTHING, not make stuff up.
>What it does now (at least, what some of them, those that force a
>Sender header do) is to replace the Sender header.
It should not do this. A - Sender is going to be signed just like From,
and B - the injector has as even less information about the sender than it
does about the From so has even less justification for playing guessing
games with it.
>> In other words, every injecting agent will always be "not convinced"
>> about any From or Sender header.
>That's clearly false-to-fact, given that many injecting agents now are
>often "convinced" about From headers.
I can't account for poor programming and invalid logic that results in
some program thinking it knows what it does not. It is simply magic to
think that a username/password authentication pair can be transformed into
a valid "real identity" for a user.
And I probably don't even need to go to the extreme that others did in
news.groups when I said that raw votes are not available to "just
anybody", when they pointed out that computer security is not absolute and
breakins happen.
But then, the issue is still not what the injecting agent does when it
thinks it knows the From is the "real identity", it is what the injector
does when it does not know. If the injector thinks the From header is
valid, there is no reason for it to change it, and thus a prohibition
against doing so is just as reasonable as none. But when it does NOT know,
which is still most of the time, a prohibition is needed.
You made the point for me: an injector cannot detect the data is wrong,
thus it should not be permitted to change it to be what it thinks might be
right. If it knew the "right" data, then you'd be saying it could actually
know the data was wrong.
>No, but for the reason I gave above; substitute "does not perceive to
>be correct" for "perceives to be incorrect", since the latter is
>impossible in the general case while the former is sometimes the
>case.
Either way implies an injector can guess it is incorrect and play with it
or the Sender header, when the truth is is cannot know it is incorrect and
thus should NEVER play with either.
>The one it assigned to the poster. E.g. Panix knows my "real ID" to
>be sethb@panix.com.
Surely that is not "THE" real id for you. It may be one of them, but THE
real id? Maybe you don't have any other email accounts. I don't know. All
I know is that I have an uncounted number of them -- limited only by the
technical limits on mail transport, since I have domains I own.
>> What do you say to the ISP when someone breaks in as you and they
>> claim you've been posting unacceptable articles and will be TOSsed,
>> because THEIR injecting agent doesn't allow unauthenticated From:
>> headers?
>I'd say to look at the Path to see that the article came from
>somewhere else (or their logs, if the Path was forged).
Oh dear, Seth, you've just been kicked off your ISP. Someone broke in as
YOU and posted the same way you would have, so the PATH shows the article
came from their server. And they KNOW that the From header is
authenticated and their server doesn't allow unauthenticated data there,
so YOU must have been the one posting it.
>>What is the ISP going to do?
> Whatever it wants;
If that's how this standard should be worded, then we might as well just
stop wasting all this time trying to specify how ISPs process news.
>presumably, reject the article unless you've
>demonstrated to them that you own that ID.
Why should I have to do that? Do I have to register every id with them?
>Why should we be moved by a strawman argument that depends on bad
>wording in some hypothetical rule?
Why shouldn't we prohibit an action that will break any future possibility
of signing articles? I don't know. Maybe you can think of a reason?
Charles Lindsey (chl@clw.cs.man.ac.uk):
>Not all cases
>are "general", and the plain fact is that some of them DO detect it and
>act upon it (as has been reported in this thread), in spite of what you
>say.
And I say that those limited cases where an injector has some mapping
between username/password authentication and an email address are
irrelevant, since we are not dealing with what an injector would do if it
can tell the address belongs to the poster. (I.e., NOTHING.)
We need to deal with what happens when the injector CANNOT tell, which
will be in most cases. Implying that an injector can simply replace the
From header with something it likes better is simply ridiculous. To say
that it can know who the Sender is when it cannot determine the poster
is even more ridiculous.
>The paragraph
>that you are complaining about is merely a *warning* to say that some
>injectors MIGHT do it.
Yes, and that is the wrong message to be sending. Injectors MUST NOT do
it. It breaks signing, and it is guessing at best.
>>It is patently ridiculous to say it "might happen". It cannot happen.
>Then how come it does happen?
It doesn't. Injectors cannot detect that the address does not belong to
the poster. It simply does not happen. They GUESS that it doesn't, if they
do anything, because it does not match some database entry for who they
think the poster is. But that is not the same as detecting that the
address does not belong to the poster, only that it is not one that they
know belongs to the poster. Yes, the difference is important.
>But note that it is only *altering* an existing Sender header that I am
>taking out.
Inserting a Sender header that differs from the From header (which is the
only legal kind) breaks the implied assumption of 6.2 that the sender is
the same as the person listed in the From: header when the Sender header
is absent, thus inserting a new Sender header is changing the implicit
Sender data. Doing so when this information is unavailable to the
injecting agent is simply wrong and should be specified as such.
>The general permission to add absent headers remains (though
>there is another thread discussing that one).
And this permission should be removed for Sender. And for From.
The only place this data is available is from the poster. He knows if he
is the sender and or author, he knows his own identity.