From: John Stanley (stanley@peak.org)
Date: Wed Feb 06 2002 - 15:33:35 CST
Charles Lindsey (chl@clw.cs.man.ac.uk):
>Actually, the draft does not say that, because we agreed a few weeks back
>to change it. It now says:
> Be warned, however, that some injecting agents which are unable
> to detect that the address belongs to the poster may choose to
> insert a Sender header (6.2) or some entry in an Injector-Info
> header (6.19) which discloses some valid address for the poster.
"We" did not agree to this change, and the latest draft that is available
still says exactly what I claimed it did. I made the effort to check it
before I quoted it and I just checked it a few minutes ago. I'm still
trying to get a change to prohibit broken behaviour; I would not accept a
change that still allows it.
> With that wording, no headers are modified.
With that wording, yes, dear, headers are modified. It inserts a Sender
header, which has the clear meaning that the poster is not the "entity"
identified in the From header, even though it has no knowledge to that
effect. Either that, or the injector is trying to redefine the meanings of
the headers as I've already pointed out. Either way, the headers are being
modified.
> But the injector is not allowed to change an existing Sender header,
Where does it say that?
> 10. The injecting agent MAY add other headers not already provided
> by the poster,
And when it does so with a Sender header, it is changing the meaning of
the From header.
> but SHOULD NOT alter, delete or reorder any
> headers already present in the article,
I'm still looking for the part where an injector is not allowed to change
an existing Sender header. Is it this wimpy note that you think prohibits
it:
> 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.
>>If a FORGER inserts a Sender header and signs the article with a bogus
>>key, and the injector replaces the Sender with authenticated data, then
>>the signature is broken.
>As it jolly well should be.
Well, you are getting this part right.
>>One case is the real signature failing, the other the forgers. How do you
>>tell them apart?
>You don't, because your first case cannot arise.
Yes, it most certainly can, and the current draft explicitely says it can.
And it is BROKEN when it does so. I say there should be an explicit
prohibition on it. What argument do you have for not prohibiting it?
>The only case that can arise is where a poster includes NO Sender header,
>signs it saying that 'Sender' is included in the sig (which is a stupid
>thing to do), and the Injector then adds a Sender.
Or the poster includes a Sender header, the injector decides that the From
header isn't the poster, and it replaces the Sender header with a valid
spammable email address for the poster. Not only will the poster NOT see
that this has happened until after the message is released to the public,
he probably won't notice the change until he starts getting spam at an
address he has never used to post from, or people start telling him that
the article he signed is not verifying and he goes to find out why.
Too late. And too bad for him, huh? But good for the spammers and forgers.
> But this has all been explained to you before. Why do you keep raising
> it?
Because the problem still exists. I don't care if you explain to me 1000
times why a broken injector is going to do the broken thing, I will still
argue that it is broken and needs to be prohibited. And I've explained why
it is broken and needs to be fixed, why do YOU keep arguing otherwise?
I know why -- because you have a private copy of the draft that you have
modified in whatever way makes you happy, and you are debating what THAT
copy says instead of what the publicly available copy says. I'm sorry, but
when the draft ACTUALLY says what you claim it says, THEN I will argue
with you about what you claim it says*, and until then, I'm using the
public copy that is supposed to be the basis for public discussion.
If you don't like that, I suggest you change the public copy so we can all
be discussing the same document -- otherwise YOU are the odd man out.
* And I'll still argue that allowing a modification to a Sender header, or
the insertion of a Sender header, is broken and should be prohibited,
because it is action taken without enough information to meet the
requirements of the draft. Unless, of course, you've changed the other
parts of the draft which deal with identity, too. You might have, who
knows?
And I'm getting tired of getting handed the drafts after they are sent to
the IETF as the work product of this group instead of before they have
been seen or discussed even once by this group's members. Several times
you've told us unilaterally that you've sent the "new draft" off to the
IETF and we'll get to see what it says in a few days when it makes it to
the archive. I think WE ought to be seeing it before it becomes the
group's submission to the IETF, not after.