John Levine writes: > >I do not understand this predilection for trying to change the DKIM base > >engine. It doesn't need it. > > Actually, I claim that a version bump is the approach least likely to > break existing clients.
The point is to avoid breaking the anti-spam *system*. If the system continues to work (in some appropriate sense) in the presence of clients "broken" in some sense, that's a win. > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, so of course it "accepts" weak signatures. It accepts invalid and nonexistent signatures, too. By this I suppose you mean that spamassassin does not distinguish among levels of content coverage of signatures it detects and verifies, so different spamminess coefficients can't be assigned? _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
