> On May 25, 2024, at 12:49 PM, John R Levine <[email protected]> wrote: > > On Fri, 24 May 2024, Jon Callas wrote: >>> blank lines.) Maybe you can tell it's from a list and the crud is >>> benign, or maybe you can't and you should treat it as suspicious. >> >> And yet, I didn't make up the word robustness, it's there in the spec as >> Dave quoted. > > When I read the whole paragraph, the message I get is that l= is intended to > survive mailing lists but it has many problems so don't use it. My > recollection is that for a few features like l=, most of us found them > useless, a few people really really wanted them, so that paragraph was a way > to get the document out the door. > > Twenty years ago there was no DMARC* and the issue was that until DKIM became > more widely used, mail from dusty lists would have no signatures at all. In > fact lists did start signing pretty quickly, list mail all has DKIM > reputation and that particular issue is moot. > > I do not ever recall l= being an proposed as an invitation to recipient > systems to do surgery on incoming mail. If anyone had ever suggested that, > I'm sure I'm not the only list manager who would have been sure to strip any > l= signatures to prevent downstream funny business. > >> 1) It appears that the issue with l= is that implementers are not doing it >> correctly, ... > > If there ever was a correct way to use l=, there sure isn't now. But per > your next message we seem to agree on the outcome.
Yet, as shown, there are many implementations that support it for usage (outbound) and ignoring (inbound) per the consensus. I did agree with the option and left it as option for sysops to enable/disable. But I agree it was not an answer to restoring original verification and can be a loop hole. All the best, Hector Santos
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
