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 >
- [dmarc-ietf] Sender-supplied decision matrix for … Brotman, Alex
- Re: [dmarc-ietf] Sender-supplied decision matrix … Zachary Aab
- Re: [dmarc-ietf] Sender-supplied decision matrix … Seth Blank
- Re: [dmarc-ietf] Sender-supplied decision matrix … Tobias Herkula
- Re: [dmarc-ietf] Sender-supplied decision matrix … Ken O'Driscoll
- Re: [dmarc-ietf] Sender-supplied decision matrix … John Levine
- Re: [dmarc-ietf] Sender-supplied decision matrix … Steven M Jones