[dmarc-ietf] Some Gmail comments on DMARCbis version 28

Wei Chuang <weihaw@google.com> Thu, 07 September 2023 16:29 UTC

Return-Path: <weihaw@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 1DB7AC14CF0C for <dmarc@ietfa.amsl.com>; Thu, 7 Sep 2023 09:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.597
X-Spam-Level:
X-Spam-Status: No, score=-22.597 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dme4JlDX50Fy for <dmarc@ietfa.amsl.com>; Thu, 7 Sep 2023 09:29:24 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C143C15DD6A for <dmarc@ietf.org>; Thu, 7 Sep 2023 09:29:24 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-414decfb83aso01cf.0 for <dmarc@ietf.org>; Thu, 07 Sep 2023 09:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694104163; x=1694708963; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=vBryaZzXhHDOlatUaPegBaoX6UocLSrTGs7oWUzLHQY=; b=uc3W0dg5ANl3/lV8K/HlzsvW/2yzRsjGnU/7HFBqKUkdfuSAjG+P77RSWzyHoN8ofo QHFtkBWGkL529ZKubva13ImZQBXKRHwrgnNHZjMc4j0+APrc3i3Any3d0ijpCOfe3+0k yasF14yAsBHrfntjWu9EP4QklQPYkyKmjx3s/UBN/M99/0OdtdiYHTDItbY2gmmiJRfA yFv2DiJSO+Ns5IZdHIJKuJ3aYfYevcqn9Hcms4VSL0PHsrSImH6S3zTcJHjX+DQDioOY cxiYwMu5BGHM64rbjkccO79NOi2o7CtOC6FDRsLgQWM61H4UpEVrqsLz2/bHNDCZSIrX 45tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694104163; x=1694708963; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vBryaZzXhHDOlatUaPegBaoX6UocLSrTGs7oWUzLHQY=; b=SGXcdPBTsoum5AvBhr7irpAM8BCzOyEsYt2EjduA4Sc6m51lDVEDMmuxLzAwInXtB2 BUzttAZShQIbmwWiXEhNH22ToG6cIf5G+nByUeWrjgW+B1AajUk9nc8BfVcMOdl1+EEH ScxcF/+t0/wMXVimqz8vL/dQr638/w7bpNO9zm2afGoG1/OUI2x2qdlVCMS66dZSdZJO VDg3P0Sm5PmjUUzOsN3CMzPAnsqKxq++pJkRpuVYDqaE42BKT9pYW+8pXnN+XnQhkrab xv5Gl0JyVowsqnchGfh/AJ+WDLHtUuNHYkXAB5Ifqdf02jN6PzvpBCdrjdsJVy6JouSn TA1A==
X-Gm-Message-State: AOJu0YzqP0V0rU0ylKGS/OYZUm4GcbIOiXF/8VzJRSN1IZcEw3FfY3k3 rFGbZvOvllkDt0rn3wbPNgKbtvtF6AH1kiQ4BnGsh0wntbhXJM3Nq9QI/Q==
X-Google-Smtp-Source: AGHT+IGMc5qpet5aT2Ux4rtXyoMiwFfNoJ9JY2fyY5mHvCmkmYC56pWR5jtyvprcTaVwK/eBW3YEeCCa8Nxjx20laLg=
X-Received: by 2002:ac8:47c6:0:b0:410:c04:b479 with SMTP id d6-20020ac847c6000000b004100c04b479mr3613qtr.2.1694104162081; Thu, 07 Sep 2023 09:29:22 -0700 (PDT)
MIME-Version: 1.0
From: Wei Chuang <weihaw@google.com>
Date: Thu, 07 Sep 2023 09:28:59 -0700
Message-ID: <CAAFsWK1xtj0zCEG-77Ar8G83_F2uQpJPOA5SKzci7T5BHTnNWg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cbabf30604c75cb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mLL-kErnhwJ3-Aq7QoV44xQNEBc>
Subject: [dmarc-ietf] Some Gmail comments on DMARCbis version 28
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 07 Sep 2023 16:29:25 -0000

We had an opportunity to further review the DMARCbis changes more broadly
within Gmail.  While we don't see any blockers in the language in DMARCbis
version 28
<https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28> and
can live with what is there, we wanted to briefly raise some concerns
around some of the changes.  Two points.

Regarding the languages in section 8.6 "It is therefore critical that
domains that host users who might post messages to mailing lists SHOULD NOT
publish p=reject.  Domains that choose to publish p=reject SHOULD implement
policies that their users not post to Internet mailing lists", we wanted to
point out that this is impossible to implement.  Many enterprises already
have "p=reject" policies.  Presumably those domains were subject to some
sort of spoofing which is why they went to such a strict policy.  It would
be unreasonable to tell them to stop posting to mailing lists as many
likely already use mailing list services and will want to continue to use
them.  The one thing that makes this tractable is the SHOULD language as we
may choose not to not follow this aspect of the specification.  Our
suggestion is that there is not a lot of value in including this language
in the bis document if the likely outcome is that it will be ignored, and
rather more effort should be placed with a technical solution for interop
with mailing lists.

We question the benefit versus the implementation effort and confusion of
deprecating the DMARC policy "pct" percentage mode and replacing it with
"t" test.  We do agree that there is benefit in having receivers support a
debug mode to enable DMARC deployment and that the test mode supports the
most useful use case for testing with indirect mailflow behavior.   However
"pct" represents a sunk cost and implementing test mode seems redundant to
the already existing "pct" percentage mode.  Moreover both modes will
likely need to be supported for a while.  We do see senders use "pct"
ratcheting and it will be confusing to them when at some point they will
have to switch.


-Wei