But different parties mean different things when they sign the
message. If the author signs a message, it means "I wrote this".
If a list signs a message, it means "I sent this".
Ah, why didn't you just say so two weeks ago? I think you will find
that you are reading a whole lot more into DKIM signatures than other
people are.
I concur with Tony's model that a signature only means "I will accept
the blame for this message".
THe term I prefer is "accountable". "Responsible" goes a bit too far in this
context since it carries with it some connotation of authorship.
Realistically, my MTA is going to sign
mail from all of my users, and although I am willing to accept
responsibility to be sure that they behave themselves, I don't have
the faintest idea what mail they send is new, quoted, sent on behalf
of others (lots, due to third party web and mail hosting) or anything
else. I barely know what domains they use in their return addresses
and I do not know, for example, whether a message with a return
address at one of the little wineries I host is sent by the winery's
management, or someone else (web host) on their behalf. I'm sure not
going to spend any effort forcing them to tag their mail to tell the
difference, since among other things they'd never get it right,
anyway.
Indeed. And we have ample evidence that this is the case.
I expect that my position is similar to that of most ISPs and web hosts.
It certainly agrees with the feedback I get from customers.
I can see that you might want a system full of fine-grained assertions
about mail, but DKIM isn't it, and I doubt that it would be very
useful. It comes back to the failed Lumos model of complex assertions
about mail to be sorted out by recipients. I'm not interested in much
more than one bit to decide either someone's mail is worth accepting
or it's not, and I haven't heard any clamor here for more. I'm
planning to look up the signing domain in whatever passes for a
reputation system, and if it says good, I'll accept it, if it says
bad, I'll reject it, and if it says nothing, I'll send the message
through the filtering gauntlet I use now.
Yeah, I know not everyone feels the way I do, but I think I'm pretty
close to the mainstream here. Everyone? Am I blowing smoke?
John, I am in complete agreement with everything you said here, although
I would have phraswed it a bit differently.
It seems to me that the underlying disagreement here has to do with the
term "signature". In DKIM signatures are nothing but a means to an end:
They provide the means of attaching an accountably identity to a specific
message.
Frankly, if there were some other means of performing this sort of attachment I
would be in favor of using it, because people persist in conflating "signatures
the cryptographic tool" with "signatures as a service". DKIM isn't supposed to
provide a general content signing service, or a general nonrepudiation service,
or any of the other myriad things that can be built on top of "signatures the
cryptographic primitive". The service DKIM provides is the attachment of an
accountable identity to a specific message. Nothing more and nothing less.
And perhaps more to the point, having seen and participated in numerous
extended discussions of signature semantics over the past 15 years or so, I
view it as utter folly to try and extend DKIM into these other areas. If you'll
permit the simile, this isn't a slippery slope, it's the edge of a cliff.
Moreover, we can clearly see four bodies on the rock below. I see no reason to
step forward and join them and every reason to turn around and run away.
Now, Keith will no doubt argue that DKIM is of marginal value at best unless we
extend it into these areas. Simply put, I disagree. For example, even in the
absence of SSP DKIM at a minimum provides a service that can make
whitelisting/blacklisting far more reliable.
Now, if at some point in the future, after this group is done and has "walked
into absence", it makes sense to reuse some or alll of DKIM to provide some of
these other services in lieu of using S/MIME, PGP or whatever, that's fine.
Incremental development is A Good Thing. But we need to focus on a problem
that's just large enough to provide sufficient utility for deployment but not
so large it causes confusion and hesitation. Finding this balance isn't easy,
but I think the current proposals are very close.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org