On Tue, Apr 1, 2025 at 10:26 AM Alessandro Vesely <ves...@tana.it> wrote:
> The resulting DKIM verifier is not semi-broken, it's DKIM2-tolerant. And > it's > not just a library change, it's also the MTA interface. > First you said: "a DKIM1 verifier will be able to verify a DKIM2 signature, limited to DKIM1 semantics", but I don't know what this means. I'm assuming by "semantics" you mean DKIM2 presumably will have its own way of interpreting or even developing the pass/fail result. I think what you're saying means we would need (or STD 76 would implicitly impose) a mapping from DKIM2 semantics to DKIM semantics. If I have all that right, I think we're saying that we probably don't want this, or at least there are some undesirable failure modes in that direction, such as a DKIM2 signature that should fail but DKIM passes it, or vice versa. Then you said: "a DKIM1 verifier could be updated to handle DKIM2 signatures —if DKIM2 signatures were specified with compatibility in mind", but if they're compatible (your premise), what update is needed? Then "The verifier might not be fully DKIM2 compliant, perhaps because the MTA interface does not support it or for some other reason." To me those are mutually exclusive; a DKIM verifier that doesn't have access to the envelope, say, can't possibly verify a DKIM2 signature. That part, at least, is harmless, except when you consider that the industry does, contrary to our advice, sometimes degrade the value of a message bearing a failed signature. If I'm still misunderstanding, then you're going to have to make this concrete with an example. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
