R. Scott Perry wrote:
When they were added, they were rarely used, and the extra processing wasn't much of a consideration, and ensured that there would not be any unwelcome side-effects (for example, reverse DNS lookups would be skipped, preventing the %REVDNS% variable from working).
FYI, I'm using this to whitelist my customers that are behind a static IP. This will probably save me about 3% to 5% of my Declude processing demands with PREWHITELIST ON (if I understand that correctly). Before such an impact didn't matter, but I've got so many custom filters that every little bit matters. It's true though that most of your customers probably use this improperly.
Why would we want to have to start coding this information into our individual filters?
That's up to you.
One reason is that it allows more flexibility -- anything that a filter can filter on can now be used for a whitelist. Another reason is that it helps reduce CPU time by ensuring that other filters will not be run.
OK, I occurs to me that I was misunderstanding the functionality that you and Kami were in agreement on. This does make sense, though it will probably be misused just as often if not more than the Global.cfg whitelist. No reason to punish those that understand how best to use the functionality though.
I need to give things a second thought before responding when both you and Kami agree on something and I don't :)
Matt
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
