Re: [dmarc-ietf] Ticket #112 - Authentication vs. Repudiation.

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 29 June 2021 14:54 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4E63A36AF for <dmarc@ietfa.amsl.com>; Tue, 29 Jun 2021 07:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StgM1INxl1aK for <dmarc@ietfa.amsl.com>; Tue, 29 Jun 2021 07:54:34 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E84A3A36AE for <dmarc@ietf.org>; Tue, 29 Jun 2021 07:54:33 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id k206so7679800oif.2 for <dmarc@ietf.org>; Tue, 29 Jun 2021 07:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FSOq8w2Edhpa6tMyqhSWLx7DZcX5nKK1mu+RUvfmVSA=; b=d8fPOhQXSLUvjJ+vhvf43VUd8UU9mdhb4oQBBc1yahelH/bsYFdc1vBAQ9Sy5rgPGC GoTZeQ5vgTb4uluZTCQb8+caSO9jWZtOOMWtt8mqSX0lX0SGoW2gYgWzRB8HKlO9EQaA tX7lti28+eInNuiXl8wLqItrlXyzVUepPD5MP8dcaF/V3Q4vdtWQPEz+8hYVNg6+odca rHF0wQQVrKS62tKA1i0+w/gu/tScWDpLOl2ntFv6Gu5JV3PrPvA/lsVBpd1pQEGlBAcH V3TisHQPxh8n4luDVwnNUTV6OziLaR/uFRA5uGSCSD4D9dC1ccTuYVS9mmrPijt4ZYLX mFgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FSOq8w2Edhpa6tMyqhSWLx7DZcX5nKK1mu+RUvfmVSA=; b=AFsv5DcY3Rx/R8my2jTgayCDfYd5ZibUT8t8mnXg724/zQo/yzPMd4J3nvy88OmK31 NGmGqKLJpv0JrFQedJf4SXfoKxuOmxczy7GFPMt4FCKBAzWRwkSG/xO28EvBYHEuwdJ7 0Vefe12QlcM/3yczRb7YZAfWZvhNO4BxP1xsej0U8D9ULh2VVRHuih2pgSgjW6tify88 NmU8/mRg13FGEFWf8dWDEFH1qNqFTM4oSm7wj8HKx3ZTxZlADrvfC5OlS3al+d2BX8it ci2L/ODaIXR/aHAF4MgugWPRzaicKbdJlUFjLs45Qr2E10HawQ892FFPirZJQqNbdgeZ TRVA==
X-Gm-Message-State: AOAM532kxphd37o/Eo6gFe70vc2AqI78tIs3Uv70+pIosm5StOgpIei5 b+B7mFD+f0p1CZvX7I7IwdtI4yAsNr4b4ZjDwba5R3LQEyke2A==
X-Google-Smtp-Source: ABdhPJyiLn8h3g0vHR+ewGkKj6L1wkS1DdKzB8I3cw4dm/fvO5m9o7IYpd0YW+AVzPZFGMHaFBbQfsBprs995znH6Xc=
X-Received: by 2002:a05:6808:cb:: with SMTP id t11mr8517129oic.73.1624978472720; Tue, 29 Jun 2021 07:54:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAH48Zfyai_qZzMt5VDhpWj5wHrYAyLA5hEssvKXwXn9v006XDg@mail.gmail.com> <CAHej_8=S94d=HU578WekbR8Q-GOKJnfqjED_H4s-P_7hyo-hxw@mail.gmail.com>
In-Reply-To: <CAHej_8=S94d=HU578WekbR8Q-GOKJnfqjED_H4s-P_7hyo-hxw@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 29 Jun 2021 10:54:25 -0400
Message-ID: <CAH48Zfwu-Fdv-=tf_QE-hCKMuNafkfYdLL3jYwqVqFQ_-3d7fA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a25cc405c5e8c8ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/gXwmWAoUJgrR8QaBHAs94NdYowY>
Subject: Re: [dmarc-ietf] Ticket #112 - Authentication vs. Repudiation.
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 14:54:37 -0000

What is so hard to grasp'?

"Treated in a manner that is consistent with the reputation of the
responsible party"
means that
"the message is safe to whitelist if whitelisting is desired."

I was not saying that DMARC=PASS was a basis for whitelisting.   I said
that DMARC=PASS and a trusted identifier is a basis for whitelisting (when
necessary to avoid false positives.)

Any product can do whitelisting based on a single attribute, but
whitelisting requires at least two attributes:  a trusted identifier or set
of identifiers, and a verification status which indicates that the
identifiers are not spoofed.   Therefore the primary value-add from sender
authentication is that it allows me to whitelist messages from trusted
senders to avoid false positives.   As we have both said, sender
authentication=FAIL is a can of worms, but it is not identical with
Repudiate.

BUT MORE TO THE POINT

If you believe that the ex'sting NP language is sufficient and effective,
just explain why you believe this is so.   A justification is all that my
original topics requested, and this has not been done.  For my part, I
don't see a test definition that can be implemented reliably, all I see is
a test name.  Any attempt to code the test introduces questions that have
not been addressed, such as SP="-ALL" and MX= ".".  Similarly, I see a
concept name, "non-existent", which is also undefined.  Any attempt to
interpret "non-existent" will expose ambiguities.   This language is simply
not up to IETF standards.  When I try to fix the language, I find that the
design is not merely vague, it is wrong.

So please answer these questions:

   - Do you believe the problem and the solution are well defined in the
   current specification?
   - Can you explain why the solution is the best possible fit for the
   problem?
   - Have you evaluated the problem and solution against an actual mail
   stream to see if it works?
   - Have you asked someone to attempt an implementation of this part of
   the specification?

In short, the group needs to stop telling me why I don't think straight, or
why I am incomprehensible, why I should shut up, and instead start telling
me what they believe and why.

Those who cannot or will not do these things, should let someone who has
evaluated this idea against a real mail stream take the lead.

Doug Foster