On Tue, 2005-08-23 at 07:58 -0400, Keith Moore wrote:
John Levine wrote:
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".
Concluding there is significance for a mailbox address assumes mailbox-
addresses are normally constrained by the signing domains, or that DKIM
establishes an appendage of mailbox-address authorizations. It also
seems you want this to include some type of path registrations to
regulate forwarding and mailing lists as well. The overhead and
billions of possible relationships to approach this ideal remains
daunting without using per-user-keys. If this is the goal, then
something more like S/MIME would be far more suitable.
I would rather ALWAYS hold the signing domain accountable for any type
of abuse. However, have the signing domain include another new
identity. This new identity would be used by the domain to quickly
retract authorization and to permit rapid correlation of abuse. Call it
u=<revocation-identifier>. Add a proviso. When the key is flagged as
delegated, the selector becomes this identifier.
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?
MUAs will need to change in order to make assuring any mailbox-address
be meaningful due to issues of what gets displayed, such as various
headers and pretty names. If the MUA must change, then why not expect
the MUA to capture bindings of <mailbox-address,signing-
domain,revocation-identifier> as a means of alerting them of a phish?
This would help keep DKIM on a diet, while addressing the targeted
replay issue.
Much of the efforts to combat abuse is related to correlation. Because
it would be overly optimistic to expect signing domains to always
constrain mailbox-addresses, or that DNS can handle mailbox-address
authorizations, a different identifier instead would be helpful in this
regard. This identifier only needs to be meaningful to the signing
domain. It would also be a powerful tool to combat abuse.
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.
The revocation-identifier restores fine grain resolution without
changing how providers are used. It does not require huge amounts of
information be published in DNS to create mailbox-address authorizations
or path registrations. It does not increase the size of IT staff
configuring DNS records for email, or dealing with complaints when email
no longer functions as expected.
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?
As with any provider that finds their client's email generally accepted.
It would be their governance in removing those that abuse.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org