> On May 21, 2016, at 9:41 AM, Jim Popovitch <jim...@gmail.com> wrote: > > On Sat, May 21, 2016 at 12:23 PM, Steve Atkins <st...@blighty.com> wrote: >> >>> On May 21, 2016, at 8:45 AM, Jim Popovitch <jim...@gmail.com> wrote: >>> >>> On Fri, May 20, 2016 at 5:21 PM, Michael Rathbun <m...@honet.com> wrote: >>>> On Fri, 20 May 2016 17:00:37 -0400, Jim Popovitch <jim...@gmail.com> wrote: >>>> >>>>> Give me a (real world) example of how 2 DKIM sigs will be in the same >>>>> email msg and both sigs will verify. >>>> >>>> Here are two: >>>> >>>>> Authentication-Results: mx.google.com; >>>>> dkim=pass (test mode) header.i=@humblebundle.com; >>>>> dkim=pass (test mode) header.i=@dynect.net; >>>> >>>>> Authentication-Results: mx.google.com; >>>>> dkim=pass header.i=@cpro30.com; >>>>> dkim=pass header.i=@morningconsult.com; >>>> >>> >>> >>> That's quite vague. What was signed by each key? When most people >>> think of DKIM they think of a DKIM key being used to guarantee that >>> parts of a message haven't been modified in transit. >> >> If they do, they're thinking about it wrong. DKIM is *not* about message >> integrity, it's about someone taking responsibility for the message in >> a way that is provable by a third party. Or, if you prefer a more mechanical >> model, it's about attaching an unforgeable identifier to a message so that >> that identifier can be used as a key to track the history of the email >> author. > > Email is multi-faceted. I really don't think there is any one person > who has seen all sides and knows whats best for all sides.
It's not about what's "best", it's about understanding what a protocol is, and what it provides. That's important because if someone misunderstands what DKIM is for, you they misusing the results it provides. > Correct me if I am wrong (with details please). ESPs are the only > ones using 2 or more DKIM sigs, and one or more of those DKIM sigs is > just an identifier injected along the way, that seeks to verify the > middle-man by signing zero or a few headers (but not any headers wrt > deliverability, hops, received lines, etc.) *All* DKIM signatures are just identifiers injected along the way. All reasonable[1] DKIM signatures sign a sensible subset of the headers and the entire body. There is no "primary" or "main" DKIM signature. A message may have zero or more DKIM signatures; none is intrinsically more valid or valuable than the others. There is an order to them, but that's just the order in which the signatures were applied rather than anything inherently meaningful. (Though, obviously, you can intuit things from the order, and there is broken software out there that, for example, treats the first or last DKIM signature differently. And there are protocols out there that pay more attention to DKIM identifiers that bytewise match other elements of the email. That's all outside the scope of DKIM itself.) The result of validating DKIM is a list of zero or more identifiers (one from each DKIM signature that validates). Mailserver automation can do whatever it pleases with that result, but that's the only information it gets from DKIM - a list of zero or more identifiers (typically the d= value from each DKIM-Signature header). Cheers, Steve [1] There's a lot of leeway in the DKIM spec about what you can sign and still be a "valid" DKIM signature, but that's mostly theoretical. In the wild you'll see everyone signing something like mime-version, in-reply-to, references, date, message-id, subject, from, to and the entire body. _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
