-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Kelsey Cummings writes: > On Tue, Oct 05, 2004 at 05:05:18PM -0700, Justin Mason wrote: > > Kelsey Cummings writes: > > > On Tue, Oct 05, 2004 at 03:25:55AM -0700, Jeff Chan wrote: > > > > > 4. SURBL query traffic > > > > > > > > > mostly good if you subtract the blacklisted ones > > > > > > > > But any big, as-yet-undetected spam domains can also generate > > > > much traffic. > > > > > > What if you were to have a friendly ISP that would be willing to send you > > > an anonymized data feed that looked something like: > > > > > > sa score<tab>spam/ham<tab>url<tab>url<tab>url....\n > > > > > > It wouldn't be very hard to send this information in realtime. > > > > funnily enough, I have some IPC::DirQueue code to do this in > > a low-impact, low-load manner ;) > > I was actually thinking the easiest way to pass this data in realtime would > be to send it to surbl's colo at sonic via syslog. SA can already > generate it and syslogd can write to a named pipe for processing. Makes > it easy to get running. well, that's true! didn't think of that. > But, IPC::DirQueue is useful. Taking a queue from it I rewrote all of my > spam processing stuff to operate as a Maildir client. A single thread has > proven to be fast enough and alot better than passing to each processing > bit via procmail. If I find that it needs more than one processing thread > to keep up I'll probably go steal lots of your code. :-p that's the thing -- it's designed so that if you need more threads, just start more processes. you don't even need to synchronize them externally, it does it itself! (ps: did you notice I put up a version that does the hashing thing you suggested?) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBYzs1QTcbUG5Y7woRAodqAJ98/Q7IfuXdGpY2s+GKzzXjr4mmjgCfUa45 QnSi8VGgTtczz4IgubtH+gs= =xqNK -----END PGP SIGNATURE-----
