IETF Logo Mail Archive

Re: [dmarc-ietf] non-mailing list use case for differing header domains

Alessandro Vesely <vesely@tana.it> Wed, 29 July 2020 08:49 UTC

Return-Path: <vesely@tana.it>
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 6FC303A0C38 for <dmarc@ietfa.amsl.com>; Wed, 29 Jul 2020 01:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAqczrafLY7l for <dmarc@ietfa.amsl.com>; Wed, 29 Jul 2020 01:49:53 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 D7EF03A0A3F for <dmarc@ietf.org>; Wed, 29 Jul 2020 01:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596012591; bh=GpViQP27ievK4MKltSJKt2d6gWc2r7xmp/GStjGDLCc=; l=1028; h=To:References:From:Date:In-Reply-To; b=B/pcZxEYvzYGDprAqL/OhPhtjHjN7ALcsUP+vsyukdzNQSVSBPbNJzJSvJGjl+QHu kbNKggaM283e7YGmGLYYgNglOB1fllnSJ8Xv2YLHEqmHyWld8nyREdQDHIonU/2B7L EibrLEai0bOv6Z4cS5KS3ntoK3a5HLHDuKHgUHkxQS9WWBUhKIZuYwQRc3tu2
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005F21382E.00002B9C; Wed, 29 Jul 2020 10:49:50 +0200
To: dmarc@ietf.org
References: <BY5PR13MB29998094418C8A6C25902569D7730@BY5PR13MB2999.namprd13.prod.outlook.com> <c0361cb2-b25b-5d75-cb1f-f9c87e3ecccc@tana.it> <AE9A3A9F-27FC-4935-B8E6-AB0CE1A6D5E2@wordtothewise.com> <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <99275d09-dbdf-1167-11c6-8a42a09789b0@tana.it>
Date: Wed, 29 Jul 2020 10:49:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lkEZLIp_nQyB3V_gkNH8IvKgdAM>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Jul 2020 08:49:56 -0000

On Tue 28/Jul/2020 19:19:50 +0200 Doug Foster wrote:
> Hector, I do not understand this comment:
> 
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma."
> 
> Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key.    But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer.


It is difficult, even for smallish domains, to get a complete list of MLMs which legitimately distribute messages From: their users.


> The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request.


Right, a possible approach is to outsource trust.  If you lookup my SPF record[*] you can see an example.


Best
Ale
-- 

[*] "v=spf1 +ip4:62.94.243.226 ?exists:%{ir}.list.dnswl.org -all"

v2.23.0 | Report a Bug | By Email