Re: [dmarc-ietf] Signaling MLMs

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 12 April 2023 19:02 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 97B54C151531 for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 12:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, 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 Bqwnu3krAAWX for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 12:02:26 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 71730C152A0D for <dmarc@ietf.org>; Wed, 12 Apr 2023 12:01:10 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id bx15so11049144ljb.7 for <dmarc@ietf.org>; Wed, 12 Apr 2023 12:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681326069; x=1683918069; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Db/OUHuiBKZEmOD0NamgtzWRyjc7jAhYxo5VMnnejuI=; b=FqIuGP5TDXGrUZReHf52fcNJS8l0B/0XYR95aZLZIKv9P8JBfM+O9re2zfYLw7sZc1 6jHk7ZNHmMIrYyaJhZNbHFVliuITLy5mGrO9l1ndEdAvMjh3x/UpZMXZo5OX+YrH2AT3 B8pF2khj3/4B2MUczHAv6PQwNqkyk+2rcdaqdXGRXcpvo0G5GjdBRWgPx6VEJu5cqBM1 14NGl4zSXd78mX7rniBuHxH6whQ2twH9Bz6K/IaQNIHsmciihYxMSwCt7oRDWZW0/p/O yBoRMw/LN/xo+T7W5PMVR7iznCtf59HdT0tX57j03v6ww1NSxoy0Mp6OzgPcMdIar/m1 TkBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681326069; x=1683918069; 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=Db/OUHuiBKZEmOD0NamgtzWRyjc7jAhYxo5VMnnejuI=; b=ERb4/kiUpRDsDmV1eza938mq9u3ek+b1JDo3GUp6N4xJ3U7MXDs+ZTU8vxhtHe4Bx+ NRSs5xCQPgRW17JuEvdu+/UBpqU3g+lFMHZi1HPCnAuPCwQParoMO94S/3ntzB2xKvFE Kah9PiFFEEspg+aVZaFhoTP6sAUAoRHVEnVzkm/KDERTPj9SGYxuxtcpluJO04BgicBb LUYUMAIV58esAdw4txFldfYmfI7vJO7pR+udNx56ZZMO4xLm091BIzBgzn6penp9pOtp aLE6F9adDEAsmdMPeBi7qakIsGAOPKdZRWM/O3m2kRaIwjdFyhiKCzjMgCu76SHjQKpH O1Kg==
X-Gm-Message-State: AAQBX9cSkGEjj9ytvbm/98fYBG5rJ5jsZhBG7SGZC5gzL0WAzi7/i/tz lXv7lo71I61AOcOpkwuHaURukYICpktmSRch9Q2W4rY2
X-Google-Smtp-Source: AKy350Yma2ssErTFS9dnbR8tXf8hYMgTumrStN2rbsITQCdLO3j0o04tGuRarATvGZt2W1E8+wC3hwOr/EEEpKcN9nw=
X-Received: by 2002:a2e:3609:0:b0:29b:ebfa:765d with SMTP id d9-20020a2e3609000000b0029bebfa765dmr2390438lja.1.1681326068390; Wed, 12 Apr 2023 12:01:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
In-Reply-To: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 12 Apr 2023 15:00:58 -0400
Message-ID: <CAH48ZfwWdarZ4vagSAwG3WTa=Tk1Wp6uq8dF2XNLKy=n20OAAw@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ee11605f9283b4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DBnP2GUMr3saMBlgeMR-eowDtsk>
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: Wed, 12 Apr 2023 19:02:30 -0000

My own feeling is that lists should have a service agreement / disclosure
statement that says,
"We will modify your text in {manner} for {reason}.".
"We will do {feature} to reduce the risk of unwanted or dangerous list
posts".
"We will do {feature} to minimize use of off-topic posts.   The following
behaviors will ..."
"Your email address will be released to all list participants.   This list
does not condone use of list addresses for non-lust purposes, but cannot
prevent that from occurring.   Consider this possibility when choosing an
address to use for list participation."

My only point of reference is this list, and I am not happy that such a
disclosure was not provided at sign-up.

DF


On Wed, Apr 12, 2023, 2:16 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
> cover both ends.  We need to be careful about admonishing participating
> receivers though.  What would we say to them about how to be selective in
> application?
>
> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> 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.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post.  It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations.  MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>
> -MSK, trying to be useful here
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>