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

Seth Blank <seth@valimail.com> Mon, 14 June 2021 17:45 UTC

Return-Path: <seth@valimail.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 5B68E3A2C26 for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 10:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=valimail.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 vV8DOcfKi_Yp for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 10:45:34 -0700 (PDT)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 4932D3A2C23 for <dmarc@ietf.org>; Mon, 14 Jun 2021 10:45:34 -0700 (PDT)
Received: by mail-vk1-xa2e.google.com with SMTP id 184so4335295vkz.13 for <dmarc@ietf.org>; Mon, 14 Jun 2021 10:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KzvY503In23kSDrl+9Amv/sjB8SL8z5pHmpfpguPevk=; b=ZLHOG6LFD7d25moEVpIHeawBxNMcmBYlPUZLUrcl8JC3jym1UMsk8tyrzI19tlY+Ue NhvlWg8eK0VbOWzsgyOEPqeRF35UH/hwbXPUTcNWHKXqsCwHLQdDVpJAAPhhfdKR9bmX YKTw12rzf1ZbxYM6O8cOrnnFl0lz6vzR2R9TD4dby841fgMeaUsWs/3eAGNIeB+XHDAa JG81OaE1eZ3aLzq1pmJoEckgp3twGKdi1GaIQGIeBe8v6Hx36niaCb8Cf89J/R7LEUYL 1zXEKHb2HST5qvyIPRyFh2Jd9UH/IDsomAfbz8pNgxGtCsHh5zBDQsEW9JDirLgwwHnA kFyA==
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=KzvY503In23kSDrl+9Amv/sjB8SL8z5pHmpfpguPevk=; b=saxqBAdPnCpEEOWtFLyKa0fNUcLoO0BsYixOcxtHqlytkNpC/0bnuH4cvDTm8qaDxn kICdnvNCwLiCpR3AKcDu45OfVTKZTrimZQeqd0mAUH+qPZinX9arfsctce/K5qdm1uIl m7nX2v5SGZ2IIqHDgpTK/j7oCk78eItsMwChMCaPAEpFnUKapkIV8S/EgjPk4K+gIEYp GjSuqlV2UsQgEPR4AQsUZAmzlQC0sRPfXZfipU6AmDx9pmUlqaEM3zcsZkADp25J3RYy w0+2M7mbU5Rm05DiDWfxxJHo6BfyldjM0ykWSDVMvYN6VhpYNGIBnBL0MggYWn2qd6wH qQFA==
X-Gm-Message-State: AOAM531AnmFRk5jYUnQUItzQFqGbqyftQBTSeDhJTspvmq3dj8lIIY16 WbDEz/jBoBhhDrJGOPo2JAatLeJeAw3HvwbRF88Ttg==
X-Google-Smtp-Source: ABdhPJxshwufMT34X92Aw4wdu/sXFI3+dQ5QHHXYfg2+adtR2xmiCoAMf4WDKUWNeP7v3XCKRNfRaz0Rf8ZbY+veZy4=
X-Received: by 2002:a1f:2e86:: with SMTP id u128mr74673vku.22.1623692731847; Mon, 14 Jun 2021 10:45:31 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Seth Blank <seth@valimail.com>
Date: Mon, 14 Jun 2021 10:45:21 -0700
Message-ID: <CAOZAAfM4w2nNcDcdqXXtDf1_H7Ah1Py1gO0Yjm1byh3eKXzTUQ@mail.gmail.com>
To: "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000081a61905c4bd6ca2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Y317Xm8BwGSxZZ_N7dRKej0KoAk>
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:45:40 -0000

HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must
pass aligned. This proposal breaks that foundationally.

This is suggested quite frequently, but fails to understand just how few
senders of email actually send with DKIM. Most email is sent from services
that have a core business that's not in email, and when we're lucky, they
manage to publish an SPF record for their customers to use. Only large
volume sophisticated services tend to do DKIM.

A domain owner that requires everything that sends on its behalf to use
DKIM basically shoots itself in the foot, and makes most of the services
they'd need to use unavailable to themselves.

The correct answer is what you said: domain owners who want this should
only authenticate services using DKIM.

Seth


On Mon, Jun 14, 2021 at 10:10 AM 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
>


-- 

*Seth Blank* | VP, Product
*e:* seth@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.