Re: [PATCH] generic spam detection
* On 2004.07.14, in <20040714053853.GA55151@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
* "TAKAHASHI Tamotsu" <ttakah@xxxxxxxxxxxxxxxxx> wrote:
>
> Okay, I wrote a bogus patch against hcache19. (attached.)
> (Of cource, sizeof(int) should be too short for spam/nospam IDs.
> Moreover, I'm not sure whether it works as expected. :)
I can't comment, since I don't use header caching -- I'll leave this to
you and Thomas Gl. :)
> Well, the reason why I thought null-$spam_separator was just to
> concatenate templates was that I hoped so; I wanted to set:
> spam foo f
> spam bar b
> to show "fbbbfb" in index_format(%H), for example.
> This is useful for narrow screen. Just FYI.
Useful, indeed. In case it's not apparent, you can do this by setting
$spam_separator to "". The override behavior is only when it's
completely unset.
I think that "" should not be the default, but I'm split evenly on
whether it should be unset or "," (or the like).
> As Dave said, some of us would need unspam/unnospam for folder-hook.
It's surprising to me that anyone would want to folder-hook these --
my original thought was that spam patterns would remain the same for
all folders, and it seems strange that one folder might use different
external spam engines than another. But perhaps this is for a non-spam
application of the functionality. More below.
* On 2004.07.12, in <20040712184628.GF14973@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
* "Thomas Roessler" <roessler@xxxxxxxxxxxxxxxxxx> wrote:
>
> It would be consistent with behavior of other list management
> functions in mutt if spam would go through the nospam list and
> remove a possibly identical regular expression (in addition to
> "spamming" something), and if "nospam" would go through the spam
> list and remove anything matching from that one.
Agreed. This is doable, and I'm willing to extend the patch to cover
this. It shouldn't be hard.
> That said, I'm wondering if the spam/nospam stuff shouldn't reuse
> the current hook framework; we'd then have "unhook" as a
> coarse-grained mechanism to clean up the situation.
>
> spam-hook, ham-hook?
Hmm, I hadn't considered that.
The hook framework would need to be extended to handle backreferences,
I think, but this seems like it would work. It has the advantage you
mention, but I think it still requires a new datatype (e.g. spam_list_t)
to map the hook pattern to a spam tag template, and most of the
functionality in parse_spam_list() would be duplicated anyway inside
mutt_parse_hook(). It seems like the primary advantage of changing
it would be in the extent to which it makes the user experience
more consistent. But it's not clear to me whether it would be more
connsistent, particularly. I wonder what others think of this.
--
-D. dgc@xxxxxxxxxxxx NSIT::ENSS