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

[Douglas Foster <[e-mail]>]

I would be happy with p=signed, because that is what p=reject means, and it
is our job is to ensure that people interpret the signal correctly.

But for those who believe (a) that sender policy is the problem and (b)
that the mailing lists should not be inconvenienced, there is a simple way
to force the issue.

"We are sorry, but your post to this list cannot be accepted because your
account is in listen-only mode.   This has become necessary because your
domain has published a DMARC policy which prevents us from making changes
to your post and then presenting the result as if it had been part of your
original submission.   To return to bi-directiional participation, you must
convince your domain to change its DMARC policy or change your subscription
to an email account on a different domain with a weaker DMARC policy."

Apparently universities acceded to this type of pressure.

I am not an alchemist that can make gold out of straw or make secure email
out of insecure practices.   The power to change a message in transit
includes the power to change it maliciously.   That makes it a privileged
function which requires prior authorization.   The only way to get that
permission is to ask for it from the evaluator, and to demonstrate to its
satisfaction that your messages can be trusted.

There is no reliable algorithm for reliably distinguishing mailing list
messages from all other messages, much less an algorithm for identifying
mailing list messages from trustworthy list sources.   In the absence of
that ideal, I cannot provide automatic privileges to mailing list
messages.   Lists are asking for the impossible.

DF

On Thu, Mar 30, 2023 at 12:45 AM Pete Resnick <[e-mail]> wrote:

> 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
>