Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy

Дилян Палаузов <> Sat, 26 January 2019 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DC18130F33 for <>; Sat, 26 Jan 2019 09:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HTJpC39GS8YN for <>; Sat, 26 Jan 2019 09:21:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 137FB130E5F for <>; Sat, 26 Jan 2019 09:21:30 -0800 (PST)
Authentication-Results:; auth=pass (PLAIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1548523289;; r=y; bh=B1H4Hxh75PAr1Msqd3tw7hCZ0+thZ4INlyGw1UIX7Es=; h=Subject:From:To:Date:In-Reply-To:References; b=U7pN5ca74zHcYbh3M2IyVAI9qH7D0YwECPTUyZ4Ft3goLDMUVYKm6nMfJxTxuldCY mDuaRcnvA9+iv4jD+uR8ueerOmQuU1c/KB2uqhTP90uJy9jaxD2Hzkx/gzCDQV4K8A nWbfRveLecQKvzCsNK3hSMib7ffPIElyAl2t63TtcOorvhV4TnVUz6RQ/ib2Xnu1tV V+e+fQ1sD+cmYTM7C4wRTTtIm8yiB1Ci/ao9+l6f8zsk91npiIFdItrCLKLm/2lum0 npEA/g/nFZvDUM76BMdVF+ky29J8DvQsuD2vTY8rvJ5dEq6AgOHWKTy6j/Zu+Ir+n8 zW4icYPDzIY2xuxy0/qhtY2WLm03IvHZ1mZejNcsO0ylycfyBOHDFRZ1OIRO03mLUj whLs2eTcA7usvbDFWnqZPIvy+4aKvwGAnYyDDQHc1zSCq6n8BnNoKSjgLf0hWEVS+p dIQ2wWOWIBm3ezdhuTZtEc5E6G+HXAwAISm+YuGtHjh7EpuklaEK2dy8c5Lv4Ye4PB gg6Igs++TY1wPTfMvwao5z44v7npZc2FpVGuaLli1+LPXBNeF8EZxLBClrdzcgNL0o 4cNJ/dBPvr3VHsMFqaNXg6uhS3TpRedwDgoJ98FIWx7++OLI7TONGHxwH+x0m+kWAy xuXduWBsg2YlzfCUleP1vHyc=
Authentication-Results:; dkim=none
Received: from Tylan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x0QHLSA4029944 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Sat, 26 Jan 2019 17:21:28 GMT
Message-ID: <>
From: Дилян Палаузов <>
Date: Sat, 26 Jan 2019 17:21:28 +0000
In-Reply-To: <20190126163123.AAA4B200D39816@ary.qy>
References: <20190126163123.AAA4B200D39816@ary.qy>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.31.90
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.1 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
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: Sat, 26 Jan 2019 17:21:33 -0000

Hello John,

On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
> In article <> you write:
> > How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM
> > signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)?  In particular, that there
> > is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff
> > function good as whole?
> I suppose they could try to put it in the terms of service, but I
> wouldn't begin to guess whether that would be enforcable or even legal
> in places with the GDPR and other privacy laws.
> More to the point, I wouldn't bother.  The failure reports are almost
> entirely useless.  Of the ones I get, the majority are random Chinese
> spam that happened to forge one of my domains on the From line, the
> rest are from mailing lists where I wouldn't expect DMARC to pass.

A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these
clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the
generators of those reports, that sending forensic reports violates users expectations.

The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on
deleted information) and because email staff and DNS staff may differ.  I approached both concerns, by stating that user
expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive
forensic reports and insert this infomation in the Terms of Use.  So… what else exactly needs to happen, to resolve the
concerns against sending forensic reports (which was my original question)?

If GDPR is the only concern, this can also be clarified.  But clarifying that GDPR is not a problem, will be losing
time, if independent of it there are other concerns.

Imagine there is a failure report stating that after a direct communication between your server and another server, the
receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM.
How do you suggest to proceed to reduce this to 0%?