Re: [dmarc-ietf] third party authorization, not, was non-mailing list

Alessandro Vesely <vesely@tana.it> Tue, 25 August 2020 09:03 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 B4E7D3A0BAA for <dmarc@ietfa.amsl.com>; Tue, 25 Aug 2020 02:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.146
X-Spam-Level:
X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 w_Uobl75kHOk for <dmarc@ietfa.amsl.com>; Tue, 25 Aug 2020 02:03:46 -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 254BA3A0B87 for <dmarc@ietf.org>; Tue, 25 Aug 2020 02:03:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598346222; bh=aPoFLsCH4HJzwQF/hYVjzXhfwzhtEQpCTlQYzTtvoM0=; l=1434; h=To:Cc:References:From:Date:In-Reply-To; b=AYlavvnjN/1qnZeNpMGarKxBDmhlnnerJH0inztLVcOx+fFwTSgW/1BDF1Up37jYs DWl/pOgEZwHeISn9mJ01HGLKSSarRXxsJZvijaaFYIyAH+Wz6lWtGJPbj0bxKoHDNu KXkBBFNDD1ZlmtcNFutsM1LZa6maSKARA2bWtY664hYeCvBsyfkXfvsZQtCMw
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.103] ([5.170.68.61]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F44D3EE.00003B23; Tue, 25 Aug 2020 11:03:42 +0200
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
Cc: superuser@gmail.com
References: <20200824172403.A927C1F14BF5@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it>
Date: Tue, 25 Aug 2020 11:03:41 +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: <20200824172403.A927C1F14BF5@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/6a0x0C3qx-VTKVNZqCIhDyV6cak>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
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: Tue, 25 Aug 2020 09:03:48 -0000

On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote:
> In article <CAL0qLwaip0fzXpqnK=XTcEELZRat_gnjuEGZYj=8qgy3wkYfXw@mail.gmail.com> you write:
>>> If the intermediary DKIM signs the modified message with their own
>>> signature, that provides some assurance to the receiver.
>>
>> You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
>>
>> I'm pretty sure that got implemented too, but I can't recall now if it ever shipped.
> 
> I don't think it ever did.  It has the scaling problem of every system that sends to mailing lists
> having to decide what mail it's willing to have re-signed and what domain the second signature
> will use.  Usually it's the domain name of the list except when it's not.


Right.  The only practical implementation I see is that the sender has 
a list of recipient addresses that require weak signatures.  When it 
is about to send a message destined to a listed address, it can fork 
the message so that the weakly signed copy is sent to the (trusted) 
list address only.  Any direct copy is signed in full.

To configure that, a postmaster would need an application by the list. 
  Something saying "your users A, B, and C are subscribed to list X, 
please sign weakly".  The postmaster would then verify if A, B, and C 
are trusted users and if they confirm to be subscribed to X.  In that 
case, the address of X gets enlisted.  Would that scale?


Best
Ale
--