[dmarc-ietf] DMARCbis issue: Reporting URIs

"John Levine" <johnl@taugh.com> Mon, 27 May 2019 19:32 UTC

Return-Path: <johnl@iecc.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 A5EC81200B9 for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 12:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UhVzCKcU; dkim=pass (1536-bit key) header.d=taugh.com header.b=IoL5B/7y
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 2HsLVEZaNtsy for <dmarc@ietfa.amsl.com>; Mon, 27 May 2019 12:32:06 -0700 (PDT)
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 18BEC120094 for <dmarc@ietf.org>; Mon, 27 May 2019 12:32:06 -0700 (PDT)
Received: (qmail 43011 invoked from network); 27 May 2019 19:32:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a801.5cec3b33.k1905; i=johnl-iecc.com@submit.iecc.com; bh=cO+ApSbUs7G+RMIMJ903lZC/mQNFMdpZpCCeqKENoV4=; b=UhVzCKcUxc6tqpKU6P7ANFButvi+3jdIKggE8jFMmKd1TcoRpgEBkFth0QTRAXFlYbTbksYVTqwZMubV5T3BC7d8S47U5n9OgSphV7AmIk+Bcd9hyo7VnxgNoKAzRpDPAeIl+Er2DNPLYuJ0TmRGbP5O89mtz+DktXuY53snpEvf3qn5ehp0Imvwpl5h2eF0oEOnYDPodS0I8Ja2tPwUvICGFPT39Tq2EBgALSaqeefiK9ItMa0yUxRaMm/Rfyl2
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a801.5cec3b33.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=cO+ApSbUs7G+RMIMJ903lZC/mQNFMdpZpCCeqKENoV4=; b=IoL5B/7yeuT1RG72hAkqbp+3i+CaDvSHxMZxVN7w7GMiGOUDZ02mOsJogYuQyoouvHXitF8wxusU20JLr/vouVyDQClCp7BMgPU1OXWSrVRCz0rBJ9dHEnWEc4oE89P3ZLyHPdiIfPeFTAL5fVrojDn3AH63omNoeksYsDfqaST4stlNppIMUogfQ/KT7fYnneOqxDxmb1AVk0Z7lcZ3S8fPh/raf2EAm83AVO5KO5HVOz7RwFXNQSFGv5RVM9qD
Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 27 May 2019 19:32:03 -0000
Received: by ary.qy (Postfix, from userid 501) id 4B74F2014AD9CA; Mon, 27 May 2019 15:32:02 -0400 (EDT)
Date: Mon, 27 May 2019 15:32:02 -0400
Message-Id: <20190527193203.4B74F2014AD9CA@ary.qy>
From: John Levine <johnl@taugh.com>
To: dmarc@ietf.org
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/iKpLKGdneTs85ioOiG_RwR5Vssc>
Subject: [dmarc-ietf] DMARCbis issue: Reporting URIs
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: Mon, 27 May 2019 19:32:08 -0000

Section 6.3 says that ruf and rua tags can take any URI, but only
define the meaning of a mailto: URI.  Either it should define some
other URI schemes or it should say that only mailto: URIs are valid.

Back in the olden days there was an http or https scheme that we took
out because it was ill specified, and nobody but me had tried to
implement it.  If people are interested in an https PUT scheme it
would be easy enough to define one, but only if someone says they want
to use it.  For large reports it could be somewhat faster than mailto
both because the report body isn't base64 encoded and the report goes
straight to the https server and doesn't get relayed as mail does.