Re: [dmarc-ietf] non-mailing list use case for differing header domains

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Wed, 29 July 2020 21:00 UTC

Return-Path: <btv1==479f6ff1cdf==fosterd@bayviewphysicians.com>
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 5418D3A0DEF for <dmarc@ietfa.amsl.com>; Wed, 29 Jul 2020 14:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=bayviewphysicians.com
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 F2jA0tPi9qDM for <dmarc@ietfa.amsl.com>; Wed, 29 Jul 2020 14:00:54 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC083A0DC6 for <dmarc@ietf.org>; Wed, 29 Jul 2020 14:00:54 -0700 (PDT)
X-ASG-Debug-ID: 1596056452-11fa3118c76bb90001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id kYvPAVvTPTuEgLS9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Wed, 29 Jul 2020 17:00:52 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=CQFMbUFGdmzcVk0gzuwys6SWyaU/MfbCYSJRy5nRs0c=; b=QH26F9oQ9ok3lDPdOkKsqItseSB1ZlNQqD9tz6KKJhptVctVvj1IhAd41fNbisJGP l3rq4unuyGcKhCtagyJSuQOwf9xtL0I+c5YFvCy6K+1rTVkZlpYZm2WAHa+J3BXCb a2+H+0Uy/TVL/7l3s/Yjj7NTwVrKKnYDZMTRycikI=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: IETF DMARC WG <dmarc@ietf.org>
Date: Wed, 29 Jul 2020 21:00:45 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <e290d28b91c74346bb89fd968910d877@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="7136fd3e9e9749eca778740aaf9db759"
In-Reply-To: <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com>
References: <BY5PR13MB29998094418C8A6C25902569D7730@BY5PR13MB2999.namprd13.prod.outlook.com> <20200728173716.068CB1D9840C@ary.qy> <CAHej_8na3MLm1i4AZzgbL=7EZ7QBX8OvSB4BOqHg-1osBc4H_w@mail.gmail.com> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> <CAHej_8mztD91jeSA3S=ypdJO7B+9AhM+2ox=mhWOfz--3b0Aog@mail.gmail.com> <bd438562-b4-3ce-c731-75db0267eef@taugh.com> <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com>
X-Exim-Id: e290d28b91c74346bb89fd968910d877
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1596056452
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 4477
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83554 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/7jEoiINdL_YQeODG8s5IZJCEVxo>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
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, 29 Jul 2020 21:00:56 -0000

On the issue of spoofing, only two security postures are possible in the incoming mail gateway:
We allow spoofing by default, then block problematic spoofing as detected, on a case-by-case basis.We disallow spoofing by default, then allow desired mail as needed, on a case-by-case basis.
Only the second security posture is credible in a security audit.   DMARC v1 is the most effective tool for implementing that security posture.   The proposed "new" DMARC returns us to the first security posture.

Incoming email can be divided into these categories:
Messages that have confirmed identitiesMessages that appear to be spoofing but actually contain desired content from valued senders.Messages that appear to be spoofing and are unwanted.Messages where spoofing cannot be evaluated.
Security posture 2 will be associated with these policies:
Message category 1 will be allowed or blocked on other criteria.    In particular, confirmed identity allows preferred message handling to be implemented safely.Message category 2 will be handled through the receiving organization's exception process.   Message category 3 will always be blocked.    Message category 4 may be reviewed, as time permits, to determine a local policy which moves it into category 1 or 3. 
If there are category 2 problem cannot be solved between a recipient user and his email security team, we need to document when and why this is happening, 

However, the expectation is that senders in category 2 and 4 will have incentive to move into category 1 over time.   To the extent that this has not happened, it is a great misfortune.

An excess of category 2 messages can contribute to an organization choosing to delay or abandon implementation of security posture 2.   This increases their risk.   Indirectly, category 2 messages serve to facilitate the dirty work of category 3 messages, in exactly the same way that a large enough crowd can become an enabler for looters and arsonists.

DF