[dmarc-ietf] Spam Filtering Product Guidelines?

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Fri, 22 March 2019 15:11 UTC

Return-Path: <btv1==9847b0ea73a==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 16C7F130F97 for <dmarc@ietfa.amsl.com>; Fri, 22 Mar 2019 08:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 Z6ubPg8GXXYP for <dmarc@ietfa.amsl.com>; Fri, 22 Mar 2019 08:11:02 -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 CB3FF131051 for <dmarc@ietf.org>; Fri, 22 Mar 2019 08:11:01 -0700 (PDT)
X-ASG-Debug-ID: 1553267457-0990574becc7660001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id rt43j3P6vdEN2EJh (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Fri, 22 Mar 2019 11:10:57 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-ASG-Whitelist: Client
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=4SzT0nOsIt3maPRsxwn74jo9sLd47D3kc5XOqt3Qv80=; b=BlFrJNFc8AI5T1afVxqkwTmGusH/K+sYSQ1tkL9qG5ofBZJAEiW53mZUzcq+vguS3 i0mPWRfvonguyt+OiKpc5KhEnZqQFgxu0d+dmf9NKxJcToKEnbyIRwa2zp8ZRZVKQ 2iwQ14bVufdt4UHfL5doCpuE1fdicNR+Aulodg1zQ=
Received: by webmail.bayviewphysicians.com via HTTP; Fri, 22 Mar 2019 11:10:50 -0400
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: <dmarc@ietf.org>
Date: Fri, 22 Mar 2019 11:10:50 -0400
X-ASG-Orig-Subj: Spam Filtering Product Guidelines?
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <15a60f8319ed4e09948e6969af7b3a38@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=84c230c1fed142789e6bed536ff77a1b
X-Originating-IP: [192.168.26.116]
X-Exim-Id: 15a60f8319ed4e09948e6969af7b3a38
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1553267457
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: 1540
X-Barracuda-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wHzgElkC3Od03z0YAHtNlbB5bEs>
Subject: [dmarc-ietf] Spam Filtering Product Guidelines?
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, 22 Mar 2019 15:12:25 -0000

Based on my frustration with observed product offerings, it feels like no 
one has articulated a reference model of how spam filters should operate -- 
either that, or the vendors are just ignoring such work.
  
 The SPF / DKIM / DMARC standards define what senders should do, but I 
don't think it says much anything about what the receiving system should do 
to resolve ambiguity when these features are not fully implemented by the 
sender.
  
 Does this group know of prior work to define such a reference model?
  
 Doug Foster