Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

Brandon Long <blong@google.com> Fri, 04 December 2020 22:46 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 32BCB3A0FF3 for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 14:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, URIBL_BLOCKED=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 xGBr_iygkgoM for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 14:46:01 -0800 (PST)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 37F8F3A0FF0 for <dmarc@ietf.org>; Fri, 4 Dec 2020 14:46:01 -0800 (PST)
Received: by mail-ua1-x92f.google.com with SMTP id t15so2399658ual.6 for <dmarc@ietf.org>; Fri, 04 Dec 2020 14:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pPE3lszSgH4HavNbe1MMQlb8qKJYi+RJ0EId68pRjjU=; b=Rl1KVdp8DdnRcgy9+BF/0g0hIrim4Ywv8LFrn69Q/Kr58IfCgmE7kSMAytyk4sZ5fq hVFZh8av5BFFBUjuSad9CGYM+i1C50lPe0I+XqX5NdsZX9VTn4RsOfE0krmWTjGLxDT/ 8shGH18OsyUcSxoviDlI4sqPlN9hYvhFcxsC+GFpWveCviqiGZtsUWwMWZGYhI2Rfzaz 6M1srSoF3ztDl6CduKXdYxXQYl4BiaitlPqUwwntk5prUYGREJ9pVs2oJbLkNEmE9Z/T Yz8wYvfkq2dYHCAU23/f4ekgzmWurW8I1RbAc//1A8CiEaA5Z1qhbfUtOScWviNczWqY FMdQ==
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=pPE3lszSgH4HavNbe1MMQlb8qKJYi+RJ0EId68pRjjU=; b=R1shUVFpyTxr5e3FNxGmx4sMZpgtpojSKLbKDV8ik2UcKF+HNNJ3fRUbiH3vbgsIGj YjAmtnVfXOPJeNgMScV890+D0y1drmE5DWZ8PpuZfE0lsgwTEwVn16Iae7chQFdKDzfY bTbAo+32/n5AEqAcOvXEwE0wn/l6xcSxis5Kp88jEGDtyBqs0wWpXwkcr7mrfPOfTQ/L x90q5OD0nhC9rJpruqYoLNOBHMOfY6jCA7iZM/8yovMM9J7sKEryHERPE25jZmux/Zfx qGA8KvvnzaHBQ8/eaC1q1zIwVdK198V2r9Z/DiVyViM4DLSx5bbrgEUQ9L9LV2qR3So7 magA==
X-Gm-Message-State: AOAM530MTjOztPZy/EpOkfE4+7xRDQOMQBscBbvr5/w8K3rLRcc7noDz 3soGEiCazEYuMFwPaScWK6v9W486xPKvdiAff2+aFNYdtw==
X-Google-Smtp-Source: ABdhPJyZ1OB9WxI3CSKE+xCwxM2n7P+KG3+g8aDhr60RmBFgVtzZs+rMkWylL15NOB6JklD8bLipuYfxK6b1rBK3ihU=
X-Received: by 2002:ab0:2c05:: with SMTP id l5mr6012044uar.40.1607121959899; Fri, 04 Dec 2020 14:45:59 -0800 (PST)
MIME-Version: 1.0
References: <e9166148b9564102a652b4764b4f61ff@com> <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <b0f72407-81ce-9990-4a5b-7b0e5b76e3d7@mtcc.com> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <CABa8R6sV0x8wWmggp98JfXz8jh0GfAmZ+tNkvqnMPnVK534uPQ@mail.gmail.com> <e54e9ff4-59ae-a2ac-7ae9-a8036528a24f@tana.it> <CABa8R6us3cKfYa=tmkiZho087BfLH=Ga92JYxMiHW0Zb4btm8g@mail.gmail.com> <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it>
In-Reply-To: <01d1849f-6a0a-5307-db54-7587e33fc018@tana.it>
From: Brandon Long <blong@google.com>
Date: Fri, 4 Dec 2020 14:45:47 -0800
Message-ID: <CABa8R6spYyZDhzEnQ=txdoLOO1Ek1MAryW6ioAsur1_mEvdXkA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088413405b5ab3d34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MoefmFtEJsM8_VU37K7TLpanc10>
Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions
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: Fri, 04 Dec 2020 22:46:03 -0000

