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

Дилян Палаузов <dilyan.palauzov@aegee.org> Mon, 28 January 2019 12:03 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 66014131023 for <dmarc@ietfa.amsl.com>; Mon, 28 Jan 2019 04:03:59 -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 PwdYRnKomwrU for <dmarc@ietfa.amsl.com>; Mon, 28 Jan 2019 04:03:56 -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 7EAC6131025 for <dmarc@ietf.org>; Mon, 28 Jan 2019 04:03:56 -0800 (PST)
Authentication-Results: mail.aegee.org/x0SC3c61013721; auth=pass (PLAIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548677027; i=dkim+MSA-tls@aegee.org; r=y; bh=N4fP/VjxhInNCE0w3tE+52E00yHkTGLm8W0msxIFvl4=; h=Subject:From:To:Date:In-Reply-To:References; b=LXBDXAKgZ6h/cqzpNrrbGRwRbzGp+GL525o32fyA+OF/RWcngttk9NCx5UgbYy3Bg KOrEtWDdUMEqvSwEkloRcB5TXAAnadfEUaPVZlL8aZFmNlqJhdcG6SdMPOu+QkRHNC Q4ZbNDGvRLUIj/IZHlYx5PUxNnOtFpHh0NFYcT6TsO7tNimVHWVCqsxY3Rq7vn8zpS J/pGXqVuw1x9fjb6ntmDDkCdRRBhKNEfUm4CpE8Vn/nBB+8g9QgA/rzm/CpoTvEha1 tF0IF5pa5w87MmK8pynfqfPctnBrKwEGo9yQWT6c18nh8GX4hKC6hM/IUuxXC66pm7 VhQVcXzleyHkUHSSwcUdWkVpsfLn2SNepTcNcXRH1ICbbrKWiiIXudpr/zamHq4Nwg P5yYwL0F60zjme2lhPHX2gzlxT+Uz7JrvcoX2yEPUfz8IiPRLnNuWPSK95jLT481oR V0cliDkQ31DIMqCkxMlCwcpDEdJy6EHvBvDFeAeyyBO7VGSoXUT9T8J3QiIIZC0GqM YIKNj+0zs+rqajIup7gu+W1LZdlaLAp9CAUxyts7EXwhap2cC4V9omF4reZFaQ+rM/ rFzDA32oU9AhKt4m0ibjgacJvtc9c90QMVyEG6lMvFHD3tCyicGvRESukwloXnaUNY XaqBM7ExCDVD1f2fVn0lVIF8=
Authentication-Results: mail.aegee.org/x0SC3c61013721; dkim=none
Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0SC3c61013721 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Jan 2019 12:03:38 GMT
Message-ID: <ccec6257175e633174ed792d41f2065cdae6b3e6.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: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
Date: Mon, 28 Jan 2019 12:03:37 +0000
In-Reply-To: <78afc62c-740d-0762-2d29-ba952ab35003@tana.it>
References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> <78afc62c-740d-0762-2d29-ba952ab35003@tana.it>
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 mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2oMozZlIUDIKl8ay0QkVoRjJND8>
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: Mon, 28 Jan 2019 12:04:00 -0000

Hello,

sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user
clicks a message as spam.  In practice, when a company owns two labels, that were distinct companies in the past, for
the one label the new company sends in the feedback loop the user, who clicked the the mail as unwanted, and the other
label does not include the recipient’s mailbox.

Both labels include the Message-Id in the report.  So when the messege was sent to one user, with the Message-Id it is
possible to determine which user clicked the mail as unwanted (provided no transparent MLMs were involved).  When the
message was sent over a mailing list, from the Message-Id it is not possible to determine which user marked the mail as
unwanted.

It is technically possible to provide to every single recipient-copy spread over a mailing list a distinct Message-Id,
in order to be able to conclude from the feedback-loop message, which user marked the mail as unwanted, and be able to
unsubscribe the user from the mailing list.  Is this the way to go, or is the rationalle that the one who implemented
the feedback loop including Message-Id intentionally skipping the recipient mailbox do not understand the big picture?

Will be there any rational concerns, if for a failed DKIM validation a report is sent to the signing server, containing
just the Message-Id, when From: alignes and DMARC p!=none?

Regards
  Дилян

On Mon, 2019-01-28 at 10:15 +0100, Alessandro Vesely wrote:
> On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote:
> 
> > 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%?
> 
> No way.  There are lots of little traps, for one example plain text messages
> where a line start with "From ", like so:
> 
> > From here on, this message likely fails DKIM.
> 
> As small as this cases appear, if you program your MTA to fix them before DKIM
> signing, you are going to break any OpenPGP/SMIME signatures that users had
> affixed before.
> 
> You can educate users to use format=flowed, good luck.
> 
> You can push for global maildir usage, even harder.
> 
> The bottom line is that, in practice, understanding where that 1% failures come
> from won't help eliminate them.
> 
> 
> Best
> Ale