Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 01 May 2023 11:09 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 7E277C151B3C for <dmarc@ietfa.amsl.com>; Mon, 1 May 2023 04:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 72pGOM3qVXGJ for <dmarc@ietfa.amsl.com>; Mon, 1 May 2023 04:08:56 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 9F1DDC15257D for <dmarc@ietf.org>; Mon, 1 May 2023 04:08:14 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2a8bb726210so24305051fa.1 for <dmarc@ietf.org>; Mon, 01 May 2023 04:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682939292; x=1685531292; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=37qLbvixd2iKce6WAarY7fy26r5k6+yxrZVTsQRw+mw=; b=H58U9L9oE4wyUdw5jaO1h2gchv4Rbl4SfH2SK49t1ig1f7dc7EWm8Oq6hnBEskS59r HZGbHzpK7dBDT549i5WEjBgLxrmGltfvVQZFaFJ44rkldZ83S+SsVHPfyvHsMXWtEuHx eIKY6SDtxG0MH04j3B43VWLIrVyjsLE2c8EV+WetNGtJIedrDcGbIMnB3HUy6Sj03DuC WkNf5sE/ofaVr3fFXeiJXhvdsQAicapf+mspda8B7Esf/+VDNN+z4uTZI62S5baUgFDe obgqOvTsg5gZ/A7crQE9iX5dx53KL2o4Gvtf1ncSUrC/PK5miwlwLP7ybBGLVwCwIUPU wlwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682939292; x=1685531292; h=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=37qLbvixd2iKce6WAarY7fy26r5k6+yxrZVTsQRw+mw=; b=b10RtjJwgE3Fe61YvC7uMWKFlUOYpvY3Q7rMevNa8c3JePa0PyhVL0TS9qEbAUEJYO PrjBIKdXse0gQUZdOzYTQlKCuj+7jcbYmzymYtn5Vqr7RjzKDjPQ8CK6WrJ1siQsMXPj AmNRb0KWMbnITEel3aq0W3fe5eOX3BMlfS9Xx2/0rmqn8Biw+7T1RnU/fQF38xGL9xFD NgFVnbVtgjWgSYHFdeJKhSS1EpTrV/GVcNtxxE2U0NpSNigrcdzoz49kdQ7jiI72oUaq +2BWvf/Y5akCjHsmlvokBjNIVoPcEETlpB3oA1/LmXXSYBYAOjRwT7mmE8x72Zh1qxqh 1rLg==
X-Gm-Message-State: AC+VfDx6g+1ugH325C2xkENnY1WceBEhhFlZaSX+YRuHKxO9PRC+5fMz UMUH3/YvhetDbcdJUBqR0R1xC4K3ZVzK3ZzFA8qVhj/w
X-Google-Smtp-Source: ACHHUZ49ytyeTMMLU8CVciL0EGUEtuM6Nv0Wc1033MzgIr8gJs3xZFpo5r+tM9EklqnK2Q748tNeQqnZvh5moSvo1es=
X-Received: by 2002:a2e:2410:0:b0:2a9:f114:f166 with SMTP id k16-20020a2e2410000000b002a9f114f166mr3467647ljk.2.1682939292311; Mon, 01 May 2023 04:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <29216533.CRhL9lMF2B@localhost> <3141092.K83ThNGNZP@zini-1880> <CAH48ZfzS+MCC4-Dk3mZhF_bwc9hzWowApgPG3am14bjB9ZDz3Q@mail.gmail.com> <630A8A65-E04D-4C48-AE80-516F610EB93A@isdg.net> <CAH48ZfzmQJBb3xNSvVn84wpwf5SK2F0RSNQnSNObtxKfdHaY1w@mail.gmail.com> <B4E79EF6-E5F5-4969-824A-329576ECF20C@isdg.net> <CAH48ZfxaW5qO01HO-ESj4Sgy9gHM2rx8h_zA2-vHdS0s=yCcBg@mail.gmail.com> <CAFcYR_VBXmqT++8bS94Q1v9MPoHLXYn-0yCWy5U4FMj4gY6=XQ@mail.gmail.com> <8d9eda3e-6d72-ccbc-41ee-148a75698682@tana.it>
In-Reply-To: <8d9eda3e-6d72-ccbc-41ee-148a75698682@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 01 May 2023 07:08:01 -0400
Message-ID: <CAH48Zfw=aUh7aUpMX88knabMn=kh7JyR9d-DMkj-+kG7E9bZ8w@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b28a7205fa9fd6cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/3GNtGsp0aw1bYApwIkwp2kzm3Yc>
Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
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: Mon, 01 May 2023 11:09:00 -0000

