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

Jesse Thompson <jesse.thompson@wisc.edu> Fri, 11 December 2020 17:24 UTC

Return-Path: <jesse.thompson@wisc.edu>
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 664733A0D38 for <dmarc@ietfa.amsl.com>; Fri, 11 Dec 2020 09:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu
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 P9N8jUBprYz8 for <dmarc@ietfa.amsl.com>; Fri, 11 Dec 2020 09:24:24 -0800 (PST)
Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2CE3A0D21 for <dmarc@ietf.org>; Fri, 11 Dec 2020 09:24:24 -0800 (PST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL600AOYR0L0F70@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 11 Dec 2020 11:24:22 -0600 (CST)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.12.11.172117, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.59.170]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mzwsLIES97wplXMe53zZdnYV8Fuw1+uG+ZzeOTt7DNuRaYjkSgefvM7Gt7tVfO1fST/uTHMGuVfhoR0i4xuSxqGgW2QA/1qkTyeEe4E+ySpxsrmKuPE4dTxjQrg1E7wajJBMTi7VWszr71MbgdK0vZcEG/veteqyQfz02DxUP/zv0ON0u0eArAkkGGPnQInqJbBhMZJ2ZlVufEwEprOQ0GPOQjFCLpRAJQMUl4uXUNKhCJ0oh1TSrzTUIJjTcqIp6ZlJF/8V5uiHQNZAseNgzOpB2jCo291RCrJM/+UKjzGz22ujKd5cEaOE80elm5tFR6/pdL4CPt3nJSBKUkSwTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C5/5l0yEDAtc2R6B/Hq2nnx5CPmYT3WhPvmvdkiElRs=; b=WTWw6NpDs6wtzEX+ZtJm5L/LWc4dJMO5Y84Wt7i/6jsdaojmeaDcuM4FiABMGcPEZjjOyho2OQYBIzIymmtznqYO4DCXeELbEuqDL0K04gajb7qjHHs8n876S/XgKKAS55gdR+e3Vc1rzJrDdK7v7oWunhr8btJaMVCyLu+8C5bM7W+hsIpWNgew17iy50hLE6xe9vVnlW7MZNLoRfPcruRVQuGhvAnseagNOHI0xw+/h/mL0Wir18JKTCRAd/wxUZTYGsHPfPx/0Fo1UWnU2GO+6DaiG51w42sjoEGqI1QInaWkdwT+BjdwkRoBjHWyHj2kbymcmo83by0DuE3zjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C5/5l0yEDAtc2R6B/Hq2nnx5CPmYT3WhPvmvdkiElRs=; b=fCOb7ZhSe8oqr41gtF8MO/YbpUTHVevw/hxE2/73u4PW+uVotzZsyjtoEhBtXY3FEaSJdxsXYgcI6xzrR2MAfJNU+HpnLrNUUOLZ3b39nVZNTN7lbkI8txSqpYcvHXb321O72+SKyVQhSlj3ZSNnpB/TDclDzfo7HUxQlPvKdzk=
Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by CO6PR06MB7298.namprd06.prod.outlook.com (2603:10b6:5:353::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 11 Dec 2020 17:24:19 +0000
Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::852d:bd8b:f632:f4ca]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::852d:bd8b:f632:f4ca%5]) with mapi id 15.20.3654.012; Fri, 11 Dec 2020 17:24:19 +0000
To: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
References: <609e1c9b-cc4d-d7d1-0fa8-79f515c1eee4@tana.it> <20201209185246.1D40C29474C4@ary.qy> <CABa8R6sU0RQLSBA2LRk4mnkpzWVP5qBMbbHeTaw6VdgG02preQ@mail.gmail.com> <CAL0qLwa04NVQyP+=4o905ZF-e+NxmHhQqXZ5sGbdU9x8T3jSjg@mail.gmail.com> <CAOZAAfNUGVriJfjhQCo_3phg_pajfJsComr8zJBZcL9_Ucy3Nw@mail.gmail.com> <cf5a0365-b389-3589-48f4-333023caa7ce@wisc.edu> <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it>
From: Jesse Thompson <jesse.thompson@wisc.edu>
Message-id: <20575bf1-3813-4b3c-e59c-54e38b0da670@wisc.edu>
Date: Fri, 11 Dec 2020 11:24:16 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
In-reply-to: <747eae71-24e7-fd05-2123-2c22ae4588e8@tana.it>
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: 7bit
X-Originating-IP: [146.151.213.183]
X-ClientProxiedBy: CH2PR02CA0009.namprd02.prod.outlook.com (2603:10b6:610:4e::19) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [146.151.213.183] (146.151.213.183) by CH2PR02CA0009.namprd02.prod.outlook.com (2603:10b6:610:4e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Fri, 11 Dec 2020 17:24:18 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 8c5b8729-aef5-4928-e1ef-08d89df997e6
X-MS-TrafficTypeDiagnostic: CO6PR06MB7298:
X-Microsoft-Antispam-PRVS: <CO6PR06MB7298A369EF6C4AC6DBFFFB1AF6CA0@CO6PR06MB7298.namprd06.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: v1WHUBEfVRQrOp/IS2AdV7Kl9E45k99B09BuTyR1Sg7rWCsWqSTyHRCZ3G8/RZBkZi/6H0x2LLzWuDHLLVh7iB49Tfnseb//RcD8COwACeUemSQEgKt5Gx3nvGtHFWsWkKA0SvVO1jwhE5caXzMuV6+fR2U6vB22l0vMbVwdoKUvalHhCegZODSTn6Eq3HPpMKMlMQwPDXgZnCKO63QeYyPQNkh9uF9CfA7YAxBnoS3i380ZK+N74rd451UOSHfcfH9yRERkZFw13gy1mfAHPdcrNhX2xCqB3BYy9TtGinxyfGR3vZpyFudrtYeMsDKpzwmu60gzYEVUjhYXIeOfow7KKAoTfhzllRq91d04J1PHTBibFns/7p2Rmwnh7AvlVrAxh+bwZraU6bWB/A0f4FVONeoo5yXbHzAG2S/MMTgHq6PQPyLGDXeogcybYK3k
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(366004)(6486002)(2906002)(31686004)(5660300002)(6706004)(31696002)(16526019)(53546011)(86362001)(186003)(66476007)(8676002)(956004)(44832011)(786003)(75432002)(2616005)(83380400001)(36756003)(508600001)(66946007)(26005)(16576012)(8936002)(66556008)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: 3h1iXYWoVKSVzELL63/wCcH/IiaDafQFIxtFpnZCcYxyBPdBYgTokxffCCtNGFv7oVRWCMTga0ih1yroHX+mQKhukmnAoIXlI1RlTYUEES0rZCr8al6fWXbjan2XS4pre/9YkNhm5KsqPbVMpuZ5FT2wbIxdkXoI5XknBKeLU8XzZ/zBBxmAaXJZWpWKu0zIlgsDpW142MDkq1uTUnhIXUXb+O0s2eAbQb0aSxv6sgSkC7vTT58lwPf19MKm+pS0mrF3nInNOnoNC6GGtZMbqIm+p/MOzax6pmCuI4w3EcHwsd1HjbwE1hPy9Fq+lCKf7T39UrE/0MLyk86ZNZ61g0hFlfco4xmPXFWb7Ltf3kHU72dHWq41LMzJrlcy11zl/N7m/OQ7ZYnkaqL6UgovvEA63/3pa1KHGSXqtFy5RrBCQI78r57LlXYU/w68xmqeRYOjAaczGz3WljKsj7IA8xV5rf9LjrxJR9tJLshwynHX5PSAsLJQZZ0kbRdye8yGwN/LG5w6GCmqM7gYeg7jUc0zp7g7hZjLAMhLBf/dSdkb0U09WWtkekj6coxW0IaAoKQjketbxZVrT3+0V9hPlR3Wvkblwt8a1uRRbEzSNtJ9vjxGgOjJOdGAgsUajOwOaTO3qZ0+X9tFSAk5UZRSzrwyDOef9KGiPxhmh2U26P8yeuC5F1Ek7tG9J9nrzaJyQjw1JN/SJMTZ3YHXNhE1Obt7o072cilXtXcLj2fCY+2OmkQ/7xCbw6gQMthryekvt0+QTTErlYgwpsQcmnHODNQWF4qJxMS2UQCDn8iiaupRtfN94vxHN78F4W9KKoARlgNwIQc5WIjemClFLbi6OZ0CwU+KtZLE9D6OI3XevbHLJ0KTqwcjA+7LW1+C44WEMDSSn31j9xkjVfVKxgl8T227Q5Wdjh4OMFHQbMo5pyuQSDIKAbYsuox6SxfcipKjE5oS0sANyqxMtgVPXVu6WpibnilCLMFSLFqzuzYPK4F3jcqgTMPNFgCD+hQMUjvC
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2020 17:24:19.2877 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c5b8729-aef5-4928-e1ef-08d89df997e6
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ouBJCM8voNrj7leMYF/SamF1LCbd87YoKITgg5c60mnCRwKiOTIOEjhv3syulcyvtiL0b9xtknxyMooX2bweLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR06MB7298
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LvRzxUeFwzNe9bFTtToSWtAEJM8>
Subject: Re: [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: Fri, 11 Dec 2020 17:24:26 -0000

On 12/11/20 7:48 AM, Alessandro Vesely wrote:
> On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote:
>> On 12/9/20 10:28 PM, seth wrote:
>>> As an individual, I feel extremely strongly that failure reports should go away in their entirety. Although Jesse Thompson has outlined a use case that really has no other good solution, and is equally true in other large complicated organizations.
>>
>> To be clear, I'm not advocating for this From/To use case, but I know of universities who would.  There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email.  That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF.  It's a stretch in my mind.
> 
> 
> I'm not clear whether you're talking about sending or receiving reports.  Received: chains are key for evaluating addresses to add to SPF records.  I don't think it makes sense to specify their omission from 

Only the last hop from the receiver's viewpoint is really needed for a domain owner to assess gaps in SPF.  That's already addressed with aggregate reports.  What's missing is the additional context that the failure reports are intended to provide, to help domain owners determine if the IP address which sent the message was legitimate.  Of course, received chains are helpful for troubleshooting.  There's no "right" answer regarding the balance of useful information vs privacy, so I'm suggesting that we put things like this on a spectrum of usefulness/privacy-concerning. 


> My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows:
> 
> * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf,
> 
> * the software they use doesn't have an option to redact PII, or (unlikely)
> 
> * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days.

If sending only a limited amount of information is considered an acceptable alternative to full/unredacted information, it might help encourage these organizations to send failure reports, perhaps?


>> I would only strongly advocate for seeing the unredacted From header, since my primary concern was with identifying a little bit more information about who was using the domain and why (i.e. who is using random ESP).
> 
> 
> Agreed.
> 
> 
>> The stated purpose of Failure Reports is "for quickly notifying the Domain Owners when there is an authentication failure ... also provide more information about the failed message than is available in an aggregate report".  Since the focus of DMARC is to authorize the use of the domain used in the From header, then the logical next incremental levels of "more information" should be:
>>
>> 1) From header domain (already known)
>> 2) local part of From address
>> 3) Friendly From
>> 4) Subject
>> 5) other parts of the message containing identifiable information
>>
>> 1->5 decreases in usefulness/relevancy to DMARC
>> 1->5 increases in unnecessary information disclosure
> 
> 
> The mail filter I do sends aggregate reports but not failure reports.  Should I add it?  I'm thinking I could frame it like so:
> 
> * Have a global flag to enable or disable ruf's, which can be overridden on a per-domain basis.  Default to disabled.
> 
> * The flag can specify three confidentiality levels:
>   - full message
>   - header only
>   - header only + redact.
> 
> * Redacting the header would work as follows:
>   1. Collect recipients addresses in To:, Cc:, and envelope,
>   2. compute the rfc6590-redacted version of each address,
>   3. for all fields, replace any occurrence with the redacted version.
> 
> * Reports are left in a user-configured directory, assuming that a user supplied script deals with them.
> 
> Does that make sense?
> 
> Should dmarc-failure-reporting include text with practical suggestions along those lines?

Does this redaction logic apply to the From header too?  If so, I would recommend adding a fourth confidentiality flag for reporters who want to redact recipient information but leave the From header unredacted to better aid the domain owner in tracking down the sender.

Jesse