Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Pete Resnick <[e-mail]>]

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