On Mon, 21 Aug 2006 08:28:21 -0700 Paul Hoffman
<phoffman(_at_)proper(_dot_)com> wrote:
At 10:40 AM -0400 8/21/06, Damon wrote:
It sounds like what you and few other people want is an SSP policy
that says "if you receive a message that is supposedly from this site
(for some definition of "from") and it doesn't have the mark that
says that XYZ is authorized to sign the message, assume the message
is forged". Is that a correct summary of the requirement you see?
I am glad you put a question mark at the end.
But you didn't answer: is that a correct summary. (And, if not, is
there a summary that looks like this one?)
It took me a while to read through this can of worms, but for every
argument against the optional flags that myself, Hector, and I few
others are looking for, I see contrary arguments that only bolster the
point that these thing we are hinging on are OPTIONAL. Just because
they are OPTIONAL does not automatically make them irrelevant nor
unnecessary.
True. However, even if they are optional, they have to be fully
specified in order for people in the WG to understand if they are
relevant or necessary. The parts that I miss in this thread is: "for
this particular optional statement of policy, what is the recipient
of that policy message expected to do? What are the requested to do?"
I see people who supposedly agree with each other about the policy
appear disagree on the required and requested response to the policy.
Some of that is because the tone of the messages is "this is obvious"
(which it is not), and some of it is because there are long-winded
discussions of the usefulness of the messages that don't concretely
say what the recipient should/must do.
Note that the above summary of this one point has such a
specification: "assume the message is forged".
Not speaking for anyone else, but "assume the message is forged" is what
I'm after. What the receiver does with it is a matter of receiver policy
that I think there is consensus should not be standarized.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html