Dave Crocker wrote:
Mark Delany wrote:
Having the signer or the ssp publishes tell the evaluator what they should do
with a message is not a good idea
Why do you say that Dave?
If SSP is not giving guidance/information to receivers/evaluators, who
then is the target audience for SSP? And what do we want them to do
with the information?
An interesting twist to "telling evaluators", as you put it, is that
SSP is a negative indicator. It's telling evaluators *not* to deliver
unless the right conditions are met. Why would an "evaluator" be
suspicious of a domain that encourages non-delivery of its own traffic
when in doubt?
The signer knows everything there is about their own behaviors. They cannot
know very much about the context, needs, preferences, or much else about the
evaluator. Therefore they cannot know very much about what the evaluator
"should" do with a message.
Seriously. SSP can be entirely useful when stated in terms of the sender's
perspective. It does not need to pretend that is knows enough to give
directions to an evaluator.
From what I can see, we are converging on a policy/practice where most
domains
could make a completely correct statement: "I sign everything" and never
want
to publish that policy given that the normal and expected transit damage
of remailers,
etc. That tells me that as stated "I sign everything" is wrong. What
people really
seem to be meaning is "you should find a valid (verifyable) first party
dkim signature" which is a lot different statement than "I sign
everything". It's
the expectation that this all really hinges on.
This toes the line of telling the receiver what to do, but it at least
doesn't
go over the line by pointing out an acceptable form of execution (550,
leathal injection,
etc). So it seems to me that what we really need here is some finesse of
informing the
receiver of the sender's transit expectations without outright saying
what to do.
Mike
We have done quite a good job, so far, of distinguishing statements about
signing from statements about delivery or non-delivery. The issue is not
whether the evaluator might be "suspicious" of a direction to perform
non-delivery. It is that it crosses a line into making presumptions about the
evaluator that a) the Internet technical community does not have experience
with, and b) we do not need to cross.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html