Would anyone be awfully upset if I removed the DNS blacklist based
spam checking for the time being? I want to try and pluginize the
various spam detectors so that it’s easier to configure the sort of
thing you want (and probably to configure the default published state,
etc).
The problem I have with the RBL stuff is that DNS lookups can take an
age, and we’re really not remotely threadsafe at this point, so it’s
not something that can really be backgrounded that effectively.
Once I’ve got the plugin approach sorted, it shouldn’t be too hard to
add RBL checking back in or to write a spit CAPTCHA system.
On Oct 19, 2006, at 4:34 AM, Piers C. wrote:
Would anyone be awfully upset if I removed the DNS blacklist based
spam checking for the time being? I want to try and pluginize the
various spam detectors so that it’s easier to configure the sort of
thing you want (and probably to configure the default published state,
etc).
I’d say don’t break what’s working until you have a replacement that
works at least as well. That’s what SVN branches are for.
The problem I have with the RBL stuff is that DNS lookups can take an
age, and we’re really not remotely threadsafe at this point, so it’s
not something that can really be backgrounded that effectively.
Have you looked into using BackgrounDRb to do run the long tasks?
You could easily run a worker to do the DNS lookup and complete the
posting in a separate process. That might be good to incorporate
into the Akismet check too, since that can take a long time as well.
Once I’ve got the plugin approach sorted, it shouldn’t be too hard to
add RBL checking back in or to write a spit CAPTCHA system.
KittenAuth! http://www.kittenauth.com/
–
Josh S.
http://blog.hasmanythrough.com
Josh S. [email protected] writes:
The problem I have with the RBL stuff is that DNS lookups can take an
age, and we’re really not remotely threadsafe at this point, so it’s
not something that can really be backgrounded that effectively.
Have you looked into using BackgrounDRb to do run the long tasks?
The problem with that is that hosting companies are generally not
overly keen on long running processes that aren’t fcgi processes. At
least, mine isn’t and, as I’m sure you all realise, that’s what’s
important.
I suppose one approach is to trigger spam classification as an admin
action and just any new messages into an authorization queue.
You could easily run a worker to do the DNS lookup and complete the
posting in a separate process. That might be good to incorporate
into the Akismet check too, since that can take a long time as well.
Once I’ve got the plugin approach sorted, it shouldn’t be too hard to
add RBL checking back in or to write a spit CAPTCHA system.
KittenAuth! http://www.kittenauth.com/
Evil!
“Scott L.” [email protected] writes:
It wouldn’t bother me in the slightest. IMHO, most of the Typo spam
filtering code is kind of nasty right now, but I didn’t want to make
big changes right before 4.0 came out. Go for it.
Good oh.
I’ve been working on fixing our Trac problem, but work has completely
eaten the last week of my life. Hopefully I’ll be able to make more
progress in the next few days.
Cool.
It wouldn’t bother me in the slightest. IMHO, most of the Typo spam
filtering code is kind of nasty right now, but I didn’t want to make
big changes right before 4.0 came out. Go for it.
I’ve been working on fixing our Trac problem, but work has completely
eaten the last week of my life. Hopefully I’ll be able to make more
progress in the next few days.
Scott