From: John Stanley (stanley@peak.org)
Date: Thu Jan 10 2002 - 20:31:27 CST
Seth Breidbart (sethb@panix.com):
> We can't specify policy for ISPs.
We aren't trying to. We are trying to specify that an injector MUST NOT
insert or change an indentity header when it cannot know the header is
wrong.
>Nobody is saying that the standard should recommend that. I'm saying
>that in a footnote it should warn people that some ISPs _do_ that. We
>should also deprecate that behavior.
No, we should forbid that behaviour, since it will absolutely break the
ability to sign an article.
>It shouldn't be; that was a strawman argument that if a user provides
>and signs it, then the injector replacing it will break the signature.
So what? If someone signs the Injector-Info header, that is his problem.
On the other hand, if someone inserts the correct data in both From and
Sender headers and signs the article, the injector MUST NOT change those
headers. Period. Even if it thinks it knows better, because it cannot
"think" any such thing.
>> Answer: you don't know it, but the contents look reasonable so you assume
>> they are correct.
>That and the fact that, with one exception (which I learned about but
>never actually sent mail to), the hundreds of people I've sent email
>to in response to their Usenet postings had given good addresses.
Your "fact" is irrelevant, it proves nothing about the validity of an
address you see today. Nor does it have any relevance to the issue at
hand, which is how an injector is supposed to know what YOU cannot.
>> When it is guessing that what is there is wrong, yes sir bub it is a
>> guessing game.
>It isn't guessing that.
It most certainly is. "I guess that the From header is wrong, so I will
helpfully insert what I think the correct Sender header is." That's a
guessing game. It should be prohibited.
>It is saying that it doesn't know that it is
>correct, which is true.
And, in effect, saying that is guessing that it is wrong. It is taking
the same action whether it says "I guess this is wrong" or "I don't know
this is right." Same effect, same meaning.
>Now you want the injector to act in a way that it cannot: by accepting
>any correct (in a God-like omniscient sense) From header.
The injector needs no God-like omniscience to leave the From header alone.
It simply does not know when it needs to change it, thus it should NEVER
change it. Since it does not know the From is incorrect, it cannot know
when to insert a Sender, AND it does not know what sender to insert. Both
are the only reasons necessary to make changing a Sender header by the
injector a MUST NOT.
>Now if someone breaks into my account and posts as me, the encrypted
>Injector-Info header (which is validated by the injector) says it is
from me. Why is that different?
Different than what? Different than people all over the world assuming
that you really did post the article because they know your server
validates From headers, while they don't necessarily know how to decode
some encrypted Injector-info header? Well, I guess its different because
one header plainly states that you posted the article while the other one
needs decoding to say the sam thing?
>So you claim that:
>1. Every article will have a Sender header,
If you cannot argue against what I actually say, make it up, huh?
No, I said no such thing.
>Otherwise, some articles (e.g. those I post with From:
>sethb@panix.com) can still be properly signed.
So you sign them, and your injector decides to insert a Sender header. Or
is changes your From. The signature is broken. Now we all see that article
and don't know if you actually did post it, or someone forged it, or what.
Who knows? The signature system no longer tells us what we designed it to
tell us.
>Now we're getting into the meaning of "different from".
Simple english. "not the same as". Is that really a problem for you to
understand, or did you just run out of arguments against prohibiting
broken behaviour on the part of injectors?
> I would claim
>that when I'm using a different account, the sender is different.
Then apparently simple english is a problem. I've got two windows open at
this very moment. If I post news from one of them, my From: says one
thing. If I post in the other, it says something else. You'd have a very
hard time arguing successfully that I am a different person using two
windows.
Charles Lindsey (chl@clw.cs.man.ac.uk):
>I have said I will remove the wording allowing injectors to replace a
>Sender header (though not that to insert one when there was none).
Both actions are incorrect and cause a change in the identification of who
posted the article. If the header is not there, then the implicit
statement is that the From entity posted the article. By inserting the
Sender header, you claim that the From entity DID NOT post the article.
The truth is, the injector just cannot know this. It should not change
what it cannot know needs to be changed, nor should it change something to
a value that it has no way of determining.
>But I have not inserted any further prohibitions, because I hear no
>consensus to do so.
Sometimes you need to do something because it is the right thing to do,
even if nobody else tells you.
>>. warn software writes of ISPs that do add a Sender header.
>Indeed. That is exactly what the paragraph that John Stanley is objecting
>to does.
That's right, and by now you should know why I object to that.
>It would be unwise (though not prohibited) to include Sender in a
>signature.
Nonsense. Since the Sender header is intended to identify "the person or
software (usually, but not always, the same as the poster) responsible for
the operation of the posting agent or, which amounts to the same thing,
for passing the article to the injecting agent", it should be signed if
the From header is signed, to prevent someone from changing the identity
of the actual poster. Since the actual poster is the only one who can
identify "the person or software" the injector should leave this header
alone.
>Sure, if a sufficiently clued-up person uses the Sender header correctly
>and intelligently, then by all means let him sign it (though I doubt he
>gains much by that assuming the From is already signed).
I know that the concept of the sender not being the person identified in
the From header is difficult, but news currently makes that distinction,
and it is important to either continue it or to remove it, not make it a
half-assed kludge.
>But my point is that the Sender IS frequently used in situations that are
>neither clued-up, nor correct, nor intelligent.
And your point is relevant to something we are discussing here? We should
discourage signing Sender because some people might not understand how it
is used, and we should allow injectors to play with it (inserting or
changing it as they desire) because the people who know the correct value
to put there might not do it correctly?
Poppycock.
Bill Davidsen (davidsen@prodigy.com):
>After thinking about the points raised, there is a case in which the
>injector could know the address is invalid, and that is if it is not in
>standard format, user@FQDN.
This is just a backdoor method of trying to prohibit munged addresses that
aren't done the One True Way that The Illuminati have decided upon. We've
gone throught that discussion already. We can go through it again, if you
want.
>In that case I could live with MAY add a
>sender header, although I'm not really happy with it.
"If you do not use the One True Munging Method We have described for You,
the news injector will just go ahead and put a fully spammable verified
email address for you in each article you post."
Unacceptable.
Charles Lindsey (chl@clw.cs.man.ac.uk):
>OK, it now say, in the duties of an injecting agent:
> 10.The injecting agent MAY add other headers not already provided by
> the poster,
Unacceptable. It MUST NOT insert what it cannot know. This is especially
true in the case of Sender, where inserting this header changes the
meaning of the From header.
> NOTE: Care needs to be exercised, when adding any non-mandatory
> header in this way, to ensure that the intentions of the poster
> are preserved. In particular, the addition of a Sender header
> would have privacy implications similar to those set out in
> 6.19.1 regarding the Injector-Info header.
Unacceptable. This implies that it is correct behaviour for an injector to
insert a Sender header, when it simply is not.