Re: [dmarc-ietf] About user notification in the MUA

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Sun, 07 June 2020 23:04 UTC

Return-Path: <btv1==427d487c9ec==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 6EF083A0437 for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 16:04:37 -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 7OrlFeAV8WaS for <dmarc@ietfa.amsl.com>; Sun, 7 Jun 2020 16:04:35 -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 BEB493A0433 for <dmarc@ietf.org>; Sun, 7 Jun 2020 16:04:35 -0700 (PDT)
X-ASG-Debug-ID: 1591571074-11fa313a1092990001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id yEBCqEwHUkG4Oci8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sun, 07 Jun 2020 19:04:34 -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=HIhxyOtKpJamZIbQMC7RoJlfMvFYcRuZHmzhYzgwSRY=; b=ahanevxa1ZS27/h96fFXDIocD5rEjIL4Diw64o05Uu50V4pTW8c6gWgYiQyplDI7m oixi/kllzpRsXU1qhtd8VmDyiOk4/APhLv8MjIRp9pjVpXTuK5EIi9jICNq6HOAEX dY3CZpfloXpUfgdsEZAF7j3Dv2PXnFGQA/DdOiP8o=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: dmarc@ietf.org
Date: Sun, 07 Jun 2020 23:04:24 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] About user notification in the MUA
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <dbcc34fb870e45b2b1cd3903b90b8a87@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="ff3927184ede40d09c8f36c0b003b1c8"
In-Reply-To: <fbbcc299-98f3-5d23-15e1-1f89fa03b9a7@gmail.com>
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com> <11640715.3lbasgNmsr@sk-desktop> <25420528-d356-0273-ceb3-c44a3c94bc91@gmail.com> <3138524.EPDo7oxCqE@sk-desktop> <4620e21f-32c5-7735-9faf-a5b045f84c0d@bluepopcorn.net> <ac0f684a-4c00-0564-8cf9-5b955e037c87@tana.it> <14fe18acad53467a8027e680dfc1067e@bayviewphysicians.com> <46e045ae-9691-4f5b-86bf-142c066458d8@www.fastmail.com> <fbbcc299-98f3-5d23-15e1-1f89fa03b9a7@gmail.com>
X-Exim-Id: dbcc34fb870e45b2b1cd3903b90b8a87
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1591571074
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: 5290
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.82398 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/aSZ5y8NfqwoPeBT-ZPkTRJ6mXY0>
Subject: Re: [dmarc-ietf] About user notification in the MUA
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: Sun, 07 Jun 2020 23:04:37 -0000

I am trying to play by the rules and not chase topics outside the one assigned, but since several have jumped on my comment, I will follow up briefly.

Dave Crocker wrote
Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing that any new such requirement will be useful.

Every email filtering product that I have examined has provided a user-signaling system, using one or more of the following:
tagging the subject, adding text as a body header or body footerconverting the suspect message into an attachment of  a replacement message,soft-quarantining, where the user has unrestricted control to release the message from quarantine.
Given that market reality, I conclude that most vendors and their customers believe that user-signalling is useful.   The signalling system does not have to prevent every mistake for the signal to be useful.

The problem with all current notification methods is that they are relatively primitive, often communicating nothing substantive about the suspicious message characteristics.  They also work against other security mechanisms.   
Any form of tagging breaks DKIM signatures, reducing the credibility of the message if it is auto-forwarded for any reason.   

The tagging also becomes tattooed to the message and its replies, rather than being restricted to the trust domain that assigned the tag.   One example should suffice:  a message was tagged with [SPAM?] because the sender had an error in his SPF record and I was trying to enforce SPF.   Then when my staff replied, the originator treated the reply as spam because the word SPAM was still in the subject line when he received it!   
We need a user notification mechanism that is local to the trust domain and does not break DKIM signatures.  You have already done the heavy lifting for this interoperability problem with Authentication-Results and ARC   I am not expecting a "Standard" that requires every implementation to notify every user in the same way.   I am looking for a guidance document that helps vendors to deliver products which permit an organization to implement a notification policy which they find to be effective and appropriate.   IETF is the right organization to take this on because the email filter, the mail system, and the multiple MUAs are almost always a multi-vendor configuration.

df