> > I'm still thinking about it. Part of the answer, I think, is to have > > DKIM separate signing of the _content_ (presumably, by the author), > > from signing of the _submission_ (by the submitting party). Each time > > a message were forwarded or resent, this would be a subsequent > > submission which could also be signed without discarding records of > > previous submissions. > > I'm not sure I understand what you mean by content and > the submission. Are you talking about parts of the message > or the actors involved? Or something else?
Content = what's in the message. Signed content is a verifiable statement that says "Alice wrote this message" or "Alice authorized this message". Submission = the act of sending a message to specific recipients. Signed submission is a verifiable statement that says "I sent this message to recipients Alice, Bob, and Carol" > > So the headers of a message could contain > > several signed submission records detailing the entire submission > > history of that message. Each signed submission would have its own > > hash, its own list of headers, etc. > > DKIM has the ability to do this now via multiple signatures > in the same message. My implementation allows for it, in > fact. IIRC DKIM can't sign envelope fields, and it doesn't clearly distinguish between author and sender roles. > > Submission records also need to > > validate envelope recipient addresses. > > I don't understand what this means. About the only thing > that I can think of that "validates" a RCPT TO is the > next hop not bouncing it outright. sorry, I phrased that poorly. I hope the above description is clearer. > > It would then make sense for an MUA or filter to derive identites > > like "initially-submitted-by" and "last-submitted-by" from the > > authenticated submission information. > > Would this pass the My Mother test? I'm fairly skeptical that > the human factors people would be very keen on loading up > a bunch of new identities for people to keep track of. In > fact, I doubt that 1 person in 10 could give you a passable > definition of what Sender is, and that's currently displayed > fairly often. In order to even begin to answer that question with any confidence, we'd first need to do a case analysis, and then we'd need to try to design user interfaces to handle those cases, and then we'd need to subject those user interfaces to testing by randomly-selected users. We might want to measure existing email users separately from those who don't currently use email - because in the long term the latter group might be a better predictor than a group that is conditioned by current MUAs and protocols. And until we do this - this entire discussion is conjecture. But yes, I think it's feasible to design user interfaces that would make these distinctions clear to your (or my) mother. I certainly don't expect users to understand and distinguish the subtle differences between From, Sender, signer, forwarder, etc. when presented in that way. But I do think that a future MUA could reasonably do something like the following when presenting received mail: a. (default) Message is authored (From) by A, signed by A, and submitted by A to be sent to your mother. Just show the From field and perhaps some icon showing that the message was signed. b. Message was authored by A, signed by A, but initially submitted to some other address and later forwarded to your mother. Show the From field but also show a highlighted alert that says "this message was not sent to you by the author of the message, but was forwarded to you by <address>". c. Message was authored by A but signed by someone else. Show the From field but also show a highlighted alert that says "This message claims to be written by A but was signed by B". etc. Once I do the case analysis I suspect I'll find that there are several cases that can be grouped together. But at any rate, I don't think we serve the interests of the user community by either crippling the mail system or by making DKIM so simplistic that it doesn't accurately represent what actually happened to the message. > For my part, I think that the From address is about the only > thing that that anybody pays regular attention to, and if > we're going to provide any new assurances it needs to > align with what they know, or at least think they know. You are assuming current users, current MUAs, current protocols without DKIM, current expectations based on these. I'm assuming that new users and new MUAs will eventually be significant, and that they'll be more sophisticated. Users do adapt, though perhaps they do so slowly. A few years ago users would blindly enable cookies in web browsers and forget about them, now significant numbers of users are periodically deleting them. Many users change their email addresses periodically so that they'll get less spam and maintain separate accounts for casual correspondence between acquaintances, serious correspondence between close friends, etc. - changing the casual address more often than the others. Many users have figured out that when sending a message to large numbers of recipients, it's a good idea to use Bcc so that the replies don't go to everyone. etc. > Ok, I just did the SO test in lieu of My Mother and upon > looking at a Sender for this list, sez he "is that your > new thingy?" (meaning, DKIM). Asked if ListId meant anything > to him, "does it have something to do with the Cc?"... so, > I really wouldn't be too hopeful about any expectation that > anybody's going to understand much beyond color codes, > cutsey icons, or very simple text next to the From address. And again, I certainly don't expect users to sort out this stuff by looking at message headers. (they couldn't verify the signatures by looking at them anyway). So yes, cutsey icons and simple text displayed above the message on a colored background is very much what I have in mind. > > 1) at the time multipart/signed was defined there were still a lot of > > people using legacy MUAs that didn't handle multiparts properly, and > > certainly didn't handle multipart/signed properly. So you didn't want > > to enable multipart/signed on all outgoing messages. > > According to what I've heard, the situation is still pretty > grim. > > >>From the big picture view, the number of MUAs that will get tweaked to > > display this information - as opposed to simply being upgraded - is > > probably insignificant. But being able to tweak existing MUAs is > > useful to permit experimentation by early adopters. > > Possibly -- I'd be happy if this were incorporated quickly. But > we didn't want to have to insist on it happening. FWIW, we've been > looking internally as to how to show users that "this piece of mail > really came `from' Cisco" from phishing attacks, and the resulting > case overload for IT of people reporting our spam^H^H^H^Hcompany > internal mail as possible phishing. There are a variety of ways we can > go about presenting this now. I'll note that somebody has a DK > Thunderbird plugin now which presumably does something interesting to > the result (I've been meaning to dissect it, but haven't got around > to it.) I'll have to look at it. Maybe we should all try to eat our own dogfood and use DKIM as much as possible on this list. Keith _______________________________________________ ietf-dkim mailing list http://dkim.org
