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

John R Levine <johnl@taugh.com> Sun, 06 December 2020 16:41 UTC

Return-Path: <johnl@taugh.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 C0F283A0FCB for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 08:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=iVC0ud2i; dkim=pass (2048-bit key) header.d=taugh.com header.b=TO83kQOI
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 YfgMYJJPzEHN for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 08:41:13 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A58AA3A0FC9 for <dmarc@ietf.org>; Sun, 6 Dec 2020 08:41:11 -0800 (PST)
Received: (qmail 32383 invoked from network); 6 Dec 2020 16:41:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=7e1f.5fcd09a5.k2012; i=johnl-iecc.com@submit.iecc.com; bh=IXDmgcVdqDZc22kYzYRUaOK992eeVNmpARNPQP+IWh0=; b=iVC0ud2iviyO7Gu9V8afFpT1csazbMtsM9LFKfMJZhFFlDwiBftYm0b0Vph8ra4COVoz8tpiH10FdMYxtvWenE/ggzADq3pW1SDCjsZmsj1eNkR+15FMRStAV8dqpmz7GBfZ7sa3Hv1pb1tjr38wb1A/mFTue8aObBz1VhdHmHTN05pCWHPTYMGXblYiZ4sN3lkT1UhcA4DWL7MHLNaPOvfqrMm5VSGTTt/W0igVsYJTCqY97bpXAb87AydI5v/gbtgajUIByuXg+wChrIWnFFp8YIDwD7TDAJbwIaGukwhBDMGS0XhjMFhsvmPKHVupTkhUBrtjE1WC4UhBII/ooA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=7e1f.5fcd09a5.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=IXDmgcVdqDZc22kYzYRUaOK992eeVNmpARNPQP+IWh0=; b=TO83kQOIAHDnUZoskS00Wv9Dq6b4LRyR1Vnpc2SilG6QB9MRCcioTPh1LAUtpF6Br2Lvzj+9IJPg2oYGFIc3HLPq1hsrrI4xMYmIC9XQtyOtSiR0/Ogav7P4MgBTQuymgJ/SBT4Blkrh7k+d5oDRDOx9swSkNK4aNHcuXIWjk9Fy6+3Q2+A2Z/FdYe5Nz3QwHBLVsqIOHJSAi6AiGjKbAS5r72g4IllzjQ1kq18uiZEX17y1TtkWz7LbFL0lnaNyj84Waj8f2v1D/ed1Qsm9uU1xeez5ifHn4mREj8DyTsecmpyNba8j+VKfdP85t3ABb0faXUsfawm0/C962rtlEg==
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Dec 2020 16:41:09 -0000
Date: 6 Dec 2020 11:41:09 -0500
Message-ID: <144b4971-f276-b29-8ea4-45fd24a7a59e@taugh.com>
From: "John R Levine" <johnl@taugh.com>
To: "Alessandro Vesely" <vesely@tana.it>, dmarc@ietf.org
In-Reply-To: <570ba614-a138-8a83-eae1-e6077b82937f@tana.it>
References: <20201205210639.54261290454A@ary.qy> <570ba614-a138-8a83-eae1-e6077b82937f@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/NpqDDykKy9BsUnCEMZHQ9Ay9MDI>
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: Sun, 06 Dec 2020 16:41:15 -0000

>> If we want to do something like that, I would overload the existing
>> !size hack. For example, add an "f" for finished flag and say that the
>> URIs are conceptually processed from left to right and if you send
>> your report to one with a !f (or !10mf or the like) flag, you can stop.
>
> Legacy producers unable to interpret "f" may discard the whole URI.

At this point we're both just guessing what current code might do with 
syntax errors in a rua= tag.  Here's something that's definitely 
compatible:

We add a new ruap= tag for rua preferred, with the same syntax as rua.  If 
the reporting system can handle all of the URIs in the ruap tag, it uses 
them.  (They don't all have to successfully deliver, but it knows how to 
try.)  Otherwise it falls back to rua.  The goal here is that someone can 
put the new https: URI in ruap and the old mailto: URI in rua.

To send a report using the https: URI, the reporter appends the filename 
described in section 7.2.1.1 to the given URI and does a PUT of the 
report, with MIME type application/gzip if it's compressed an text/xml if 
not. The server responds with code 201 if the report is succesfully 
stored.

It'd be something like this if the URI is https://report.bar.com/dmarc/

PUT https://report.bar.com/dmarc/foo.com%21bar.com%211607068800%211607155200.xml.gz


Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly