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
