[dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

Alessandro Vesely <vesely@tana.it> Wed, 09 December 2020 17:07 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3A8043A1009 for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 09:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CJ8-Re6pP2_K for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 09:07:54 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it []) (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 441613A0E63 for <dmarc@ietf.org>; Wed, 9 Dec 2020 09:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607533670; bh=gtlCgWUFld/C/wKeu0obZbn0plDRtZB12YKfCdcwXYw=; l=1750; h=To:From:Date; b=BZU0RZGgLiPxipQbJ2WXcJqsYmm3guYubV0uD0awUPGWIhf+5xeiae5Cc2NDvN+YO VrQEyjm+yhnwzxDD6XvHBVtr3dtiRq8o6yNgXEaBXK6qLKkn9a/y6YM0m5RAEACUOA ZuOpSO8ljWYHq7S+KlUxCUvv6tG+UOv/r+FKawbcWMpDrAMhhPCpNPtmRg5E7
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005FD10466.00007F60; Wed, 09 Dec 2020 18:07:50 +0100
To: dmarc-ietf <dmarc@ietf.org>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it>
Date: Wed, 9 Dec 2020 18:07:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9jQ_qCNimecMRyLHHCoMkx7RR64>
Subject: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report
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, 09 Dec 2020 17:07:56 -0000

We would like to close this ticket by Dec 23, two weeks from now, so please get 
on it.

The ticket text is:

     It has been asked for a new report type (perhaps a subset of failure
     reports) that provides minimal data from the email (specifically, the
     initial ask is for the to: and from: email addresses only) in order to aid
     identification of the email's destination (and hence, the owner who can
     help with getting it authenticated) without providing other PII.

     This is a significant use case for large organizations, where the
     departments or other sub-organizations run their own emailing
     infrastructure. This has been specifically requested by multiple

DMARC failure reporting is based on Authentication Failure Reporting Using the 
Abuse Reporting Format (RFC 6591), which in turn is based on An Extensible 
Format for Email Feedback Reports (RFC 5965).  DMARC adds five fields for the 
second MIME part of the report.  The third part can be either the full message 
of just the rfc822-headers.  The latter is defined in The Multipart/Report 
Media Type for the Reporting of Mail System Administrative Messages (RFC 6522), 
which mentions that Received: fields can also be useful for diagnosing 
failures.  In any case, private data such as the local part of email addresses 
can be redacted according to Redaction of Potentially Sensitive Data from Mail 
Abuse Reports (RFC 6590).

In order to be useful, reports should contain enough data to discern whether 
the failed message was abusive, and what stream does it belong to if it wasn't. 
  Should DMARC Failure Reporting (our document) include some guidance about 
what parts of the failed message to include and which ones to redact?