> - Introduces support for URIBL services that may not have worked right, at > least out of the box, before. Defines the subtle differences between > various known URIBL services in order to maximize compatibility.
Is it worth pulling some of this config out of the code and putting it into some sort of config file? > - Uses Net::DNS::Async to simplify the code, and also to ensure the > afore-mentioned A and NS lookups will prompt new URIBL lookups in an > efficient and simple manner via callbacks Does the code still work with the async qpsmtpd cores? > Attached also is tld_lists.pl, a companion file that needs to be dropped > in lib/Qpsmtpd/ which provides the list of first, second, and third level > TLDs that we care about. It's derived from our URIBL datafeed as well as Do the owners of that data care about it being used this way? You may be violating any agreement with them. Would they be ok if this was released as an independent CPAN module? Either way, can we structure this as an API instead of just an include file? > There are some disadvantages to this code. MIME::Parser is probably heavy > in terms of resource usage compared to just scanning the message body > line-by-line. This would probably not be that difficult to revert again > if desired, although I think the advantages of M::P outweigh the > disadvantages. It would be cool if it was configurable (i.e. use MIME::Parser or not.) > code, etc. At any rate, I've worked hard on this code and am thankful to > Devin and the rest of the QP contributors for the starting point, so I > hope that someone manages to find this useful and perhaps massage it into > upstream :) I don't have time to test or massage it, but the uribl plugin is quite important, so if someone is willing to test, benchmark, and massage, it would be cool to get a "more powerful" version into core. -R
