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

Dotzero <> Tue, 08 December 2020 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 694F73A0FB1 for <>; Tue, 8 Dec 2020 06:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WbAxCYP1hbmH for <>; Tue, 8 Dec 2020 06:57:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B699C3A0FD3 for <>; Tue, 8 Dec 2020 06:57:13 -0800 (PST)
Received: by with SMTP id p12so12070414qtp.7 for <>; Tue, 08 Dec 2020 06:57:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8mXyH9BRQ/A2apqum3CtqUzxtTn5r+RptI39iyhU64I=; b=smHBZ0xylUSjse3H5Jl2Luzl7hGXBhZaLBQUlcdgGV3FbX3lkiCooNXhrF7Fl7+q3J Zq3Oymx4yuTReqikTbijbEmgiohwuk+SHZrAnZOFibW+v0H6iRNwEy6ZSA5QqRB0ZHeI 8bn5BHuXrmdZz/jtblQ4GgzencNvIhTtRdyRWfjYM/GX1SFCoqCO78tKO2goUUEkepTb t0Hu3ezBVgQMYRuW3z4W32fHStC8DPxr4RqjCaWwSi4gXPwVfVS3NqvGpEoxhMX1vDW9 kPjJmvGBoYQ7+30ePIhUtEpbwdpq76svP/kC2DWXEhNSUwCjpsgiA4iavHVEFLJVVVbP t6ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8mXyH9BRQ/A2apqum3CtqUzxtTn5r+RptI39iyhU64I=; b=BPfAoZzEDmLbb8pnY5P9Ahj7Pd8ZlQrSXw//QfXZ0oXKoG7i8pl5yd2WTxKxQmc1LA sS4ZEudu1K/+TdoO5XWAgPpnoqiJckhzWXKRTpKTPir5fBR+8t0FSGSRnbchPC9ZWRLL LdMXYlDjIHDJ8IjJBjORGm+cOQBMS/2IPA0SjL4BeoP3GIAeB0qSpMZCY1M43xokDAmH jDqOuZk6rA4wvZ5zZGDdbsIFTpc+NLP4bRscpNdVFPr8OA9bcbSfy3tUN/GLjKuMWAhA xOH3/BG5V4zFRBfSLnNqEH4qY3wMf9VkgH328tT9pOBg8h2XjYuJJLLLsYfPLR9OC1WL zvLw==
X-Gm-Message-State: AOAM5300dP8nqOKvMw0yY+vdpgH55oXYPvbZpEfi0eoHIFDNs/ADeFdk 9S+TyUp5CXzlnDgYxOHdi9qhFz1vqUCOh6iXyScylTcA
X-Google-Smtp-Source: ABdhPJy0zCqm6h6naiDhIsa0WdODoFxiw+Njs/48YvANIMMOCiOnCfk5Whndehna0jQ2xA7q/hKrJOwVcqB7/uu9Nmc=
X-Received: by 2002:ac8:6bc2:: with SMTP id b2mr14604115qtt.286.1607439432691; Tue, 08 Dec 2020 06:57:12 -0800 (PST)
MIME-Version: 1.0
References: <> <20201207214133.2D5142922931@ary.qy>
In-Reply-To: <20201207214133.2D5142922931@ary.qy>
From: Dotzero <>
Date: Tue, 8 Dec 2020 09:57:01 -0500
Message-ID: <>
To: John Levine <>
Content-Type: multipart/alternative; boundary="0000000000006235cd05b5f52839"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Dec 2020 14:57:26 -0000

On Mon, Dec 7, 2020 at 4:41 PM John Levine <> wrote:

> >I don't understand the security or GDPR references.
> Well this is amusing. I wondered if anyone had ever implemented some
> version of the http reporting in early DMARC drafts, so I set up a new
> domain
> with a server that will accept POST or PUT requests and added its URI to my
> DMARC records.

What is tht "mantra"? Running code and rough consensus? Has anyone
implemented such reporting?

> I didn't get any of those (the POSTs below are not to the right URI)
> but it's impressive how fast Russian bots started to probe it, within
> hours.

I thought it's about interoperability. Simply having a webserver running
doesn't come close to interoperability, and certainly not at scale.

> This is not a reason to avoid https reporting. Every web site gets
> probed like this and so long as your web server rejects unknown URIs,
> they're harmless. After all, my e-mail reporting addresses get a
> certain amount of spam, too.
> R's,
> John

My question was not intended to imply that HTTPS reporting should be
avoided. My point was that there has been basically no security discussion
or scrutiny of such an implementation. This document is now proposed
Standards Track, not Informational or Experimental. As such, proposed
changes or additions should be given. Your surprise at what happened so
quickly after your "implementation" proves my point that there has been
little if any thought of security considerations for this proposed change.
My comment about GDPR was simply meant to indicate that the world has
changed quite a bit since DMARC was made public in 2011. So too have
security considerations evolved. I have no objection in principle to HTTPS
reporting, only that such an addition be given the same consideration and
scrutiny that DMARC itself is being held to.

Michael Hammer