Please don't shoot the messanger: I'm just asking.
I hadn't intended to shoot, sorry if it came across that way. You're
right, people find all sorts of other uses for successful protocols, but
those uses tend to be "pull", repurpose info already used for something
else rather than "push", stick in the data and see if anyone cares. The
way we're trying to define SSP is really risky since we have, as far as I
can tell, no operational experience at all with anything SSP-like so we're
just guessing about what will be useful.
It seems to me that so far we have two, maybe three, items that a sender
could publish that would plausibly be useful to a recipient trying to
decide what to do with an incoming message that isn't self-signed.
"I send no mail" is about the strongest possible hint that the message is
forged, and the recipient doesn't want it.
"I sign all mail" is the next strongest hint, saying to me that the sender
believes it has its outgoing mail firmly enough under control that an
unsigned message is more likely to be a phish than a damaged real message.
The third is "<foo> signs all my mail", if it turns out that there
actually exist foo's that reliable enough to delegate's one's signing, and
that it's easier to do that than to sign in the MUA or to provide signing
keys so that foo can put on the sender's signature.
So my suggestion would be to use a format similar to the one we use for
the signatures, put the first two items in the spec, and use a syntax that
permits people to experiment with new items and propose the useful ones
for later standardization.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html