IETF Logo Mail Archive

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

Alessandro Vesely <vesely@tana.it> Tue, 26 January 2021 17:27 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 A55143A0BDE for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 09:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 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.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 tuqalT1SAkfs for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 09:27:09 -0800 (PST)
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 19E963A0BC5 for <dmarc@ietf.org>; Tue, 26 Jan 2021 09:27:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611682027; bh=AEEOAyh9sqRyYZH72ZkzxtCAbXOO2uiry2jEIlbCWvA=; l=842; h=To:Cc:References:From:Date:In-Reply-To; b=DDhcS70c7+/MKAUFSTaPJcj1OfrhLuotjnHBK2dnyUzYCn2VKFgtywR8VZwZYZWYx sY0xDxmHk4tAWu+lKeOcisaq3keoKfxNyt1n6N6bB26lEMM0MkBNRjO3LST7/iofNX F9RpOV4MFvD3WgGW2uW86ITwgWmoFEhQUTA8EM+fNnCz55cabdGtOG6fY9miy
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Original-Cc: IETF DMARC WG <dmarc@ietf.org>
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 00000000005DC053.00000000601050EB.00006964; Tue, 26 Jan 2021 18:27:07 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, John R Levine <johnl@taugh.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20210125212225.9045B6C14E41@ary.qy> <5749790e-c305-b77d-a2f7-94c30579aa4e@tana.it> <bbff75e7-9580-cd37-da2-e797a53859f3@taugh.com> <CAL0qLwbPNw-LaCJPUBNZk_ZNZ76bNTzb+7OHBWeiYsYyZQJZxA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <e1c50fe3-7a80-62e7-ae9d-6347f50d389e@tana.it>
Date: Tue, 26 Jan 2021 18:27:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwbPNw-LaCJPUBNZk_ZNZ76bNTzb+7OHBWeiYsYyZQJZxA@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/G4JgW__IJaM3euKpl6eHJ409nZM>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
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, 26 Jan 2021 17:27:11 -0000

On Tue 26/Jan/2021 18:23:35 +0100 Murray S. Kucherawy wrote:
> On Tue, Jan 26, 2021 at 9:16 AM John R Levine <johnl@taugh.com> wrote:
> 
>>>> Sheesh.  That isn't mission creep, it's mission gallop.
>>> The spec can be commissioned to a narrowly focused WG (like dcrup).
>>
>> Really, no.  It's something we might think about on its own merits some
>> other time, but its absurd to try to do it as a detour from DMARC.
> 
> +1.  I don't see why we wouldn't just recharter this group (if that would
> even be necessary) to do it.  The right audience is already here.


Doing it now might overload the WG.  If DKIM for binary has its own merit, we 
can just hypothesize we'll do.  Meanwhile we can mention it and suggest to use 
it for https: when it comes, if ever.  After all, that's what RFC 2045 does 
with "binary".


Best
Ale
--

v2.23.0 | Report a Bug | By Email