From: Seth Breidbart (sethb@panix.com)
Date: Thu Jan 03 2002 - 22:38:38 CST
>>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?
So it doesn't add a Sender: header, that's 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.
We clearly are not reading the same Usenet. In the one I read, a
majority of the From: headers are correct.
> When it cannot tell, it should do NOTHING, not make stuff up.
It isn't "making stuff up" to include a header that it _knows_ to be
correct.
>>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.
That's what you've been arguing all along.
> A - Sender is going to be signed just like From,
That would break the signature, so the poster shouldn't do it.
> and B - the injector has as even less information about the sender
> than it does about the From
It has equally much information about both _headers_, and it knows how
the posting ability was validated.
> so has even less justification for playing guessing
> games with it.
It isn't a "guessing game" for it to insert information that it knows
to be correct.
>>> 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.
Then you don't believe that "sethb@panix.com" is a "valid \"real
identity\"" for me?
> 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.
Given that there can be more than one right thing, the fact that it
can sometimes know that data is right doesn't imply that it can ever
know that data is wrong.
> 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 fact is that some ISPs want Sender (if present) or From (if Sender
not present) to be the account that was validated in order to cause
the post to be allowed to be injected.
>>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?
It's one of them; in particular, it's the (only) one that Panix cares
about.
>>> 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.
Please explain precisely how that differs from someone breaking in to
my account, posting as me, and having whatever header you prefer (an
encrypted Injector-Info, perhaps) pointing definitively to my account.
>>>What is the ISP going to do?
>
>>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?
No, only the ones you want them to accept as being correct in your
From: header such that you don't want them to insert a Sender: header
with information they know to be correct. Or, you could use a
different ISP, since nobody is arguing that ISPs MUST or even SHOULD
handle the Sender: header the way that some of them DO.
>>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?
For an incredibly small value of "any future possibility". What if
somebody wanted to sign an article with "Injector-Info" as provided by
_him_?
> 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.
It knows which account was validated to it in order for it to allow
posting.
>>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.
ANY header that the injector enforces "breaks signing" if the poster
includes that header and signs it. Why is breaking signing of Sender:
so much worse than breaking signing of Injector-Info: ?
Seth