On 26 Dec 2024, at 7:24, Barry Leiba wrote: >>> So would I but there's way too many SPF-only DMARC users and it would be a >>> breaking change. >> >> So we have SPF-only DMARC users, and DKIM-only DMARC users, and they could >> easily come to opposite >> conclusions about the same message. Maybe it’s not interoperability in the >> same sense as disjoint cipher suites, >> but this seems like an interoperability problem to me. > > "Users" here means "senders", so it's not a question of resolving a > message differently. It would be great to get to where everyone signs > with DKIM (on the sending end) and no one has to check SPF any more > (on the receiving end), but we're not there yet. > > But do keep in mind that different receivers may still "come to > opposite conclusions about the same message" with respect to how they > decide to handle the message, because it's still controlled by local > policy. Different receivers should agree on the authentication > aspect, but one might reject the message (seeing "p=reject" and > agreeing to it), another might put it in the user's spam folder > (seeing "p=reject" and treating it like quarantine), and a third might > deliver it to the user's inbox (accepting it as a legitimate > mailing-list message that failed authentication for that reason). > That's not an interop problem: that's how local policy works.
Barry and Todd, Thanks for setting me straight on the meaning of “DMARC users”. Still, I wonder about those users publishing a DMARC policy and only supporting SPF; it doesn’t seem that would work out very well for them. When counting DMARC users, are we counting everyone who publishes a DMARC record, or only those who publish a record that has some effect (perhaps excluding those with records saying p=none and no reporting)? But that’s just a rhetorical question, because the WG consensus was to keep SPF. -Jim _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
