IETF Logo Mail Archive

Re: [dmarc-ietf] Spam Filtering Product Guidelines?

Elizabeth Zwicky <zwicky@otoh.org> Fri, 22 March 2019 16:09 UTC

Return-Path: <zwicky@otoh.org>
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 F1BD4131156 for <dmarc@ietfa.amsl.com>; Fri, 22 Mar 2019 09:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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=otoh.org
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 g-au9FNEd64w for <dmarc@ietfa.amsl.com>; Fri, 22 Mar 2019 09:09:07 -0700 (PDT)
Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9652B13115A for <dmarc@ietf.org>; Fri, 22 Mar 2019 09:09:07 -0700 (PDT)
Received: from [172.132.14.231] (unknown [209.131.62.183]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id 5E79C1151F; Fri, 22 Mar 2019 16:09:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1553270946; r=y; bh=kopmBMrdd+5MMBi9KrH6RiBUtFyMojUnNxVrO5Cln1w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20[dmarc-ietf]=20Spam=20Filtering=20Product=20Guid elines?|From:=20Elizabeth=20Zwicky=20<zwicky@otoh.org>|In-Reply-To :=20<15a60f8319ed4e09948e6969af7b3a38@bayviewphysicians.com>|Date: =20Fri,=2022=20Mar=202019=2009:09:05=20-0700|Cc:=20dmarc@ietf.org| References:=20<15a60f8319ed4e09948e6969af7b3a38@bayviewphysicians. com>|To:=20fosterd@bayviewphysicians.com; b=wUaTOGIrWb3eWZ/ee7Z/7Kw91e+ZKUtmnnSFBtWciMDAy7x+oqEBIfhng3lamGXUI gkHmx1S3bweBTqazx/P3hXvH2cOWCupeZbY/7ZKIuOAoNmdBocETPBp5cJrTVfYJpt OkG7Bd5OnxSplQLBLSebhE8rov+NvbeoUzCVG/PQ=
Content-Type: multipart/alternative; boundary="Apple-Mail-37B1258B-6AA0-48C8-BEC6-8BFBB55B070D"
Mime-Version: 1.0 (1.0)
From: Elizabeth Zwicky <zwicky@otoh.org>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <15a60f8319ed4e09948e6969af7b3a38@bayviewphysicians.com>
Date: Fri, 22 Mar 2019 09:09:05 -0700
Cc: dmarc@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <A817C8EB-02AA-47AA-B719-BAA438F6C182@otoh.org>
References: <15a60f8319ed4e09948e6969af7b3a38@bayviewphysicians.com>
To: fosterd@bayviewphysicians.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/u_YHij8_DatkrL8XhwHCMS2moU0>
Subject: Re: [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 16:09:10 -0000

I’m not sure you realize that spam authenticates at a higher rate than good mail. This isn’t a bad thing — it helps in blocking — but it means that authentication is nearly orthogonal to spam filtering in large systems. 

Elizabeth 

> On Mar 22, 2019, at 8:10 AM, Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
> 
> 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
>  
>  
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

v2.23.0 | Report a Bug | By Email