These examples seem to need their own result code. The domain owner will want to know that the signature was intact even though it was rejected, because that tells him something important about the message flow. But he will also want to know that the signature, and possibly the message, was rejected because of insufficient trust.
Pass, Fail, Unacceptable? Doug On Wed, Oct 12, 2022 at 12:39 AM Murray S. Kucherawy <[email protected]> wrote: > On Mon, Oct 10, 2022 at 6:56 PM Douglas Foster < > [email protected]> wrote: > >> Signatures not Evaluated >> ---------------------------------- >> Based on the above, a message may have signatures which lack reported >> results for any of these reasons: >> - The verifier evaluated signatures until its hard limit on the number of >> signatures was reached, then stopped. >> - The verifier evaluated more signatures than the reporting specification >> allows, so it could not report all of them. >> - The verifier evaluated only those signatures needed to obtain a PASS >> result, then stopped evaluating. >> > > Also: > > - The verifier did not evaluate signature(s) that were disqualified due to > matters of local policy. > > Some examples we've discussed before, which a verifier might insist before > considering a signature to be valid (RFC 8601 uses the term "acceptable to > the verifier"): > > - the Subject field was not included in the signature (it's a displayed > field, and so shouldn't be meaningfully altered) > - the "l=" tag was present (it has known security issues) > - the hash or signing algorithm used is considered obsolete or insecure > - the signing key had too few bits of entropy > > All but the last one can be checked without going to the DNS or doing any > crypto-type work, and the signature can be skipped if the verifier's local > requirements are not met. > > -MSK > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
