> We could attempt to define a dkim canonicalization that would pass through a > mailing list.
This was beaten pretty severely during the DKIM work, and we couldn't come up with anything that was workable. > It should include the subject, but have rules for stripping "standard" > subject prefixes. It should obviously include other headers, but not List-* > headers (since the RFC for those says the mailing list should strip the > existing ones). > > The body is challenging. We could have it specify a length... that does > allow for some weirdness with html positioning. We could require no-html > part. > > We could optionally require footers to be added as separate parts, and have > the canonicalization be for "first text part". Anything that requires mailing list software to change won't work. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. We discussed using l= at (um...) length, and no one liked that approach. There were too many holes, yes: allowing arbitrary amounts of data to be added to the message text, having it fail anyway if text isn't added at the end (such as for multipart messages), and so on. Heuristics involved in tweaking the subject are problematic. Some of this could perhaps work if we had a canonicalization that was *specific* to mailing list posts... but then how would the signing domain know that the message it was signing was going to a mailing list? I really think this isn't a useful approach, but perhaps someone might come up with the necessary "aha" to make it work. Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