Perhaps it should be the other way around.

Addressing the mailing list problem was part of the prior milestone, which
indicates its relative importance.   ARC got us past the milestone but does
not provide certainty for the list.operator.
Your concept provides a reliable solution starting from the receiving
participant and his domain.
ATSP for Users could provide a reliable solution framework starting from
the sending participant and his domain.

I don't think replacing the PSL has equal priority, and I think the
problems created by our redesign are being underestimated.

Doug Foster

On Mon, May 1, 2023 at 6:52 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Mon 01/May/2023 04:25:17 +0200 Emanuel Schorsch wrote:
> > I want to ask about the "hollow victory" aspect and what would turn it
> into a
> > more meaningful victory. If fromHeader rewriting is the damage we want
> to avoid
> > it seems there's two options:
> > 1) Have the mailingList make a decision based on what they know about
> the
> > evaluator. This would need some mechanism for evaluators to indicate
> what trust
> > techniques they accept.
>
>
> Can do better than that.  Have evaluators indicate under what conditions
> they
> accept whitelisting agreements.  If the MLM can meet such conditions they
> set
> up whitelisting, for a specific recipient, of messages signed by the
> mailing
> list, even if they break DMARC (see below).
>
> However, this cannot be part of DMARCbis.
>
>
> > 2) Have the mailingList rewrite the fromHeader but store the original
> > fromHeader and propagate the necessary trust information so that
> downstream
> > evaluators can undo the rewriting.
> >
> > Given that currently many mailingList do fromHeader rewriting it seems
> that #2
> > would allow gradual adoption and flexibility for experimentation over
> time to
> > see what trust methods work and allow downstream evaluators to make
> > personalized decisions depending on the recipients trust preferences.
>
>
> Been there, done that.  For the message I'm replying to, I have:
>
> Authentication-Results: wmail.tana.it;
>    spf=pass smtp.mailfrom=ietf.org;
>    dkim=pass reason="Original-From: transformed" header.d=google.com;
>    dkim=pass (whitelisted) header.d=ietf.org
>      header.b=jAsjjtsp (ietf1);
>    dkim=fail (signature verification failed, whitelisted) header.d=
> ietf.org
>      header.b=QuwLQGvz (ietf1)
>
> However, not all signatures can be verified.  Mailman tries and preserve
> most
> header fields, but not all.  For example, they rewrite MIME-Version: from
> scratch and don't save the old one.  So if a poster signs that field and
> writes
> it differently (e.g. with a comment) MLM transformation cannot be undone.
> https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform
>
>
> > What are your thoughts? What would be needed for that to result in a
> non-hollow
> > victory?
>
>
> I'll propose another draft, here or in the ART WG, more or less like so:
>
> * The mailing list sends a message to the subscriber domain requesting
> permission to send mailing list messages that may fail DMARC checks.
>
> * The message explains that list messages will be properly authenticated
> using
> ARC, but may fail DMARC alignment checks because they are being forwarded
> by
> the mailing list server.
>
> * The subscriber domain verifies the request with the subscriber and, if
> the
> subscriber agrees to receive mailing list messages, provides a DMARC
> override
> specific for the mailing list server's domain and the recipient.
>
> * The DMARC override allows mailing list messages to bypass DMARC checks
> and be
> delivered to the subscriber's inbox, so the mailing list won't rewrite
> From: in
> messages to that subscriber.
>
> Additionally, it may be helpful to provide regular reports or updates to
> the
> domain's IT team, detailing any issues or incidents related to the mailing
> list's email traffic. This can help establish a sense of trust and
> accountability between the mailing list operator and the domain, and
> demonstrate that the mailing list is actively monitoring and addressing
> any
> potential security concerns.
>
> That has to be discussed, but not in the DMARCbis context, otherwise
> someone
> will say it's mission creeping, someone else will escalate it to mission
> gallop, an they'd be somewhat right that such discussion delays DMARCbis
> publication.  IOW, let's proceed step by step.
>
>
> Best
> Ale
> --
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>