On Sun, May 26, 2019 at 7:49 AM John Levine <jo...@taugh.com> wrote: > In article <54fb29a0-517a-430e-af5b-cb079cc3d...@aegee.org> you write: > >-=-=-=-=-=- > > > >Hello Douglas, > > > >1) Check the Authentication-Results header. An implementation could put > there additional information as comment. A > >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt > trust the previous hop. Common case: aliases > >to random servers. > > That would be my suggestion. You can put whatever you want into comments > in the A-R header. >
At one point in the early DKIM days we were discussing a way to have DKIM verifiers return enough information to signers to indicate what the mutation was that invalidated a message. This was supremely useful in the early days of DKIM when we were just figuring out how to interoperate; if I keep a copy of the the canonicalized header and body of something outbound, and then on receipt you find the signature doesn't validate, then you send me the canonicalized header and body you saw, and I get to diff them to see what mutation broke the signature. We ended up with RFC6651 and the ones to which it references. OpenDKIM implements this, but I don't think any other implementation does, so its use is obviously very limited. And as John said, there have been numerous proposals over the years of ways to annotate a message with what "standard" mutations were done so that at verification time the receiver could decide which mutations it was willing to forgive, but the community showed no interest in such complexities. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
