Am 15.10.2008 15:20 Uhr, Tim Mancour schrieb: > Sam, > > There is a set of POSIX compatible regular expression functions available in > "C". The functions regcomp() and regexec() are both used by qmail to provide > regexp testing for the control/badxxxxx files.
I jusrt wrote a similar mail, as I was wondering why NOT to use regexes in spamdyke, my only idea was that it could hurt performance. There is the PCRE library which enable parsing of perl compatible regular expressions, which have IMHO the cleanest and most widely used regex syntax. It's also very easy to test those regexes using perl. > > Regards, > Tim -- Felix > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam Clippinger > Sent: Wednesday, October 15, 2008 12:57 AM > To: spamdyke users > Subject: Re: [spamdyke-users] spamdyke +ip-in-rdns-keyword-blacklist-entry > option > > The kind of wildcards you're asking for (especially "*.*") would not be easy > to implement. However, the code that requires a keyword to be surrounded by > non-alphanumeric characters could be easily removed if you want to test the > results. In filter.c, just remove the if() block from lines 697 to 706 (in > version 4.0.5). Rerun "make" and install the new binary. My instinct says > you won't like the new behavior but I could easily be wrong. > > In the long run, the best solution is probably to add support for regular > expressions. They're much more flexible and powerful and the documentation > would be much simpler as well, since many tutorials already exist for > regexps. Several people have asked for regular expression support and it's > on my list (though it's not high priority at the moment). > > -- Sam Clippinger > > Youri V. Kravatsky wrote: >> Hello Sam, >> >> >>> BTW, spamdyke won't find a keyword like "dyn" in the middle of other >>> text like "dynamic". In order to match, a keyword must (1) be at the >>> beginning of the name, (2) be surrounded with non-alphanumeric >>> characters (i.e. dots or dashes) AND include the rDNS name's TLD (e.g. >>> "example" would not be found in "11.22.33.44.example.com") or (3) the >>> keyword must begin with a dot AND match the entire end of the rDNS >>> name (e.g. ".example.com" would match "11.22.33.44.example.com"). >>> This logic exists to prevent a keyword like "dynamic" from matching >>> "11.22.33.44.notdynamic.example.com". >>> >> Well, it is not good really, I know that correctly work on wildcards >> is not easy work in C, unlike, perl, but it would be very good to use >> file like >> .*dynamic.* >> .dynamic*.* > >> .broadband*.* > >> .*broadband.* > >> .*cable.* > >> .cable*.* > >> .*pppoe.* > >> .pppoe*.* >> Or else we will read log for a full days to find out all possible >> home-dynamic-cable-broadband providers all over the world... >> _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
