John Levine wrote:
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 I have said more or less the same thing already.
I think you will find that you are reading a whole lot more into DKIM
signatures than other people are.
That would not surprise me.
I concur with Tony's model that a signature only means "I will accept
the blame for this message".
I don't think that flies, or at least, I think that makes DKIM of fairly
marginal value. A message itself is rarely blameworthy; what matters is
the context. If you claim to have authored a message that you didn't
write, that's forgery. The message is still a forgery if the same
message gets forwarded or resent for any of a dozen different reasons.
That doesn't mean it should be deleted, but anyone who reads the message
ought to be able to easily determine that it's not authentic. If you
send lots of advertising to people who don't have any use for a message,
that's spam, but it's not spam if you send the same message to people
who want to receive it. Here what matters is not so much the message
content but who sent it and to whom. If you send an executable
attachment that will compromise a recipient's system, that's an attack,
but the same attachment might reasonably be sent to someone whose job it
is to analyze such content.
So if DKIM is going to be at all useful, it has to distinguish between
an author signing the content and a (re)sender signing "yes, I (re)sent
the message to this set of recipients".
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.
Okay, but why should every signer have to adhere by the limitations of
your situation? Maybe a message is being sent by a bank that wants to
assure its customers that the message is really authentic. Why
shouldn't DKIM enable this? And if it doesn't enable this, how is it
going to address the phishing problem?
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.
And if DKIM is too coarse-grained, it isn't very useful either.
It comes back to the failed Lumos model of complex assertions about
mail to be sorted out by recipients.
Now you're making a big leap, and extrapolating far beyond anything I've
proposed for DKIM.
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.
And what problem does this solve? Why does the fact that mail has
passed through your MTA confer some sort of legitimacy on it, no matter
what the content or the context?
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org