On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:
> > On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely <vesely@tana.it> wrote:
> >> On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:
> >>> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it>
> wrote:
> >>>> On 25/11/2020 20:16, Michael Thomas wrote:
> >>>>> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
> >>>>>> On 25/11/2020 19:24, Jesse Thompson wrote:
> >>>>>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
> >>>>>>>> Without resorting to ARC, it is still possible to validate author
> >>>>>>>> domain's signatures directly if the MLM just adds a subject tag
> >>>>>>>> and a footer>>>>>
> >>>>>>> I agree that ARC isn't really needed to do this (trust the last hop
> >>>>>>> from the MLM and determine the original authenticity from the MLM's
> >>>>>>> perspective)>>>>
> >>>>>> I didn't mean to trust the MLM.  I meant remove the subject tag and
> >>>>>> the footer, then the original DKIM signature verifies.  See:
> >>>>>> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
> >>>>>
> >>>>> When I was at Cisco, with l= and some subject line heuristics I
> could get
> >>>>> probably like 90+% verification rate across the entire company, a
> company that
> >>>>> uses external mailing lists a lot. Definitely not 100% though.
> >>>>
> >>>>
> >>>> DKIM itself is not 100%.  You always have lines beginning with "From
> " or
> >>>> occasional autoconversions.
> >>>>
> >>>> l= doesn't cover multipart/alternative nor Content-Transfer-Encoding:
> >>>> base64. In addition, the DKIM spec discourages its usage and suggests
> >>>> that "Assessors might wish to ignore signatures that use the tag.">>
> >>>
> >>> Right, some of the other dkim-light or diff concepts we discussed
> would be
> >>> better than using l=
> >>>
> >>> We again got hung up on the 100% solution, though... something that
> handled
> >>> subject-prefix and footer in a transport agnostic way might have
> worked.
> >>
> >> I'm not clear about the meaning of "100%".  If an author domain puts no
> >> DKIM signatures, there is no way to verify them.  Hence, some
> compliance of
> >> the author domain has to be required.
> >>
> >> The same holds for conditional signatures.
> >>
> >> The same holds for MLM transformations.
> >>
> >
> > Yes, by 100% I meant of messages that were already authenticated and
> > therefore should continue to be authenticated through the relay.
>
> That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's no
> way
> it can continue to be authenticated through a relay.
>
> OTOH, mailing lists and relays are two different beasts.  For one thing,
> it is
> very unusual for a mailing list to send to another mailing list.  Thus, we
> can
> safely specify a non-stackable authentication method.
>

mailing list to mailing list mail is very common in GSuite, but maybe we're
a special
case.  Part of that was that aliases were moved to the mailing list infra
(which is definitely
more of an "our problem" than everyone), but we also see common usage where
companies make groups matching their hierarchy (the all company group goes
to
all department groups which go to all local groups etc).  We also see some
where
announce groups mix contrib groups, etc.  Especially since we also use the
same
groups as ACL groups for GSuite and Google Cloud, so hierarchical groups
are very
common.

(there was a recent common where someone said who needs an org chart when we
have email, showing the list of footers for all of the org level mailing
lists the message
went to to get to them)

(one construction of hierarchical announce lists that was not well
considered did result
in every person on the combined list getting 9000 copies of messages to the
list, so
flattening lists is sometimes much preferred)

Which isn't to say we couldn't work around it or do the work to flatten the
lists, though
it increases the complexity of the product (can you unsubscribe from the
top level list
but not a sub list?)

Brandon