From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/49558 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: new spam.el functionality Date: Thu, 23 Jan 2003 23:33:14 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: owner-ding@hpc.uh.edu Message-ID: References: <4nn0lrepl4.fsf@lockgroove.bwh.harvard.edu> <87u1fzh3zf.fsf@eris.void.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1043382499 4949 80.91.224.249 (24 Jan 2003 04:28:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2003 04:28:19 +0000 (UTC) Cc: ding@hpc.uh.edu Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18bvRx-0001HR-00 for ; Fri, 24 Jan 2003 05:28:17 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18bvQn-0004ni-00; Thu, 23 Jan 2003 22:27:05 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 23 Jan 2003 22:28:02 -0600 (CST) Original-Received: from ns3.beld.net (ns3.beld.net [208.229.215.83]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id WAA04152 for ; Thu, 23 Jan 2003 22:27:51 -0600 (CST) Original-Received: from heechee.beld.net (dhcp-0-30-bd-1-93-b2.cpe.beld.net [24.233.67.156]) by ns3.beld.net (Postfix) with ESMTP id E0A803B847; Thu, 23 Jan 2003 23:26:48 -0500 (EST) Original-To: Raja R Harinath X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: Raja R Harinath , ding@hpc.uh.edu In-Reply-To: (Raja R Harinath's message of "Thu, 23 Jan 2003 21:23:36 -0600") User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:49558 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:49558 On Thu, 23 Jan 2003, harinath@cs.umn.edu wrote: > Andreas Fuchs writes: >> Hm, isn't whitelist and blacklist functionality a subset of the >> regex matching functionality? Could these three be merged easily? > > Also applies to spam-check-bogofilter-headers. spam-check-bogofilter-headers uses (message-fetch-field spam-bogofilter-header), then extracts the spamicity score. spam-check-blacklist (whitelists are similar) uses (message-fetch-field "from"), and stores its regular expressions in a file. It's intended for large numbers of entries in the blacklist. spam-check-regex-headers does a re-search-forward call on the message. I think those are three pretty different functions. At best, you can come up with an improved message-fetch-field. But maybe I'm misunderstanding. I'm not sure what you and Andreas are proposing: a merging of the user interface variables, or a simplification of the code? I am against merging of the user interface variables. Users want a Bogofilter header check, not Lisp code. I don't think anyone would prefer to add "^X-Bogosity: Yes.*spamicity=\\([0-9]+\\)" to the spam-spam-regex-headers, to setting spam-use-bogofilter-headers to t. If they want, they can do it, but spam.el is intended to be simple and easy to use and configure. Does anyone disagree with this? Simplification of the code is a good goal, but sometimes it's not necessary. Can you produce code or a patch that shows how you would like to abstract spam-check-bogofilter-headers, spam-check-blacklist, and spam-check-regex-headers into one function? Ted p.s. should spam-*-regex-headers be "regexp-headers" instead of "regex-headers"? p.p.s. should it be just "regexp" instead of "regexp-headers", since it does a match on whatever is available in the article buffer while splitting? spam-check-regex-headers is intended for headers, but could be used on the body.