Here is a quick attempt at a definition: Interoperability: Two (or more) entities cooperating to achieve a mutual objective"
Interoperability can perhaps be illustrated by design for a VPN tunnel or other encryption mechanism: 1) You have to know the identity of the other party. It does not matter that you have transport security if you are sending your message to the bad guys. For VPN, this uses per-shared keys or digital certificates among other options. For email, forwarding hides some of the originator's identity, and forwarding with identity rewrite hides the rest. 2) You have to know if you have received all of the message/ If it has to be broken into pieces for transmission, you need to find all the pieces and reassemble them in order. Transport protocols handle this well. 3) You have to know if the message or message component has been altered in transit. For VPN, "MAC" hash values demonstrate this. For email, DKIM verifies this. In either system, a failed hash is supposed to indicate loss of trustworthiness. 4) You have to have an error recovery / exception management process. For VPN, this is retransmission. For email, IETF has carefully avoided any discussion of error recovery and exception management. I don't know why. Of course, trust would not be a problem is all email was wanted and trustworthy. The forwarding problem exists because fraudulent mail exists, and it is nearly impossible to distinguish a legitimate forwarded message chain from a fraudulently constructed one. Disruption If a message is blocked inappropriately, the responsibility falls on the entity that made the block decision, which is the recipient's evaluator. The sender's DMARC policy is an input to that decision, it has no power of its own. The previous and proposed DMARC specifications are misleading because they communicate false certainty. The only thing that a sender can assert is that all of the messages originated by him will be properly signed by him. Even when that assertion is made, it may or may not be true. But it cannot say whether an unauthorized message was done for beneficial or malicious purposes. It cannot control whether a recipient decides to forward the message. In short, the damage happens because evaluators have been misled by the specification, believing that all FAILs are malicious. This is a widespread and pernicious belief, which is created and sustained by IETF documents. The optimal handling of authentication failures is quarantine, followed by a decision: if the source is a malicious impersonation, block the current and all future messages. If the source is legitimate, create a local policy which authenticates in place of the failed SPF or DMARC check. In either case, the disposition of future messages are unambiguous. More specifically, the damage often comes from product developers who develop to the specification, without a nuanced understanding of real world filtering. Without good options for handling exceptions, the system administrators are hamstrung. Our spec needs to fix the evaluators, and their products, not the sender policy. DF -- On Wed, Mar 29, 2023 at 8:52 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> There is no interoperability problem. >> > > How are you defining interoperability? > > "p=reject" when used on domains that send non-transactional messages > disrupts interoperability of the email ecosystem in ways that are well > documented. This collateral damage is not trivial. > > There's no interoperability problem at the DMARC layer, sure. But there's > a bigger story we need to consider. > > An evaluator has an unlimited right to block any incoming message for any >> reason. >> > Specifically, an evaluator has the right to block any message which he >> determines to be insufficiently authenticated. >> > > An operator has every right to block DNS queries of types they don't like > or don't recognize. The choice to do so by some firewalls was the source > of the problems behind the introduction of the SPF resource record. That's > a pretty broad kind of disruption that I would claim also shouldn't have > been ignored or dismissed. (See RFC 6686, Appendix A, for this story.) > > >> If a sender wants a message to be accepted, he carries the burden of >> earning the evaluator's trust. He has no right to have his message >> delivered. >> >> [...] >> >> If an evaluator blocks a message that a user considers acceptable, that >> is a management issue between the user and the administrator. It happens >> all the time, and it is resolved through normal support processes. >> > > I don't think anyone's arguing that. But does the receiver in your > scenario also have a right to impact the experiences of users not under > their control? If we're going to argue that the receiver's rights are the > only thing that matter, we'd better be able to explain why the collateral > damage is justifiable. > > -MSK, participating >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
