That will do! I've created a batch file in which I'll put my snfclient commands and my dated documentation/rationale for those, but I'll keep using the standard GBUdbIgnoreList.txt for documenting my gateways. I'll also suggest that in the online documentation, that a link in the GBU section goes back to the SNFClient section so that it's easier for an admin to find the right syntax for using the client to manipulate the GBUdb, e.g. http://www.armresearch.com/support/articles/technology/GBUdb/index.jsp perhaps directly here on on the Maintenance page that shows how to use the ignore parameter, a link would go back to: http://www.armresearch.com/support/articles/software/snfClient/commandLi ne.jsp which is where the detailed command line documentation is listed. And although it rarely comes up as a support issue, I'll also suggest that the quick help for SNFclient could be clarified. It currently is this: To update GBUdb records use: SNFClient.exe -set <IP4Address> <flag> <bad> <good> and my suggested easier-to-read version is this: To update GBUdb records use: SNFClient.exe -set <IP4Address> <good|bad|ignore|ugly|-> <badcount|-> <goodcount|-> Andrew.
________________________________ From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Thursday, April 30, 2009 1:14 PM To: Message Sniffer Community Subject: [sniffer] Re: overriding the GBUdb Colbeck, Andrew wrote: I recently used snfclient.exe to "whitelist" the IP address (actually a whole /24) of a mailing list manager that my users deem to be trustworthy. snfclient.exe -set 64.62.197.53 good - - You might argue the merits of this IP address, but that's not why I'm writing... I deliberately left alone the last two parameters, so as to not disturb the counts, given that I'm "whitelisting" by forcing the "good" flag. I assume that this does not affect the GBU community at all, because it's the good and bad counts that are shared, not the flag. Is this correct? That is correct. Does the ARMResearch support notice when an administrator does this, and research whether the findings are good? No. We wouldn't know how to evaluate that anyway-- each system has it's own policies. GBUdb traffic consists only of good/bad counts at specific intervals. If the IP is not "ugly" it doesn't get evaluated in this way so we stop seeing data about that IP from that system. The "Bad count" and "Good count" I see when I do a: snfclient.exe -test 64.62.197.53 are results only on my own server, and not the GBU community. Is this correct? They were built up using primarily data from your server with some hinting from "the cloud". The cloud's influence is diminished significantly as your system gains experience with a particular IP. I assume that condensation affects the counts, and not the flag. So I will only lose this "good" flag if the GBUdb is dumped (or I build a new server). Is this correct? If you wipe out your GBUdb data then it will be gone. Flags other than "ugly" are preserved in GBUdb. If you buid a new server and you want to preserve your GBUdb data then you can copy the .gbx file to the new server before you start it. The .gbx file is a binary snap-shot of your GBUdb data. By default it is created about once per hour so that your SNF node does not have to start learning again from scratch if it is abruptly restarted. Please let us know if you have other questions. Best, _M
