On Mon, 21 Aug 2006 08:28:21 -0700 Paul Hoffman <[EMAIL PROTECTED]> 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
