[Rspamd-Users] ARC signature validation fails at second hop and dkim.verify()-semantics

Heiko Wundram Heiko.Wundram at gehrkens.it
Tue Dec 3 17:28:52 UTC 2019


Hey all,

I'm trying to get rspamd to ARC-sign outgoing messages relayed through a mailserver, and because I wanted to adapt the signature process to allow pass-ARC-signing of messages that are relayed from a local Exchange server (which changes/"normalizes" headers, so that ARC signatures are broken...), I dug somewhat into plugins/arc.lua, trying to adapt that module to allow arc signing of local/authenticated messages even when bh/b doesn't match, but ARC-Seal is intact. Trying to implement that, I came across two interesting behaviours:

1) arc_sign_seal does not order the ARC-Authentication-Results headers (like it, or rather arc_callback does for ARC seal and signature), so that the loop to build the seal hash might get a wrong order oft he AAR-headers. Is this an oversight?

2) arc_sign_seal hashes the ARC sets in inverse order (i.e., starting at the last i, then walking up). From how I read the ARC RFC, this should be the other way around. Do I understand the corresponding source incorrectly?

3) a second seal (i.e., when relaying a mail that already has an ARC signature, for example microsoft.com) is successfully added, but when testing the ARC chain through another rspamd instance, the signatures verify, but _all_ seals do not. Is this a known problem?

4) I tried to adapt arc.lua to apply the new ARC seal with cv=pass, even though the last ARC signature (but not the ARC seal) fails (basically resigning mails that were "normalized", i.e. munged by Exchange. My adaptations works generally, but I'm somewhat irritated by the semantics of dkim.verify() with the callback mechanism. In what circumstances is the callback actually invoked? From what I gather trying to understand the module source, it's only invoked sometimes (not always), and when it's invoked, the return value of dkim.verify() always signals success (true), and the actual result of signature testing is passed to the callback. When it's not invoked, the return value of dkim.verify() signals failure or success of the testing operation. Is this always correct? Are the corresponding callbacks sometimes supposed to be invoked asynchronously, i.e. when for example lookups need some time? How does arc_callback block on generating the actual result of the tests, if the ARC seal check chain is done asynchronously? Is there any example of using dkim.verify() in other parts of the source?

Thanks for any insights into the above, and thanks for making rspamd!

Heiko


More information about the Users mailing list