On Wed, Aug 20, 2025 at 2:06 PM Phillip Tao <[email protected]> wrote:
> > so if they're not going to sign it makes sense for them not to verify > either. > > I don't think this necessarily follows from the preceding statement. > I think he meant: Client-to-client signing means the clients at each end need to be able to do their bit, but if one end can't, then the other is moot. Instead, signer-to-verifier operation where the signer is a domain MTA but the verifier is an MUA is possible. But you run into things like rotating keys causing signatures to be invalid. I think we talked about that upthread. Also some operators use very short "x=" values as a way to mitigate replay attacks (contrary to the standard), resulting in what you might think of as false negatives. There are probably other threats to this model I'm not thinking about without more coffee. Overall, I'd say client-side verifying might work for some or even most cases, but I don't think I'd consider it to be very reliable. > However, we've found that there are other policy decisions we want to > apply to messages based on DKIM/DMARC status. For technical, security, and > liability reasons, simply getting the DKIM/DMARC status from the > Authentication-Results is not sufficient for this. > Can you explain why? This is exactly what A-R was made to do. -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
