Re: [dmarc-ietf] Signaling MLMs

Steven M Jones <smj@crash.com> Wed, 12 April 2023 19:45 UTC

Return-Path: <smj@crash.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 8A849C152564 for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 12:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=crash.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 QxA9ZPJLM2qx for <dmarc@ietfa.amsl.com>; Wed, 12 Apr 2023 12:45:02 -0700 (PDT)
Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E9FC1522D9 for <dmarc@ietf.org>; Wed, 12 Apr 2023 12:45:02 -0700 (PDT)
Received: from [10.10.10.103] (192-184-205-120.fiber.dynamic.sonic.net [192.184.205.120]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.16) with ESMTPSA id 33CJiwli060576 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Wed, 12 Apr 2023 19:44:58 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 33CJiwli060576
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1681328700; bh=FpDrpPToFaRwn8eddBl+RQXAhdzE/OBsuBmi/bGNN94=; h=Date:From:Subject:To:References:In-Reply-To; b=c76quEuobwm3n+MM7B8jwuLH+2IvhamC1AOZNdUUXYrrn4jH1DSiamvFkApU00MPI HY3UhvvGfsSfz0WjYTGIc2KGhMV+9VQyjq5PvBQn+/UowrChM5+POP23RS7Gml2NgN EKt2dMoYk5wL7flNwFCsbix7PMdxkOZuEC9lUcgkbqr4beDtLwFoZLyGl9FND7ohb9 YdqrtcvfpRFYH8axrmj1RA01gAsWxxSjr/z3d4dMfGZy69dndcVCXszSq7aGTi3BmB VDcv4ASs/LI6leRG+fAxOVt0llByuCJUJv/v5I3s0Dc0ZNHsme0qHwsL9NwckWpvHg RUMu+n2LSSQ6Q==
X-Authentication-Warning: segv.crash.com: Host 192-184-205-120.fiber.dynamic.sonic.net [192.184.205.120] claimed to be [10.10.10.103]
Content-Type: multipart/alternative; boundary="------------PUYY4CvegT4vUTg3jC7IQ6uN"
Message-ID: <8d970e6b-8fa7-da85-5c47-d485abbc43be@crash.com>
Date: Wed, 12 Apr 2023 12:44:58 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
From: Steven M Jones <smj@crash.com>
To: dmarc@ietf.org
References: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
Content-Language: en-US
Organization: Crash Computing, Inc
In-Reply-To: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (segv.crash.com [72.52.75.15]); Wed, 12 Apr 2023 19:44:58 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/AJ3GBWEJtCtcTWVcjmuyFChQ5Gg>
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:45:07 -0000

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:
>
> 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 puts me in mind of Section 8.5, which calls out some potential 
impacts of blocking policies to "Mediators," which role doesn't 
otherwise appear very often in this document. Is there any need to add 
Mediator Actions/Considerations under section 5? Or does this belong in 
a separate document?

ISTR there were some vocal and visible mailing list operators that were 
rejecting messages from domains that published "p=reject" policies, 
maybe around 2014-15? I also thought they did this by checking the 
sending domain's published policy in DNS, to your point about 
implementation.

In which case I think this approach was tried, and I don't recall it 
persisting as a pain point for terribly long - perhaps they moved on to 
"unsavory mutations..."

In any case, are we really going to start suggesting that list operators 
start rejecting messages sent from domains that publish a blocking 
policy, as official guidance? (Now I'm looking ever so forward to 
catching up on these other threads - what the heck are people seeing out 
there??)


On 4/12/23 11:41 AM, Todd Herr wrote:

> My preference here would be to add text for Domain Owners to make them 
> understand the ways that p=reject might cause some mail using their 
> domain to not make it to its destination, with "mailing lists might 
> reject your mail" being one such example.
Yes, it seems like we'd either add something short to domain owner 
considerations per Todd, or we'd need to add considerably more to cover 
list operators and/or other Mediators.

--S.