Re: [dmarc-ietf] Domains and tree walk

Jesse Thompson <jesse.thompson@wisc.edu> Wed, 09 December 2020 21:34 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 4C0053A114C for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 13:34:23 -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 Hmq-mo5ZXiuy for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 13:34:21 -0800 (PST)
Received: from wmauth1.doit.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (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 A4B513A10F2 for <dmarc@ietf.org>; Wed, 9 Dec 2020 13:34:20 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QL300CTPD6K8340@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 09 Dec 2020 15:32:45 -0600 (CST)
X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU=
X-Spam-PmxInfo: Server=avs-1, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.12.9.212417, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.55.172]
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=crxuE+9IFZ5yeFrD31YJkymIhKXDfMx9GsGGzQbas5xq2MnGiQGvQaxCFSoE/fdTYFrakJQqD/+6ZA6XVogAtT8oZ/LWkck16c+DUYa2hB3St8lnXif/5boLX+lz0MJM72tbxIePyviRXRV4nOyqZalYV7nAMBy2JlVWcCXtu3OpGChFcz1LclVU4tFe8g7/N/8CJkBNqndGDAEhrZAuioBAruIeWzSnfmLGWdkcpGycG7/9P8jFduKwyPtYcza/g4R/nundLBBNK45oHj2rWlvbIfiqSNeYc9UmZOBvnPKGTL9JputM+pFTJa23XHXkea6SGdBYUHNZQ6eXajIKBQ==
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=e+wjVvcp3o0w2nGiW7mXIK8q3DK8X5DOV+RNRZjci3I=; b=fvaOx9Sx5o4/OJMG0oLNLSG/qpSWZIeJx+FC1UcPWcM4nBvyW/flBeQMTBRATggGRO/x0DiwmMzXIGaFabK4U/X5JnjvMoC8L7GgeEuVRMTueSND75rGlTyC/6Tszs1KnajK25aUSgqjOP5687Uo2lfb82ax9tlfFa+HWFb8hZzt4iWJirW0kNOPYQYvO4yOQ6Twfr6OABzzv7ocdpBTdYkclL8cXIkmlW6JI66lEr5u4ErsePaSBRquXBBfVNWo3tyb/Hlo+BXmLcrAK7sX9pTb/QH6RIO32twKyLa7oYdrDkHiVMQN84eRXcAoXYHze3nzgPEKK/Gi/iUlcYiz4g==
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=e+wjVvcp3o0w2nGiW7mXIK8q3DK8X5DOV+RNRZjci3I=; b=janxOWx6w+7NzPxGPilsE8rQmxne5REt9chzdNrsn6Y+Xf0doP3yDRBC6Ewye8TKrg7g+Ac8f9yCWwwN5197YNLYBk+/rAg1B16fF4ggdKvTkyV9hBTClgvQ3QUBBjO39oYkU2hF6fr4XrqaO76Rt/IZicMjtIjLT6ekU+IoMCE=
Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7622.namprd06.prod.outlook.com (2603:10b6:510:5e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 21:32:44 +0000
Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::51ec:c9cd:3511:1bcc%6]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 21:32:44 +0000
To: dmarc@ietf.org
References: <20201202025026.F16E128C5FDE@ary.qy>
From: Jesse Thompson <jesse.thompson@wisc.edu>
Message-id: <b54e5d04-a90b-8bae-9224-2c94409ef39d@wisc.edu>
Date: Wed, 9 Dec 2020 15:32:40 -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: <20201202025026.F16E128C5FDE@ary.qy>
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: 7bit
X-Originating-IP: [47.12.96.133]
X-ClientProxiedBy: CH2PR14CA0014.namprd14.prod.outlook.com (2603:10b6:610:60::24) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8)
MIME-version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.0.2.111] (47.12.96.133) by CH2PR14CA0014.namprd14.prod.outlook.com (2603:10b6:610:60::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 9 Dec 2020 21:32:43 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 33c9fa41-1b24-447e-78e9-08d89c89f708
X-MS-TrafficTypeDiagnostic: PH0PR06MB7622:
X-Microsoft-Antispam-PRVS: <PH0PR06MB762285D8B586C3232D1257FAF6CC0@PH0PR06MB7622.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: 2Rv5tlmjra6IG8lw5EZy2JMr+F3v9La+gQav8ZA9GZ9TPskxDsLrvFmiOK/kD+yaGm/nP5AGCI5mMtFKvYVrXnjIEnD0frl9jF4mUlrBDSwhfSiY0/3oSBJuouxC0YpFQ+Wm9Hj6Ke6RVRTNyDjMwar1Im5WauhKHitPw2Hki0OmvrLcB9LfV8soprlxTfzs0Y5lgyMEJmRLFXXCnNsz9Y1ezHAxcRk4rHRXMQ+FHdL9BMAL2Sy0hVXc7kMWCktab8e0/McspfipI/GLfizFGtNMZU19eUDCr/gHq8vr7bz0Gc89D4tqtDaPuoewzHV1rfp3jnGO3woK54vTOWQY81wV6VHmKKgRNM44mwqitApTOCftplPCkVFDfp+ulll7Q30pZ4WO2aRh0geRY5FXL4EWmQo/IMLxCLJnWQMttoM=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(8936002)(6916009)(86362001)(75432002)(44832011)(36756003)(5660300002)(2906002)(8676002)(508600001)(2616005)(956004)(31696002)(786003)(16576012)(83380400001)(53546011)(66556008)(6486002)(66946007)(66476007)(31686004)(186003)(16526019)(26005)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?QXQ3UGNmZ3Z0VmQrMUVSUjlCak4rMEk4ZDA4MWM0dC9hODhydUR4RnkreGFv?= =?utf-8?B?cE91Q0tjSEQ3Vi9PbTNUOE9yeEhnaEczMzBVSnJzM1A1NFJCbU9DZzhDblF6?= =?utf-8?B?amVlNlJ3YURxNnpDMWxaTnZZb3M3d3VuMnl3RFBhYisxOWpwaERuckRjbkhx?= =?utf-8?B?M3FqYUcxS2VMbUhkUUd5VWg3NVFVUjNwMWxkc1ZsbjgzUGhoUitPUEFMcWlW?= =?utf-8?B?R1NNYTcvc1R5OTJhalgxaE5BcVAyUGhxYUJQVFRGSlhDeWV1MkZhajArbUdY?= =?utf-8?B?bEk0a3FxakhReHMweStBTHB3MEQ5V1c2K0hOaUNZdjBhRll6emROZTNuUWdo?= =?utf-8?B?cnhscCsrVTlCR3NsQUF1dG5rd05WUU1JUVZxamZDWkhVb1E3U2NKVTFjbzB4?= =?utf-8?B?YkxpMHhzdlZmMmpzNm9ZNVhncUtFRFdlT29qQTI2YzhNM3p0TU5ZeXZLVTRx?= =?utf-8?B?RmFWUGNXQWl1M3pJamhBWkp4UHROME1CZ0lUcVlMUDM4MnpYanJ0dGZYdk4y?= =?utf-8?B?cWtBWVBlZnkvNGVzamx6YVhnUWlhWmFaY1VHaHRlU1llMlVFUVNMMUZLQXIr?= =?utf-8?B?M2NySnJmT3JRU0Y1RUNyK0h6SzlrQi9tYTR4ZW9Ya0N1dmdaZHN3QUVQeXR3?= =?utf-8?B?aVdKNjRzdlJVT0QxV2p2K1RKeTNGNVU1bTZ5L2dYOTg1VHNrc2dnRFdpclF0?= =?utf-8?B?aEV0Z2VUNEs1cFNWUnByRElvWXpMaVpxZENOVWhlQ1lEZkZZcVNlSW1yUXBQ?= =?utf-8?B?TWpYbHhST0dpanZ2aW5jN0Q1Vms3emVDQThrV3ZBM1RNMzVIVkZsR0ZwVm5V?= =?utf-8?B?VWNWOGVKMDlWdlN4YTlzMUhzY0QrSEhScnZwMWxvTXZSYjhhalp0N2JIUmx3?= =?utf-8?B?djduQng4ZGV3SzdjSGppUytHWHRwYXp5c0hGQUlVMmZnTjZ0S09ObzRuZjZJ?= =?utf-8?B?allERm5LdHYrSURERS9va0FNWVgrSkRMcU9SVnRvVThRNjY4aEE4OUU1S0J2?= =?utf-8?B?cG9XSG1YbGNpZm5PUXBjemdDYXJGNSt0eUhlMzJUMzB5Q0JiSzQzOFpvdXAz?= =?utf-8?B?TmdieStnOS9LMmN4ekpQdnpBUHpMRjErRHI0TG1nZjBVVlVBemVuckRoblJT?= =?utf-8?B?eXNPKzdWQUlpZlBuSHd6UmxoSTl1ZURNbGVVZUZKcG5ZZk80Q1NMbUVJcHpL?= =?utf-8?B?WWk2ajdJcU4zQmgzYjZiWE16OHJ1bTc3MFFyMERKdXBOSlNLYndMSzUyajJi?= =?utf-8?B?NjY4K3pBYTFIOWI1TnI3R1N4akZxRmMvWW4xREMyVDA3MzNrdDBTVkpPbW5v?= =?utf-8?Q?6x9WmvEEIk9eZrS4gm/XwdoIh89jhQ2J9I?=
X-OriginatorOrg: wisc.edu
X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2020 21:32:44.1327 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9
X-MS-Exchange-CrossTenant-Network-Message-Id: 33c9fa41-1b24-447e-78e9-08d89c89f708
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YcWa7Erq8e9Rs4pZqpJA8KCfaDCvZGaj7PjC8NYu+yOX8oPnlp6uSqBk7CuwYDtiHJJGD8XBku06szDQ/hrAEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7622
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/EC-kYTL4GJYT1tIwFc5vxLDyHaU>
Subject: Re: [dmarc-ietf] Domains and tree walk
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 21:34:23 -0000

On 12/1/20 8:50 PM, John Levine wrote:
> On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn,
> and Yale, whose situations are not altogether unlike Columbia's, all
> publish DMARC records. Closer to home so do NYU and CUNY. They all say
> p=none with rua= to collect reports. You might give them a buzz to see
> how it works for them.

The fact that Joseph is here raising valid deployment concerns shouldn't be overshadowed by an assumption that these other universities are ahead of the game.

I participated in a hi-ed cybersecurity committee to create an "email security maturity" rubric - basically just something that CISOs can use to reflect/compare to each other.  I advocated that publishing p=none and consuming the reports is a good first step, but just maturity level 1 (of 5).  

Some university cybersecurity organizations feel like publishing p=none (and, perhaps, not actually looking at the reports) puts them into "compliance" with this DMARC thing that only their email admins really grok. 

I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC reports).

For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains.  Now, *that* must have forced each agency to figure out how to actually deploy DMARC and deal with the implications.  I applaud the tenacity.


On 12/2/20 10:21 AM, Todd Herr wrote:
> This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk.

I agree with all of this.  As I mentioned above, I just question the assumption that seeing p=none in a DMARC record is a good indicator that the organization is actually doing all of the things you enumerate.

It's also pretty clear from my own experience that it's impossible for complex organizations to address all of their non-compliant sources of mail flow.  Eventually, you just need to draw a line in the sand and cause the mail from random campus servers and ESPs who use domains without authorization to be rejected (or quarantined, in our case).  


On 12/2/20 1:48 PM, superuser@gmail.com wrote:
> If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" only, then nothing stops me from generating unauthenticated email with a From field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or not it actually exists in the DNS.

I also advocated that sp=reject would be a sign of a high level of maturity.  I was in the minority and criticized for complicating the situation (only the flagship domain needs protection - said some).  Win some battles, lose some battles.

Regardless, I still feel like the tree walk is better than the org domain model since it would actually allow us to get to sp=reject.  With the org domain model, we'll probably be stuck at sp=none indefinitely.

Jesse