Re: [dmarc-ietf] Signaling MLMs

Barry Leiba <barryleiba@computer.org> Thu, 13 April 2023 15:14 UTC

Return-Path: <barryleiba@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 EBC69C151B0D for <dmarc@ietfa.amsl.com>; Thu, 13 Apr 2023 08:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level:
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qgUVGiwFCckb for <dmarc@ietfa.amsl.com>; Thu, 13 Apr 2023 08:14:52 -0700 (PDT)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 07D1AC14CE3B for <dmarc@ietf.org>; Thu, 13 Apr 2023 08:14:52 -0700 (PDT)
Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-94a9bbfe3ecso274561866b.0 for <dmarc@ietf.org>; Thu, 13 Apr 2023 08:14:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681398890; x=1683990890; 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=bjeicfn82O4DCgXw0KRGzSd8ijVnHtOy3+GVRjWZlEc=; b=FeW9wbH9H6agXRxKW49/9NMNq6meGHMggUC5FgLIkCPzMUOwtbPsN3O0IyvovNFpyH CcfGr1HtNt1DcEk6RCftzBHIYZaiyvm20FKT1lSXLX7anu1qnPBTjwX0kDWZ5Urwl9J/ MrfcHVbeYpTYMVE9cieIuCRgTc47zkQ2Fod2bkWNSbBtrtcbaVAq0YIKDbFqh8qQIm5S pwFy4tOQ2KYuzZBZ87OxcWg9yXFrX4RVFoYukN7Nuzjw+SfWG9RGBDj9nWyXUvb1gWt6 cQXLSgKnJHo7VufIPvsvi26qyWuXhR95k5tFvV842F8GEFzqoeVO/nzxoWirVSZWI2E1 oQXg==
X-Gm-Message-State: AAQBX9fNIHUENLp6Str3LL6oNNOSn4xP2+OLrnpIDwj+2t95vHl8D5ra zizC7pMhRMAkOqqdqKITtLWihae9L0UbFLm1qiLp/Fo5xtk=
X-Google-Smtp-Source: AKy350Z0pxo4rViqVv3aAezMdsKC+ugOTiiNvpNp7vkMPqN0362i1Ddn9Tw/m0nBEtrKs5B0QAZfsbo8bomzQPFA9/U=
X-Received: by 2002:a50:d0cb:0:b0:504:a1a7:6916 with SMTP id g11-20020a50d0cb000000b00504a1a76916mr1459487edf.0.1681398890059; Thu, 13 Apr 2023 08:14:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
In-Reply-To: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 13 Apr 2023 11:14:38 -0400
Message-ID: <CALaySJKcf5=c_5rTiZUdRmUqsuAm0P-TykN+dew74uURRKn-5w@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/k8MypicXThjawheJCXH5jyP4HIY>
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: Thu, 13 Apr 2023 15:14:53 -0000

> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that
> MLMs can take advantage of indicating to them that the author is using
> a strong policy, and so it would be possibly a bad idea for the MLM to
> accept, mutate, and re-send this message.  This could be a header
> field or an SMTP extension (though the latter is complex to get right
> in a store-and-forward system).  The MLM can then decide if it is
> willing to pass the message unmodified to the list, or reject it with
> an error like "The policies of this list require modification of your
> message, which violates your domain's apparent policy.  Your
> submission therefore cannot be accepted.  Please contact your support
> organization for further assistance."  There's never an opportunity
> for the collateral bounce to occur if the message is never
> distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.

There's no need for a signal here: the MLM can simply check the
sending domain's DMARC policy when a new post comes in, and
preemptively reject it if the policy is "reject".  The IETF considered
doing that and ruled it out because it would mean that users with
yahoo.com addresses (and others) could then not participate in IETF
mailing lists without changing addresses.  I think that was the wrong
decision, but we decided on the ugly "from" alteration instead.

I still think that outright refusal of posts from p=reject domains is
a good approach and I wish it were used more, but most MLMs that are
willing to put in a change to address this seems to prefer not to
punish the sending domains users for the excesses of the domain
management.

Barry