John L wrote:
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.
As I've said before, there are really two different subclasses of this one.
You can have your mail very well under control, but you don't have
control over what the damage might be in transit. For some people
like banks and phishing targets, that collateral damage is likely to be
acceptable. For most everybody else it's not.
So I guess it just intrinsically bugs me that the former is a pretty
rarified
class of sender, and is SSP really _only_ for them? (leaving I send
no mail aside). Is there little or no value in knowing that you sign
everything, but transit related damage is possible?
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.
This is sort of orthogonal to the previous: it's just saying _who_ is doing
it, so the previous considerations of "I sign all mail" still appy.
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.
I'm mostly on the keep it simple side as well -- I'm mainly pushing on these
things to get issue out in the open so they can be considered and likely
closed.
I have seen some pushback on "standardize later" tact, but I think
you're right
that this isn't the same as, say, dkim-base where we're not very likely
to get an
opportunity for version 2.0. But it shouldn't hurt to just add
stuff to the policy record -- possibly non-standard experimental stuff
-- and
if it's useful and relevant, users of the protocol will almost certainly
have an
incentive to upgrade their software to take advantage of it. This is in
stark
contrast to the -base upgrade problem where the signer has no clue of the
capabilities of the receiver, so backward compatibility is huge concern.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html