On Sat, May 21, 2016 at 1:22 PM, Steve Atkins <st...@blighty.com> wrote: > >> 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
Thanks Steve for the details. Some explanation for my deep curiosity.... Mailman (which I hack on here and there) and other MLMs had problems in the past because Mailman modifies the body and appends a footer (as seen on this list). So the advice, years ago, was to strip any incoming DKIM sig, than add a new DKIM sig from the MLM host before reflecting the msg. That worked for years... then multiple DKIM sigs came into parlance, then came DMARC, then came the advice to not strip incoming DKIM sigs and just add a new one. What I would like to do is find a way to keep incoming sigs, keep the mailing list footer, add the MLM's DKIM sig, and have all sigs validate. How does this work in the ESP world where a client originates and signs a msg that is then handed to an ESP who adds a sig and distributes it? Does the client sign the body? -Jim P. _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
