From: John Stanley (stanley@peak.org)
Date: Wed Feb 27 2002 - 12:24:18 CST
Seth Breidbart (sethb@panix.com):
>However, going from MAY (or SHOULD) to MUST NOT is a rather extreme
>jump.
RFC1036 says neither that the injector SHOULD nor MAY insert or change a
sender just because it cannot verify the entry in the From header. It does
say that the Sender is present only if the submitter manually enters a
From line. Not only does the injector get to guess that the From line does
not correctly represent the "person who sent the message", it has to guess
if that person manually entered the data it cannot verify.
No, it is not extreme to tell an injector not to do something that it has
never been able to determine needs to be done.
> You're objecting to SENDER in part because it's unencrypted
I've not once said anything about encryption of the Sender header, and the
standard does not permit it. Stop telling me why I am objecting to
something after I've told you several times why I am objecting to it.
>Where did he write "cannot"?
He said he wants it clear that it does not mean a human being. Since that
is clearly one of the possible meanings that it can have in english, then
saying that it DOES NOT mean this is saying that you are excluding that
possible meaning. That's a "cannot".
>He said that "entity" is not _defined_
>to mean "a specific human being".
That is not what he said. The words were included in what you quoted. He
said "does not mean", not "is not defined to mean". He said, in essence,
"there is a list of things an entity can be, and we should make it clear
that that list does not inclulde 'human being'." For what purpose he said
this, I dunno, other than he mentioned that I made him want this.
>As far as Panix's injector knows (or can know) when I post, the entity
>posting is defined as "those who are authorized to use the
>sethb@panix.com account and who have demonstrated that
>authorization".
Thanks for proving the point. How? Because Panix defines the entity to be
YOU (the human), not your email address, and thus when YOU use any of your
email addresses you are correctly identifying the entity doing the
posting, which means that any action by Panix' injector to insert a Sender
is in violation of the standard.
If Panix is inserting or changing Sender headers when you post using any
of your addresses, it is changing the meaning of the From and Sender
headers, and that is not permissible.
> I does know which entity identified itself to the injector,
I'm sure you does. The injector may even know what entity identified
itself. But it does not know that the entity that identified itself is not
the same entity that is identified by the arbitrary email address used in
the From header.
>I have several accounts, and I would claim
>that they are different entities
And I would claim that most people do not agree with you. I certainly do
not. I do not change "entities" just because my email address is
different. Where I work, there are at least 100 different email addresses
for EACH person, all funnelling into the same mailbox. Should we count
each person as 100 employees? At home, I have many thousands of email
addresses, all funnelling into the same mailbox. If you want to claim that
I am tens of thousands of entities just because I have so many email
addresses, that's your right, but you would look pretty silly doing so.
Now, you CAN argue reasonably that role accounts are a different entity.
I.e., when I use "postmaster" at a site I am the admin "entity", but as a
simple user, no, it makes no difference whether I use address A or B or C,
I am the same user.
>> That is exactly what you said. "Entity" can mean any one of several
>> things, one of which includes "human being".
>The fact that A _can be_ B does not imply that A _means_ B.
Yes, but the fact that A DOES NOT mean B does imply that A does not mean
B. That is what the change to the definition of entity causes. It does not
ask that it be clarified that "A can be B", it asks specifically that "A
does not mean B". It's pretty foolish to argue that "A does not mean B" is
not somehow saying that "A does not mean B".
>Because we're discussing the behavior of software, and even strong AI
>is insufficient to deal with "specific human being".
And yet, that is exactly what the argument in support of changing or
inserting the Sender header requires. "You are not correctly identified by
the entry in the From header, thus I, the injector, shall insert the
correct identification for you..." Read the definition of the Sender
header and notice that it says that the Sender header is not supposed to
be used unless the From header does not identify the sender. Then think
about what the injector does and does not know, and that one of the things
it does not know is that the From header does not correctly identify the
sender. If it does not know this, it should not be inserting a Sender.
Period.
>What we want it to mean is that the *entity* in question is the one
>known to the injector.
What is "it"? If you are talking about the definition of "entity", then
you've failed. Circular definition. "Entity means "the entity known to the
injector"."?
And you've still got the problem. Suppose the injector knows that you are
the entity authorized to use a certain account at panix. That still does
not tell it that you are NOT the entity identified by the email address
"sethb425@hotmail.com". It simply does not have that information. Thus it
cannot meet the requirements to correctly insert a Sender header.
>I prefer that wording; in particular, deprecating adding Sender (so
>that it can become a MUST NOT in the next version,
God forbid we actually ever prohibit something. I find it rather
disengenuous to argue that we should just deprecate it now so we can
prohibit it in the next standard, when nobody in their right mind expects
there will ever be a next standard. If you agree that it should eventually
be prohibited, then there is no better time than now to simply and clearly
prohibit it.