[dmarc-ietf] Purposes of aggregate and per message failure Reports

Дилян Палаузов <dilyan.palauzov@aegee.org> Sat, 10 August 2019 09:14 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 061161200BA for <dmarc@ietfa.amsl.com>; Sat, 10 Aug 2019 02:14: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] 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 e4CP0qlzq7HM for <dmarc@ietfa.amsl.com>; Sat, 10 Aug 2019 02:14:06 -0700 (PDT)
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 80EF1120058 for <dmarc@ietf.org>; Sat, 10 Aug 2019 02:14:05 -0700 (PDT)
Authentication-Results: mail.aegee.org/x7A9Duro025182; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565428442; i=dkim+MSA-tls@aegee.org; r=y; bh=+TmO1EYukcx0CI8P3cl9IvbvvNdFvX28TboTe5Zp8Bk=; h=Subject:From:To:Date; b=pdrjqqM1jV+Xs8k6ZzNqZSCXjL3t5fDnTMP9+FvGIqOaHVmAmR58X9AW75qGM6drN /TEghgssoae5nQkG4IABSepMibyE0ufTdpvLVpz5OYPoHqeDgNk742OxAgddch5ZdH xV16eb2TAIqqcZb4bH0xuIRInMoLJ1pi27vYSJEJ5qgib/ZWJiPjLR4tu9AZZJMkJV vxdp4Jb4SkFmhVrnigI3V3ZM7VPb8m1Ao6qp5SHKsivb6TgoiySkra4Tge4IY4Y6Xi YDpPWT7PUnjNSd5WTLwnhxC6f5YMVy9fyqao1hZj5Pb34XLIYyrVdNYQkOmU15m8da V/g68hlbXKv2jXkmglh5OAFxX6f6XL8UMft/nHSEfg+fUu3Mq9vD7FtbmwYhmF9Xq9 IS7KjOiQFmnOGWiXPTAuwdA9z646J6H93VPvwDJMCCppZy6N8D4JHdtZABmp2hlKTl GeS/rezM/y1ZmI56uulOXLjgKa/G4qUE/Yiy4VqK1bqJWTn+B10nmwzOLc5JX8rKKF DwGNn7cjfTZ/YjiCMvPTQefkKdELyqdNZ624TSKkt4QLo45xDnLeHCrsrKuArjkfuP p+TX2I8La2ubEyqf8uTNDjfFaXl2B8iEpZSKr/c47ibSetddUDYI+fHvx0D7TC7x0a 4jyCyWRCwClcU48vNGc+zlAc=
Authentication-Results: mail.aegee.org/x7A9Duro025182; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x7A9Duro025182 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sat, 10 Aug 2019 09:13:56 GMT
Message-ID: <2e2e9fa0a4da92b5d02a41a803e9947f6c562696.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: dmarc <dmarc@ietf.org>
Date: Sat, 10 Aug 2019 09:13:55 +0000
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.91
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.3 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nQQ4dhxSe-kmmImr7cFKSplvl9E>
Subject: [dmarc-ietf] Purposes of aggregate and per message failure Reports
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: Sat, 10 Aug 2019 09:14:07 -0000

Hello,

the purposes of the reports shall be first articulated and then the content of the reports shall be augmented to fulfil
the purposes.

* * * Purpose of Aggregate Reports * * *
Some purposes are clarified in the email from Michael Hammer/2019-07-31: “

Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams
will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that
rate will help you identify problems.. An increase in the failure rate is generally either 1) someone trying to abuse
your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization
has started sending mail from somewhere without appropriate SPF or DKIM.”

--
The email from Tomki/2019-06-21: “
As mentioned by Elizabeth recently:  (Elizabeth please chime in if this doesn't capture your meaning)

The spec does not define *which* DKIM signature should be reported in the DMARC RUA created by a receiver.  The proposed
resolution to this is that if the receiver does not provide the complete set of DKIM  signatures found, they should
provide (in order of preference)
1. a signature which passed DKIM in strict alignment with the From:  header domain
2. a signature which passed DKIM in relaxed alignment with the From:  header domain
3. some other signature that passed DKIM
4. some other signature that didn't pass DKIM”

Once the RSA-SHA256 signatures between two sites function properly, the aggregate reports do not allow to verify, that
the ED25519 signatures also work correctly.  Thus two sites exchanging emails cannot know, if switching to only ED25519
signatures will work reliably.  With this in mind, a new purpose of the aggregate reports is to allow for two sites,
having proper RSA-SHA256 implementations, to verify, whether the ED25519 implementations are also correct.

--
For what purpose the envelope sender is communicated?  My understanding of recent communications is, that this
information is exchenged, I do not reread the specification now.

* * * Purpose of Per Message Failure Reports (also known as forensic report)

My understanding for the purpose of the failure reports is, that these can serve only one of two purposes:

* Either verify whether the DMARC/DKIM implementations of sender or receiver match,
* Or spread information about scammer actions

(The concerns for not sending failure reports for privacy reasons are only for the second case.  The concerns about not
sending reports in the first case is about silencing improper DMARC implementations).  The case, where the implentations
match, but the sender forgets to sign messages from its servers, is uncovered by the aggregate reports, and for fixing
this case, the aggregate reports provide sufficient information.

Regards
  Дилян