[dmarc-ietf] Trying to understand DMARC in light of Sender/indicators
Brandon Long <blong@google.com> Wed, 30 September 2020 01:56 UTC
Return-Path: <blong@google.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 57B6C3A0A7D for <dmarc@ietfa.amsl.com>; Tue, 29 Sep 2020 18:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Q94pVrcsLjVh for <dmarc@ietfa.amsl.com>; Tue, 29 Sep 2020 18:56:47 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 764D33A0A56 for <dmarc@ietf.org>; Tue, 29 Sep 2020 18:56:47 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id 7so165155vsp.6 for <dmarc@ietf.org>; Tue, 29 Sep 2020 18:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gNDy4dtt0LLuJi40e9lwT2Kq/KmJBV9PakfXcx6FELs=; b=JsYQfnzSs4M2AWFuERw3VriyCGEf1tb+xfDNhlhGtCTCiEYfO4AAH9Pq39pHXLLsWr mHlD8T+3yZBB3DRieljljgmec1rLGPcMXY+IefXen53xD8T83iTeG/eGifOE/nJ3S3pz y9rEezr6Kor9sMyLW9PfHmfv0W41j7nLYOYiVK77BytkBdNB0yDw3CwnyV1K794weUPF B5C5JyUHRvFBfita85P6FbnkBKPy/mtw8rQgGdpKxcMLzgAu3Mg4XGfDtx5aj5i7ndDO A497ZC6jKLYB0JoEK4XHMjwvLpjcpk00/bZnPYEEkUiQYH9+6RQTl5pxzNu7ltfGMu3j 77QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gNDy4dtt0LLuJi40e9lwT2Kq/KmJBV9PakfXcx6FELs=; b=JG85Vt6AC8JrDFOvBEhi3CRhe+tcBH0GkBIndMhViwMKHJ6XBITJ1T4bR82DyGWpuB kM57HIbA66k1iJJQB5jSox2B60q9jWEYabpFvAorHHzmjR4AowzY8Ca4N6QSc6NqDAke MGoYpdAnbeJFkZNJ0YXnzhxeHslv0iQg4DJ41LmdrL02pZXMPQlmDe39nE5fV7XlLrb2 aCJVpeHKDVIWbpOHRReBGW2MnGAq1WTBDJXbC9wDtNjYEGkN8q5LHjapU4xJt+UoisTn jotTJBDiIjf7Rak0QD6dWwOrI9BGSMfRddgWNZnZtBeWlBTbgCiOfvung4Ga+n+Tl+0d 6bUw==
X-Gm-Message-State: AOAM531TRLQOB5ssw0WJ0IKfnDKKSVLbs43LEwAp1VeZ7oyj+r8/w4Hf CkzWFiQaf1zjmA5t+7axoF2+JKmOhJV44LxBCncNIZCmVcAS
X-Google-Smtp-Source: ABdhPJyj/XN1ve19DHkuO4ZhWCU0h6eT7Bl5WUeOH/WHuHuCOFhuJQ+7LHXYWoMPyZI+o5WNiU5fbdnmPWq/upKClJs=
X-Received: by 2002:a05:6102:22e9:: with SMTP id b9mr72901vsh.55.1601431005377; Tue, 29 Sep 2020 18:56:45 -0700 (PDT)
MIME-Version: 1.0
From: Brandon Long <blong@google.com>
Date: Tue, 29 Sep 2020 18:56:33 -0700
Message-ID: <CABa8R6u-mcaUD8Nkz0o8LVU9OXbwW0=+FjvzSz9xer60h_ckfQ@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035bf8805b07e36b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/GB_SNr55eNAjLgH5z2fo8i-e88c>
Subject: [dmarc-ietf] Trying to understand DMARC in light of Sender/indicators
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: Wed, 30 Sep 2020 01:56:49 -0000
Although I'm not fully convinced by Dave's point on whether indicators are useless (they certainly are not of large value, I'm less certain in the margins).. I think I need to work through what DMARC is without that. DMARC is composed of three things: alignment, policy and reporting. I think the argument is that the most important thing that DMARC brings is message authentication.. but that's not actually what DMARC brings, but perhaps we can view the point of DMARC as pushing forward the authenticated message agenda. In some ways, it's well defined to be such a forcing function. Policy and alignment make it easy for various bodies to point to it as something they require entities to do, and reporting gives them the path to do it and measure their success against it. Alignment makes policy application easy, and it also makes reporting easy. The Sender proposal hijacks the alignment, bringing in another possible policy to enforce and a different potential reporting path. The draft makes it clear which policy is enforced (though of course that only works if the receiver supports the Sender extension), but various folks on the list have referred to the matrix problem of looking at the policies of both, so at least it brings confusion. It does provide confusion of "ownership". DMARC currently provides very clear ownership, even if that is overly simplified for the pre-existing ecosystem. Adding Sender muddies that, even if it is a better match. If both Sender & From fail evaluation, do we report to both? Should we report Sender overrides to the From, should we report which From we're overriding to the Sender? How does the Sender overrider benefit from reporting? They'll have even less opportunity to "fix" things, since presumably they have a more straightforward role, and without the existence of the header, they have no role at all, so the best it could be is "places we add the header but fail to sign" or all the other normal intermediary cases where DMARC currently fails. Does DMARC that allows third party overrides via Sender provide the same incentive to originators? In the sense that it makes it easier to get to p=reject as there are fewer false rejects, probably. In the sense that it undermines the simple explanation for what DMARC does, I think it will harm DMARC adoption. ""Why did this phishing message get through" "Because example.com added a Sender header that's aligned" "What's the point of me doing all this if it can be bypassed that easily?" "See, the receiving system knows it wasn't yours and so it's on them that they didn't catch it" In some ways, I fear that the Sender proposal is a solution for the mailing list problem that throws out almost everything that DMARC added. Brandon
- [dmarc-ietf] Trying to understand DMARC in light … Brandon Long
- Re: [dmarc-ietf] Trying to understand DMARC in li… Brandon Long
- Re: [dmarc-ietf] Trying to understand DMARC in li… Dave Crocker