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

Brandon Long <blong@google.com> Tue, 08 December 2020 01:36 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 B937A3A0BF3 for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 17:36:57 -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 95XrrVRqAar2 for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 17:36:55 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 497793A0B17 for <dmarc@ietf.org>; Mon, 7 Dec 2020 17:36:55 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id y26so5155442uan.5 for <dmarc@ietf.org>; Mon, 07 Dec 2020 17:36:55 -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=2OeVn86l6Dbnky0RlhLQVsYMRzVWFmnfs9bqmyRxLF0=; b=r/lataonwFaqbpkJ3RQwHKAdCWvRnKeMrS//uSH9dc9wNyLQuWP/cY3Qt7UwgLV8wS YZvu9Gz8n92d81pySmecgyv+b4SEg1HfLWqkgC7CqXKHT5i30Qt+eCO7jClVCitO9oW6 VWlwJhe8Ns8xSa1XOgw0FVx0FGr+vOCNti3yd2qODAnMl/b9FzJx45f6fnQiHm+L1utC OLV/+EHu8e2uEgqPf8GbgMloab1tYRGAd7vH75A+9pDsTH9LiEWrYDqj45U7Gnn9f2li QTNcSgKUWIw+oDPlShvc/YFTdmGXRjuVrM+KLWG5VuzSAUmtRHbp2HFmUo1kMDczpt9k xrLQ==
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=2OeVn86l6Dbnky0RlhLQVsYMRzVWFmnfs9bqmyRxLF0=; b=nYdeoaqrHpSkj7wlC+Lsn20UD5oNGglO+WrugraWWMepkah7HJ5VsJS8J8HBUK+q1o frzvpmlZytpHK8NGIahc39TFJ/wDhTC9rT6CclA0qHdoZ85LTV9yLJih+KTpnwFsvHp7 aRCZxMN/9YqzvH9dBV6ML28CkBLYvhT938TX3roBrjiDF8uDMoekAR4PPNCc6P7flBus 51O56UfbyIBMAXvp+BTU4LZtz7FS0xazYXgaz3FsquPv0/HL4AXCCiVtVyQeRM+1unLA O16DtUNXMY6Rt0gqx7CWIweqff9/IdQyrqoNQZJxXZcoaZHFMclZwOIv4emFic7cbI5i l/4A==
X-Gm-Message-State: AOAM532vzAdgaB+yqpCMuTKIAB26zqW/HFEpJIfRBkminqetjl5hyU5j +HDleoTdGYutoX7AmEvYAE1OyBnBoLEK7yIAgi3ICLPfx06v
X-Google-Smtp-Source: ABdhPJzWKE1frCDahmZpi+hctN9b7czPawkS0CSm9sAshj2qggVkBVQjnCyIa8DHvVkHl6lZmlNyYzChNvOQiJdR+4I=
X-Received: by 2002:ab0:55da:: with SMTP id w26mr12065099uaa.31.1607391414093; Mon, 07 Dec 2020 17:36:54 -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> <CABa8R6spYyZDhzEnQ=txdoLOO1Ek1MAryW6ioAsur1_mEvdXkA@mail.gmail.com> <dff10989-b2cd-8cbd-f465-46796028d320@tana.it>
In-Reply-To: <dff10989-b2cd-8cbd-f465-46796028d320@tana.it>
From: Brandon Long <blong@google.com>
Date: Mon, 7 Dec 2020 17:36:41 -0800
Message-ID: <CABa8R6uY87DRnUT+fwoT-Tf3H6EzPkp7r5oVtQCWi-oeGJELfA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041271105b5e9fa7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/aZKGWgoAz8lbLspQhJ_5MKkQslI>
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: Tue, 08 Dec 2020 01:36:58 -0000

On Sat, Dec 5, 2020 at 5:20 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote:
> > 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.
>
> I'm not familiar with that feature.  How does a list get subscribed to
> another
> list?
>

Either by direct add via the groups interface, via carefully
crafted +subscribe emails,
or via our directory API:
https://developers.google.com/admin-sdk/directory/v1/guides/manage-group-members

The consumer version of groups tries to not let other groups subscribe by
looking at the
subscribing domain, but the workspace version doesn't care.


> In general, a list accepts messages from subscribed users, so if
> dmarc-ietf
> distributed this message to another list which I'm not a subscriber of, it
> would not pass.  (From: rewriting changes that behavior.  For example, one
> could subscribe to a list which routinely rewrites From: on behalf of this
> list, dmarc-ietf.  If the former list traffic is very high, that
> subscribing
> could be a sort of DoS attack to us.)
>

Yes, having lists subscribed to lists creates all sorts of complications.


> > (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)
>
> The mlm-transform draft (referenced above) limits footers to 10 lines of
> text,
> each shorter than 80 characters.  If the hierarchy is not deeper than 10,
> the
> chart can fit within a single footer.  Note that every added line breaks
> all
> previous signatures.  However, only the author domain's signature is worth
> being recovered, as far as MLM transformations are concerned.  ARC can
> still
> certify the whole chain.
>
> The 10 lines limit is arbitrary.  It is meant to avoid that recipients
> mistake
> the footer for the main part of the message.
>
>
> > (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?)
>
> I guess some coordination among sublists is required anyway.
>

Note that sub-lists may not be from the same list manager, ie one could
subscribe alias type lists to lists at other domains.


> To recognize that a message arrives from a sublist, and hence mangle the
> existing footer instead of adding a new one, is certainly an added
> complexity.
>   Maybe, the number of lists in such condition is low enough to let MLM
> transformation reversion still worth being deployed?


I think something like mlm-transform is not a 100% solution, though how
useful would
depend on whether it's a 50% or 99% solution.  Frankly, I think some of the
other restrictions
might eliminate more email, but we'd have to look at the numbers.

Brandon