From: John Stanley (stanley@peak.org)
Date: Wed Jan 02 2002 - 13:48:23 CST
Charles Lindsey (chl@clw.cs.man.ac.uk):
>I have now replaced that paragraph by the following (it is still part of a
>NOTE):
> Be warned, however, that some injecting agents which are able to
> detect that the address does not belong to the poster may choose
> to insert a Sender header (6.2) or some entry in an Injector-
> Info header (6.19) which discloses the poster's true identity.
This is still as unacceptable as the original text, for the same reason.
Injecting agents are simply not capable of detecting, as a general case,
that an email address does not belong to the connected user. Even those
that require authentication are incapable of doing this. To imply that
any of them CAN do this is simply and patently absurd.
Yes, you can argue that "foo@bar" is not the poster's email address, and
except for the fact that this address expands to "foo@bar.localdomain",
you might be right. But what about "lurch@lurch.com"? Does that address
belong to me or not? How about "webmaster@fozzie.com"?
The only correct thing for this draft to do is to prohibit the injecting
agent from being permitted to make these guesses. The most likely guess
will be "doesn't belong", and then it will happily insert a spammable
email address for the user based on some magic -- which is what the user
may very well be trying to avoid by posting with his hotmail address.
>I think that now represents something which might actually happen,
It is patently ridiculous to say it "might happen". It cannot happen.
All the injecting agent can do is guess. It should not be guessing. It
should not be "fixing" From headers, it should not be inserting bogus
Sender headers when the Sender header is not needed.
In <200112171750.fBHHosP15421@panix1.panix.com> Seth Breidbart
<sethb@panix.com> writes:
>s/are able to detect that the address does not belong/are unable to
>detect that the address belongs/.
Same problem. Nice frosting on a piece of crap does not a chocolate cake
make.
Charles Lindsey (chl@clw.cs.man.ac.uk):
>What now is the injecting agent to do when it sees both a From and a
>Sender, and is not convinced about either?
Exactly what it knows how to do: nothing at all. It does not know the
>From: is not the sender, it does not know the Sender is not correct. How
the hell do you think an injecting agent that cannot determine that the
From header content is not the poster's address will come up with any clue
that the Sender header is not? After all, the authentication that it may
have done is for the poster, not the sender. It has no idea about the
sender.
In other words, every injecting agent will always be "not convinced" about
any From or Sender header.
>BTW, the Duties of an Injecting Agent say that it SHOULD NOT alter headers
>other than the usual variant ones, and the ones it adds itself. That does
>not include the Sender header, strictly speaking (though adding one where
>one was present would not count as "altering" perhaps). Do we want to say
>anything different there?
"Injecting agents MUST NOT alter the From or Sender header content, if
present, nor must it add a Sender header if one is not present."
To say anything else is to let the agent guess based on zero information.
Agents should not be guessing. The poster is the only one who can know the
information in those headers is wrong.
Seth Breidbart (sethb@panix.com):
>There's no way Panix's injector could possibly tell whether or not
>sethb@suespammers.org belongs to me; since it can't tell, it adds a
>Sender: header.
That is exactly the wrong thing to do, and is probably directly
antithetical to the reason you are using the From content you are.
Charles Lindsey (chl@clw.cs.man.ac.uk):
> except that it MAY alter a Sender
> header (6.2) that it perceives to be incorrect ...
> Is that OK?
No. No. And no. Injecting agents cannot "perceive" anything. They cannot
know. All they can do is guess, and they should not be guessing.
>Are people happy with that, or does it want
>changing, moving, or removing.
Changing, to the prohibition I've already written.
> 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 the poster's true identity.
It cannot insert what it does not know, and it should be prohibited from
guessing. To say anything else is patently absurd.
Charles Lindsey (chl@clw.cs.man.ac.uk):
>I think I would like to change our draft at least to say that an injecting
>agent MAY supply a Sender, or overwrite an existing one, since that seems
>to be existing practice. Is that agreeable?
No.
Brad Templeton (brad@templetons.com):
>If an ISP is clear and makes a decision that its users get no ability to
>post without their real ID,
This statement makes it painfully obvious that the problem is not
understood. What "real ID" is this ISP going to enforce? It cannot know
any "real ID" other than the one at that ISP, at best. At worst, it
will "know" I am someone else, if I happen to break in or log in as
them. 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?
Suppose I sign up for an ISP that says "you must post using your real ID
in the From: header". Suppose I post using the ID "lurch@lurch.com". Is
that my "real ID", or is that a "fake"? I assure you, it is quite real,
and I own it. What is the ISP going to do? The first time it plays games
with my "real ID" in the From: header, I will tell them to stop, because I
am following their rules to the letter and they have no reason to mess
with it.
They will think they are obeying the standard for news and I am violating
their rules; I will know they are being arbitrary and capricious with
rules I am following to the letter. What a wonderful position to put
people in.
>If an ISP does something with a conscious decision and informs users, that
>is one thing.
And if an ISP makes a stupidly incorrect decision because this working
group implied that this decision was valid, then it is our fault. It is
something that we can forsee, it is something that is patently wrong, and
we should take the simple step of preventing it before it is allowed to
happen.