On 30 Mar 2023, at 10:32, Douglas Foster wrote:
Here is a quick attempt at a definition:
Interoperability: Two (or more) entities cooperating to achieve a
mutual
objective"
Not quite. If a third party does something that causes failure even when
two entities do cooperate on their mutual objective, that's still a
failure of interoperability. Go again to the TCP retransmission example:
If I violate the standard, I can cause you and someone else on the
network who are behaving reasonably to fail in rather impressive ways
(indeed, even taking down whole networks). Documenting interoperability
also means documenting what intermediaries and ancillary players MUST
and MUST NOT do.
Disruption
If a message is blocked inappropriately, the responsibility falls on
the
entity that made the block decision, which is the recipient's
evaluator.
No, that's not the way we write standards in the IETF. Compare: An SMTP
sender definitely has to deal with the possibility of a connection
closing unexpectedly, but the standard still says that an SMTP receiver
"MUST NOT intentionally close the transmission channel until it receives
and replies to a QUIT command (even if there was an error)", and we say
that because we know that not doing so causes problems for some senders.
Saying, "Hey, it's up to the senders to implement things properly" is
all well and good, but we still put requirements on the other end in
order to increase interoperability. So:
The sender's DMARC policy is an input to that decision, it has no
power of its own.
Of course it has power of its own: It is interpreted. You can object to
the way it is interpreted, but if we have operational experience that it
is interpreted in particular ways that cause delivery failures that we
expect should complete reasonably, then it is incumbent on us to
document that some DMARC policies MUST NOT be used in certain
circumstances with known failures. I understand that some people wish
the IETF produced conformance standards, but that's not what we do. When
we see running code that consistently produces bad results, we write the
standard to document that state of affairs.
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.
Well, that's a bit misleading itself. The directive is not "p=signed".
It is called "p=reject" for a reason, and that word is used elsewhere in
the document. It carries meaning. The fact that it has been interpreted
in a particular way should not be surprising. And given that historical
interpretation, we now have an interoperability problem that needs to be
documented appropriately.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
