Keith Moore wrote:
Ok, tell us what the right functionality is.
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?
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.
> 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.
(This is tricky but I think it's doable. You probably end up with a
different set of field names every time you submit a message, e.g.
submission-0:, submission-1: in order to finesse problems with
duplicate fields and reordering, but that's cool because it lets
subsequent submissions sign the fields from earlier submissions.)
This is possible too, I think. PHB suggested using a numbering
scheme, I think, which would probably be easier to untangle.
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.
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. See
my comment to Mark Delany re: what Yahoo! is claiming in their
client vs. what I think people read it as.
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.
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.)
Mike
_______________________________________________
ietf-dkim mailing list
http://dkim.org