Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Zachary Aab <zachary.aab@gmail.com> Mon, 14 June 2021 17:41 UTC

Return-Path: <zachary.aab@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 55E803A2C07 for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 10:41:28 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YXX4K8lAg2hd for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 10:41:23 -0700 (PDT)
Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 203E23A2C08 for <dmarc@ietf.org>; Mon, 14 Jun 2021 10:41:22 -0700 (PDT)
Received: by mail-oo1-xc31.google.com with SMTP id j17-20020a0568200231b029024900620310so2845971oob.7 for <dmarc@ietf.org>; Mon, 14 Jun 2021 10:41:22 -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 :cc; bh=eOWDjMkzL+EK1vBKc4sSx42rUgHsIJJ3vzHnHhlcM0I=; b=sDY/f1fB5/tRzCuW9DMH9QGJwhkaKOXC+s6nCffukG43KbQbN19YQstxnXZTQvTTy2 ZVSdBSkr5mNWsIWh/F08vtG5KGV7FV35lkvm9IxG+SjhSgqoWWvEhL9XzPhNAZYKkUFa OQ+Xos7fUh78HMVsDX2GROKX9/5MfVZLgUi9F1pehST6upnSbrV11IeWcQtNJdG7VMqt ZVX68JCF0404GtHwTcO4ZipDz4DMk3paY4VXxe6CldStpMU5ZvT3l7Zs8XXAC0NUVM0f iK8R/ID9dHuNn7zbpiQR+YJXHxnAhvi/nviItQ+E/RXO38hSHaxidNLzabO6/61YxYHF 01dw==
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:cc; bh=eOWDjMkzL+EK1vBKc4sSx42rUgHsIJJ3vzHnHhlcM0I=; b=k2y28+ZtLD5BGtHgTr/SZf6g2Yogu+cGMlBrTSYp4GucPV5L1Lv3pOFg33LD+2Tx3R +LVq0jyUn1mZDYLfWOxOtQFlOEkEzmn+JYAGohNKTU3qyYlsTtaIbUnqU1AwebFptyzC sNPJ9PALEzMSM7RmPyjBVhvb1uJW/Hf/XZQJnpyqCLG2Q5zRCeHJSV+EnSFXfePVnpV3 BktWLwJR5U35SaejHSovQE0EPOAt3u9Tmbr5ljC+Nt5MmXJCf9pdctxc8nxYL2TtGQRR sPnEw6THK0V6IteyHnVvKCJQvFaMio8dh6TedenIs9BRZTRPK4Ku326nCyQcF7KjFUo+ 6ZbQ==
X-Gm-Message-State: AOAM530AWqtJba0PQmdjhBW7ZvNJQD/hLbMtt+yXs2yPql9m6wgtXF2q DrUFGh/Zg4T/m1y6GMnCtE7cqEm3OIFOMKwti6XxdINoj/nd9A==
X-Google-Smtp-Source: ABdhPJxx4+RXSWGL3nguFfha8ydc4fIsutU0onxj8TVcous1CgRv/VM+WRPm4XSGlf/cMWpugk958nbxHlPmeRHDZNc=
X-Received: by 2002:a4a:dd8d:: with SMTP id h13mr13887036oov.84.1623692480660; Mon, 14 Jun 2021 10:41:20 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Zachary Aab <zachary.aab@gmail.com>
Date: Mon, 14 Jun 2021 13:41:09 -0400
Message-ID: <CAD8zhRdWwZ4tHKNbZvuFHy1seLJ0VqQ7+r-5SowJJ7Hqssm9xQ@mail.gmail.com>
To: "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088c6f305c4bd5dd9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Y50xZyKSeuOmEIWSXSVLY6J0x9I>
Subject: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC
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: Mon, 14 Jun 2021 17:41:28 -0000

This rings to me like something that would look like the simple/relaxed
alignment option currently in DMARC.  "Require aligned DKIM" being
something along the lines of "rdkim=y; rspf=n;" with the
not-included/default value being "n."
If you agree that adding it is simple enough, the real question is what
value does this really add to DMARC and/or will it improve DMARC adoption?
Personally, I think it would be generally welcomed among senders who like
really granular control over their authentication or who don't fully
understand DMARC's "defaults" (for example, senders who use "p=reject;
pct=100;").

On Mon, Jun 14, 2021 at 1:10 PM Brotman, Alex <Alex_Brotman=
40comcast.com@dmarc.ietf.org> wrote:

> Hello,
>
> I was talking to some folks about DMARC, and a question came as to suggest
> as the domain holder that your messages should always pass DKIM.
> Effectively, the asker wants to say "I intend to deploy SPF and DKIM, but I
> will *always* sign my messages with DKIM."  So the obvious answer may be
> "Just only use DKIM", but I'm not sure that completely answers the
> question.  While discussing with someone else, "Tell me when DKIM fails,
> but SPF is fully aligned".  There was recently an incident at a provider
> where they were allowing any sender to send as any domain (and I'm aware
> that's not specifically a DMARC issue).  We all know brands that have just
> dumped in a pile of "include" statements without fully understanding the
> implications.  In this case, other users could send as other domains, but
> perhaps they would not have been DKIM signed.  Should there be a method by
> which a domain holder can say "We want all message to have both, or be
> treated as a failure", or "We'll provide both, but DKI
>  M is a must"?
>
> >From a receiver side, it makes evaluation more complex.  From a sender
> side, it gives them more control over what is considered pass/fail.
>
> How does this look in practice?  Maybe
> "v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
> (pm=Policy Matrix)
>
> Does this make everyone cringe, or perhaps worth a larger discussion?
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>