From nobody Fri Jun 9 16:26:44 2023 Return-Path: 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 613D4C152F3D for ; Fri, 9 Jun 2023 16:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.596 X-Spam-Level: X-Spam-Status: No, score=-17.596 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 PthKXzZS4GGB for ; Fri, 9 Jun 2023 16:26:39 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 98D50C1516EB for ; Fri, 9 Jun 2023 16:26:39 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-3f7fefb1274so65e9.1 for ; Fri, 09 Jun 2023 16:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686353197; x=1688945197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dywwJdnMhDhvu9Lv90MnBIgM9jOfS26uwlYLrN7TfRc=; b=U/tRCZMOSfZw0kgcJj4EThDf2LGPYtiGkLVWVVMfdLvCJF4ViZC8uaY2SziuCvRaTx l7MdFE1SKMwcEHXsQM4V/WlUleGWL/q5aNQT2YFjRIReBdWaPY1bW2+OJNfqEqlN906l L3a59wFiIxiplMEq+1yj8IBNM6DWmzVorQa7gPh0xih/8n40h3T+JsCiq6q4bdrufs46 Nr9EGxxlAMLXGeA0aj23dfaLeXw2zgavqF+g8rfs1qXSJSfCaTB1LVFlS1iVMuUUWOA4 I/wM+dzjC/UAYRjjf9MzZdPWc6bLfCItpRYQVP+hmximmwIR0FW877NLw7Zubo5ED8UG 0ACQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686353197; x=1688945197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dywwJdnMhDhvu9Lv90MnBIgM9jOfS26uwlYLrN7TfRc=; b=koY2Yxs1135Zv2cVpBicZIAjS/05rPwHuKxvDJ2C8WIwrnEAK3bDblR67L+5h+bFAJ ph11pn3DOSEFgog7rKi14+A5MeKro1gv8qTmQeyRCEWz+13hJ8GdKgRDsU3RsbBZe+lz pxR7mH+HnU5lXCkFfboNyyb2Pj6fHU7wiRIyJXHNEDDGmwdvX6eNGLKycI+hPs4jPyiR yXh/2DxIO7elG3JkSgfcTCT7DktTzmZOApd75TKlYYzEbSyvtoHz8jLJLNqy3AUPA+Ee V+btCo2ZclBqMVBzCs6l2tqZqJDKTKv4aTOySY0XJiLBgdzIL3UjjVY56YWQ26qrGY2Z +u2w== X-Gm-Message-State: AC+VfDy1RP3DITSvrnwfpVubnj8zky4mkBxbExcr55LIgXvjd+U7fX0/ Mcnqu1BMVPzsk3hzGtRmDGm54unjOo6eALBIs4Q+PQ== X-Google-Smtp-Source: ACHHUZ6nl71SizLl+CxPNIlsrq5kcRXqmtO7fvIF5nRtB7vjiNuKobJsASUhNClXD4wS2sdlZapSmEHJrkSDPODPKIQ= X-Received: by 2002:a05:600c:82c9:b0:3f5:d927:794e with SMTP id eo9-20020a05600c82c900b003f5d927794emr2577wmb.0.1686353197114; Fri, 09 Jun 2023 16:26:37 -0700 (PDT) MIME-Version: 1.0 References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <20230608162112.5903CE7035F3@ary.local> In-Reply-To: <20230608162112.5903CE7035F3@ary.local> From: Emil Gustafsson Date: Fri, 9 Jun 2023 17:26:18 -0600 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000488b4b05fdbab34a" Archived-At: Subject: Re: [dmarc-ietf] version bump to DMARC2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2023 23:26:43 -0000 --000000000000488b4b05fdbab34a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not sure if I am that someone mentioned. In case I am - I'd like to clarify what I meant; Without a version change for the tree-walk, I think we (Google) would need to support both approaches (the old one plus the tree-walk) and based on what we see - make a best guess which version we should use. Having two explicit versions still means we have two implementations, but at least we don't have to guess which one to use whenever there would be ambiguity with a single version. I'm always concerned about what bad people do to gain an advantage. But in this case I'm more worried about somebody having an ambiguous DMARC setup where VLMPs end up guessing the wrong intention. The most likely outcome there would be rejected emails and an upset sender the VLMP need to deal with. But atleast they are not spoofed. I think explicit versioning helps mitigate that risk too (but it wont help companies making bad configurations - but that we always have to live with). /E On Thu, Jun 8, 2023 at 10:21=E2=80=AFAM John Levine wrote= : > It appears that Tobias Herkula said: > >However, such a fundamental shift in the protocol's architecture warrant= s > a clear signifier. I suggest we upgrade > >our DMARC version string from the current state to 'DMARC2.' This upgrad= e > would not only denote the change of SPF > >removal, but also the switch from the Public Suffix List (PSL) to the > Tree-Walk algorithm. > > I was talking with someone from a Very Large Mail Provider who told me th= at > if we keep the same version number, they won't change what they do now, s= o > no tree walk even if we keep SPF. > > They understand that as things stand now, the results of the PSL and > the tree walk are in practice the same. Their concern is that if some > people do it the old way and some the new, and you can't tell which > the domain expects, bad guys will create records with deliberately > inconsistent results. > > I'm not sure how likely that is, but arguing with a gorilla rarely > turns out well. I will see if I can talk to people at other VLMPs > and see how widespread this concern is. > > R's, > John > > PS: If we do bump the version number, it needs to go into the > aggregate reports, too. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000488b4b05fdbab34a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure if I am that someone mentioned. In case I am - I&= #39;d like to clarify what I meant;

Without a version change f= or the tree-walk, I think we (Google) would need to support both approaches= (the old one plus the tree-walk) and based on what we see - make a best gu= ess which version we should use.
Having two explicit versions still mean= s we have two implementations, but at least we don't have to guess whic= h one to use whenever there would be ambiguity with a single version.
I'm always concerned about what bad people do to gain an advantage. B= ut in this case I'm more worried about somebody having an ambiguous=C2= =A0DMARC setup where VLMPs end up guessing the wrong intention. The most li= kely outcome there would be rejected emails and an upset sender the VLMP ne= ed to deal with. But atleast they are not spoofed. I think explicit version= ing helps mitigate that risk too (but it wont help companies making bad=C2= =A0configurations - but that we always have to live with).

/E

On Thu, Jun 8, 2023 at 10:21=E2=80=AFAM John Levine = <johnl@taugh.com> wrote:
It appears that Tobia= s Herkula=C2=A0 <tobias.herkula@1und1.de> said:
>However, such a fundamental shift in the protocol's architecture wa= rrants a clear signifier. I suggest we upgrade
>our DMARC version string from the current state to 'DMARC2.' Th= is upgrade would not only denote the change of SPF
>removal, but also the switch from the Public Suffix List (PSL) to the T= ree-Walk algorithm.

I was talking with someone from a Very Large Mail Provider who told me that=
if we keep the same version number, they won't change what they do now,= so
no tree walk even if we keep SPF.

They understand that as things stand now, the results of the PSL and
the tree walk are in practice the same. Their concern is that if some
people do it the old way and some the new, and you can't tell which
the domain expects, bad guys will create records with deliberately
inconsistent results.

I'm not sure how likely that is, but arguing with a gorilla rarely
turns out well.=C2=A0 I will see if I can talk to people at other VLMPs
and see how widespread this concern is.

R's,
John

PS: If we do bump the version number, it needs to go into the
aggregate reports, too.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000488b4b05fdbab34a--