Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see this appear in a protocol document (maybe some kind of applicability statement).
It does create a circumstance where indirect mail flows look inherently less good (since they take longer), which I don't like. On the other hand, if X is set more than a minute or so in the future, mostly what is affected is mail that is delayed in transit, direct or indirect and maybe that's okay. Scott K On February 17, 2023 5:22:37 PM UTC, "Murray S. Kucherawy" <superu...@gmail.com> wrote: >On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba <barryle...@computer.org> wrote: > >> I like this approach: if the issue is that an "expired" signature is >> treated as unsigned, I think we have an unacceptable level of false >> positives. But if the fact that a signature is valid but expired is >> simply another factor in the decision, I think we might be OK, keeping >> in mind that "x=" is purely advice to the validator. To *really* >> expire a signature, one has to stop publishing the key associated with >> the selector. >> > >One thing that would impede the success of this approach is whether current >implementations make the distinction between "invalid" and "valid but >expired", and for those that do not, how much churn and for how long it >would take to make that change to the ecosystem. > >-MSK _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
