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

[Douglas Foster <[e-mail]>]

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 <[e-mail]>
wrote:

> On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster <
> [e-mail]> 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
>