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

Дилян Палаузов <dilyan.palauzov@aegee.org> Wed, 06 February 2019 22:12 UTC

Return-Path: <dilyan.palauzov@aegee.org>
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 8AB7B130E62 for <dmarc@ietfa.amsl.com>; Wed, 6 Feb 2019 14:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 Ck7qNi-PWjjp for <dmarc@ietfa.amsl.com>; Wed, 6 Feb 2019 14:11:58 -0800 (PST)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 7CEA712D4F3 for <dmarc@ietf.org>; Wed, 6 Feb 2019 14:11:58 -0800 (PST)
Authentication-Results: mail.aegee.org/x16MBtpU031557; auth=pass (PLAIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1549491116; i=dkim+MSA-tls@aegee.org; r=y; bh=LodIfTzoTme/eC9doO9HeTk5F3ntXADUZXNeHJ5WZLM=; h=Subject:From:To:Date:In-Reply-To:References; b=AbxQ/6I1oznY7IylFO7SHGoKTFCBbSM42z/Z429H/J6D2LKMiojQb/RSRSyN/3Aht 0FBSh6L+ZOOzUhBOL6xSf0fP3wNyqDggRk1VXwbVTsz0wxp7l1pb9MIwGgKfQkEpgN I/LzpjnJd0kRj30CfqeyyGjt8r/5wFc5Q2/hvRBirqZ2+PUYuji32OaTNbInm4xZsn I94nrgoo2VUYo/VLIrJynTsU7SBlgVUs5/Za2SUs1P2YMpJ5pPcd0Q8m3m4GaBrEtg eqBViW+0IjA72U9jRJXCJG10fgrgitmz6w3nzQhEB2IeJkGTGx6Dsk65oKW6y4bHer iER3J3hz86QxZ3ud7TuYrdmnuY32lTaWoB5XP29IMRtMWNckaF0uiBDVBNs6FAB79T QGhuh+b4SKvROSxKb8YyDVxJJt3/rjpUgCskKihuV3mTg7wcNO3ALYekUN0aK6TJ3J /eWER0JUEp7KC/S+VW96jwsPOMC5kBxgabP5YDip7dn0TkN2/HEAN99C/6Eq5vFsdw jnWYg2gQfS3QYaj/o6UXB8pWM+1unLe22hMTnYIGM3HT2CHIuzNIxtel1RJqln4fFy uEA/jXICNqXNu7wIY0vGuGkGOeuWIfIh/4+RbUFnf4+8HSF+1qgT5kSBA8VsmiSBnp POXTwZkcbGpw1S+cIG3PIVAs=
Authentication-Results: mail.aegee.org/x16MBtpU031557; dkim=none
Received: from Tylan (x5d877ef8.dyn.telefonica.de [93.135.126.248]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x16MBtpU031557 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Feb 2019 22:11:56 GMT
Message-ID: <e5763e2e64cae01a7b53f94e521b9f2d103f6708.camel@aegee.org>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org>
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
Date: Wed, 06 Feb 2019 22:11:55 +0000
In-Reply-To: <20190206010110.ED53C200DD2BA4@ary.qy>
References: <20190206010110.ED53C200DD2BA4@ary.qy>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.31.91
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/t2vAwVWXNAmWQoWfneeivS-oX98>
Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
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: Wed, 06 Feb 2019 22:12:00 -0000

Hello John,

DMARC reports for p=none are not supposed to be useful, as they do not depend on the policy.

If the question is about how to get reports on failing DKIM validation only on unexpectedly smashed messages, then I
recall the last discussion on Ietf-dkim@ietf.org:

- this is not DMARC, but DKIM domain
- when the DKIM-Signature does not validate, contains r=y and the remainign provisions from RFC6651 do apply, a
(usefull) report shall be sent
- when a message is intentionally modified, in way that the DKIM-Signature gets invalidated, the modified message shall
adapt somehow the fact that it was intentionally modified for particular DKIM-Signatures, so that no useless report is
sent
- Nobody wants to modify DKIM-Signature, so it is unclear where to add the information that the message was
intentionally smashed in regards the first and second DKIM-Signature, but not for the third one.

I proposed at the time to add a r=a tag, sending only report, when DKIM aligns to From:, so that after passing a MLM
rewriting From: no reports shall be sent (contrary to r=y).  Now I realize, that for p=none there is no added
usefulness, since
- DKIM-Signature gets usually intentionally broken, while passing over the MLM, and
- From: is not rewritten, therefore From: alignes to the signature,

so a useless report will be sent for the message.

Regards
  Дилян


On Tue, 2019-02-05 at 20:01 -0500, John Levine wrote:
> In article <974c2d00017358cdf3b78037e4276234db2cfdee.camel@aegee.org> you write:
> > Hello John,
> > 
> > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
> > > …  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.
> > How do you define a useful report and for which purpose do you want to receive reports? 
> 
> A useful report would be one that was a message that one of my users
> had actually sent and was smashed in a way I didn't expect.
> 
> > I mean, when does sending reports to p=none make sense.
> 
> The feedback reporting doesn't depend on the policy.  Please review
> section 7 of RFC 7489.
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc