> I've already got the database open, so I'd rather keep all the relative
> info there.
You also have the DNS available, and I suspect that it might be quicker
(actually, if I correctly recall my benchmarks from before, forget the
"might" part).
> And actually, in the back of my mind, I've been thinking about how to
> make these personal blacklists sharable... kinda a napster-blacklist.
DNS RBLs are sharable (obviously).
> But anyway, what it did lead me to was the idea of having the blacklist
> matcher point at the *message store*. As spam fills my spam folder,
> when it was something I wanted to blacklist, I would copy it from my
> spam store to my blacklist store. Then the matcher would look for any
> messages from the sending IP address in this blacklist store
Major performance issue. However, a service could periodically poll a
message store, and populate a block list.
That sort of service could resolve some other issues, e.g., another
derivation of the same abstract service could periodically poll a
"reprocess" folder, and insert those messages back into the queue. Take a
look at FetchScheduler, and perhaps abstract from there.
> This also preserves the evidence for why I blacklist them.
Maintaining the spam/evidence database is certainly worth doing. But for
publishing the block list, itself, I would suggest the DNS RBL approach.
FWIW, we can fairly easily integrate block listing into the fast-fail code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
