Re: [dmarc-ietf] Signaling MLMs

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 14 April 2023 19:20 UTC

Return-Path: <superuser@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 D4E9CC151B09 for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 12:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 StMmM7ZPboxv for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 12:20:34 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 5B720C14CE47 for <dmarc@ietf.org>; Fri, 14 Apr 2023 12:20:34 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-50671ef0c48so97609a12.1 for <dmarc@ietf.org>; Fri, 14 Apr 2023 12:20:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681500032; x=1684092032; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P5bJq7c22rxDmn80MoUEUZvWulAfhWJeKfFq0ySUgqs=; b=LCO8V5qeAQ5QTiXrOzIN6IUek/QVMzUZN8QSB/0Xt1JVVMSaikpxoIR/gbGcMN1WGA ZC0Bm6479IZTxn3OqIikSrbPA+jRrc1bWgW0YOWbtYpEa2EyyUwuJhZnRNEuPLB0Om33 3Hvl7k074HfJELSw/SADDb1yp1u3YfVjylnAQaytXQWN9KNj1dNGSdHRg72OUroDQnrf VH92ZQepkQR6Xgj6yPGnAY7lHR1qk8gdV5HWEGm+aQr9SVs7U1ULf9/6Tn9IwoyKSej2 hDQVw23iMYV/MyKm6+x2YSFVoi77LtU2HregGKFxetY+Sn2e6n8yps3el1eETTL0Le8W sDtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681500032; x=1684092032; 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=P5bJq7c22rxDmn80MoUEUZvWulAfhWJeKfFq0ySUgqs=; b=VfIaAVWz1otKNg0wlSfcVHEW/AfgoaFD027fTcNfFVyhXTwZn89YI1414Zus53VLiE Rxc0BZ1YQZ75p1h/MPu37Dil7nAE2wyK/8JRVkb83DAuz8GPNv58Od70fVm0bxLaX6+v lmDxGzwgMTjG3n9k5O1BknV22TUUK6mcKM62G0FR9mSRsNpBZaoVvaTB/fTuWegSicZL 7tgcjXIaCvwZHPeI/WyV79GKgyikw2rm4wASHEbR2gZEPUbBADi35LGp0KMN/U4nzlKv leHTZGYI6A2wc4q99H4YYIOszQhZYKcX1bhG7lNyQ2JcpOGkV6fJhlGR2b8gXESmD/Ev RLBA==
X-Gm-Message-State: AAQBX9eTMdTIuebP45p9ias0w8Kp7a3qez7k4OUIuGfxr0wC2mIRuMvO CVXh79flkqT9p7ac4gdZkaCmEA1PvwwoIJqYV9IKgUOC
X-Google-Smtp-Source: AKy350ZXmMINgpLmeJDxmRr2ehN9pJubL4v2PXyCifuK7dECHvQXuuP0ZzWZzSDm0N64/dlnqhffvhwoV6pic+F7aAU=
X-Received: by 2002:a17:906:535a:b0:94e:9235:d77d with SMTP id j26-20020a170906535a00b0094e9235d77dmr827566ejo.0.1681500031655; Fri, 14 Apr 2023 12:20:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com> <8d970e6b-8fa7-da85-5c47-d485abbc43be@crash.com> <CAL0qLwZJjBq0T8kODJifTT10ttJJE2Bof5kJZACRTwyauzwQ6A@mail.gmail.com> <CAJ4XoYcHeFe0kS9QHz4fP5TbOMOiW8mJaiNYx+Yk8keZYW-yDQ@mail.gmail.com> <b6a2b444-de02-9833-fe7b-fc9ad542f900@tana.it> <CAL0qLwYwcXTBzqd=3sKwtZJUsEYO5kfv9V-CZtVHz2TQ78v=0g@mail.gmail.com> <909C826B-2745-4BE8-AD16-920E6DE86D1C@kitterman.com> <329db752-fdeb-7633-ede1-06e435db1c0e@tana.it>
In-Reply-To: <329db752-fdeb-7633-ede1-06e435db1c0e@tana.it>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 14 Apr 2023 12:20:19 -0700
Message-ID: <CAL0qLwa=cA7426zgNJQFDBBqOKA6KXyBGAE4TOy=C+c9+JUY3A@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000013a54405f950bc0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/uLCs35h2ZkPEuX4r2zhNqfv20XM>
Subject: Re: [dmarc-ietf] Signaling MLMs
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: Fri, 14 Apr 2023 19:20:38 -0000

On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superuser@gmail.com> wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <vesely@tana.it>
> wrote:
> >>
> >>> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >>
> >> That's not enough to avoid the damage we're talking about.
>
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
>

Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection
of messages merely because they fail authentication on ingress.  They both
acknowledge that there are perfectly legitimate mail flows where that can
happen.  Since DMARC is built on those foundations, I think your assertion
strains reason.  That is, it's weird to say "If you observe DKIM and SPF,
don't reject; but if you observe DMARC, do."

>>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
>
> I agree there are better solutions, but they're not yet developed.  As
> ugly as
> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat
> again that the IETF standardized facts, not theories...
>

Let's put the challenge back on you: Where's your evidence that From
munging is the emerged consensus solution that this working group should
standardize?  Where is this _fact_?  If we advance that as a Proposed
Standard, the community will quite reasonably ask why we think this is
true, and we're going to need to be able to answer them.  If working group
consensus agrees, then away we go.

Laura, I believe, enumerated a few reasons why it doesn't work all that
well.  We'll need to explain why that's all fine.


> >> What you describe as "cannibalizing" is actually a matter of presenting
> the
> >> correct normative advice about interoperability.
>
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports.
> If that's really what we think, we'd be better off deprecating p=
> completely.
> Otherwise, let's wait until next April 1st and publish it as such.  It's
> ridiculous.
>

I think that's rather hyperbolic, but ignoring that for the moment, there
is some validity to the idea that the reports part of DMARC is the only
part of DMARC that does not disrupt interoperability.

>>  So I don't agree at all with that characterization.
> >
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically
> accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
>
> I agree that we have to say that some domains have interoperability
> problems as
> a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless
> (or
> until) better solutions arise, or unless they don't alter messages.
>
> We're proposing email authentication, not anything less.
>

Sure, but that proposal is -- clearly by now -- fraught with disruption.
We can't ignore it because it's inconvenient to DMARC's goal.

This is the first time I've ever heard someone push the idea that From
munging deserves Proposed Standard status.  I'd be happy to hear what
others think.  If that's actually a sleeper consensus of some kind, then
out with it.

-MSK, participating