[sniffer] Re: IP Change on rulebase delivery system
Pete I thought the local gbudb got updates from the service or was that a future enhancement? > Original message > Subject: [sniffer] Re: IP Change on rulebase delivery system > From: Richard Stupek 'rstu...@gmail.com');>> > To: Message Sniffer Community 'cvml', 'sniffer@sortmonster.com');>> > CC: > > > Can you point me at the documentation for the truncate blacklist and its > usage? > > > On Thu, May 23, 2013 at 3:36 PM, Pete McNeil > 'madscient...@armresearch.com');> > > wrote: > >> On 2013-05-23 15:22, Richard Stupek wrote: >> >>> Looks like I have this issue again (pegging 4 core cpu) and resetting >>> the process doesn't make a difference. Not sure what is causing it but it >>> does slow down spam detection to 40-50 seconds for many emails. Any ideas >>> what I can look at or do to resolve this? >>> >> >> Check the message sizes. As part of the newest spam storms we've noticed >> that a lot of the messages are huge (65536++). I suspect this might impact >> throughput as large buffers are allocated and moved around to handle these >> messages. This kind of thing has also been known to cause NTFS to crawl. >> >> Please let us know what you find. >> >> If you are not already doing it -- you should consider blocking >> connections using the truncate blacklist. No sense taking on some of these >> messages if they can be eliminated up front. >> >> >> _M >> >> -- >> Pete McNeil >> Chief Scientist >> ARM Research Labs, LLC >> www.armresearch.com >> 866-770-1044 x7010 >> twitter/codedweller >> >> >> ##**##**# >> This message is sent to you because you are subscribed to >> the mailing list > 'sniffer@sortmonster.com');>>. >> This list is for discussing Message Sniffer, >> Anti-spam, Anti-Malware, and related email topics. >> For More information see http://www.armresearch.com >> To unsubscribe, E-mail to: > 'cvml', 'sniffer-...@sortmonster.com');> >> > >> To switch to the DIGEST mode, E-mail to >> > 'sniffer-dig...@sortmonster.com');> >> > >> To switch to the INDEX mode, E-mail to >> > 'sniffer-in...@sortmonster.com');> >> **> >> Send administrative queries to >> > 'sniffer-requ...@sortmonster.com');> >> > >> >> >
[sniffer] Re: IP Change on rulebase delivery system
Thanks for the info. Mine can speak XCI, its custom. On Thu, May 23, 2013 at 4:31 PM, Pete McNeil wrote: > On 2013-05-23 17:21, Richard Stupek wrote: > >> Would this: http://armresearch.com/**support/articles/software/** >> snfServer/xci/gbudb.jsp<http://armresearch.com/support/articles/software/snfServer/xci/gbudb.jsp>yield >> the same results as using the ip4 blocklist? >> > > No. Asking your local GBUdb about an IP will only give you a local > perspective. > > The truncate blacklist contains the currently active worst-of-the-worst as > seen by all SNF nodes working together. > > Also -- getting your MTA to pay attention to your local GBUdb is > nontrivial since no MTA software (that I know of) can "speak" XCI yet. > > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
Would this: http://armresearch.com/support/articles/software/snfServer/xci/gbudb.jsp yield the same results as using the ip4 blocklist? On Thu, May 23, 2013 at 4:11 PM, Pete McNeil wrote: > On 2013-05-23 16:41, Richard Stupek wrote: > >> Can you point me at the documentation for the truncate blacklist and its >> usage? >> > http://gbudb.com/truncate/**index.jsp<http://gbudb.com/truncate/index.jsp> > > It's an ordinary ip4 dnsbl. > > Most email systems have some mechanism for blocking connections based on > this kind of blacklist. > > Hope this helps, > > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
Can you point me at the documentation for the truncate blacklist and its usage? On Thu, May 23, 2013 at 3:36 PM, Pete McNeil wrote: > On 2013-05-23 15:22, Richard Stupek wrote: > >> Looks like I have this issue again (pegging 4 core cpu) and resetting the >> process doesn't make a difference. Not sure what is causing it but it does >> slow down spam detection to 40-50 seconds for many emails. Any ideas what >> I can look at or do to resolve this? >> > > Check the message sizes. As part of the newest spam storms we've noticed > that a lot of the messages are huge (65536++). I suspect this might impact > throughput as large buffers are allocated and moved around to handle these > messages. This kind of thing has also been known to cause NTFS to crawl. > > Please let us know what you find. > > If you are not already doing it -- you should consider blocking > connections using the truncate blacklist. No sense taking on some of these > messages if they can be eliminated up front. > > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
Looks like I have this issue again (pegging 4 core cpu) and resetting the process doesn't make a difference. Not sure what is causing it but it does slow down spam detection to 40-50 seconds for many emails. Any ideas what I can look at or do to resolve this? On Fri, Mar 29, 2013 at 12:27 PM, Pete McNeil wrote: > On 2013-03-29 12:59, Richard Stupek wrote: > >> well when all else fails restarting snf seems to have corrected the issue >> for now. >> > > In that case, it is likely that RAM fragmentation was involved. Dropping > the process allowed the fragmentation to be cleared. (theory). > > > Best, > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
well when all else fails restarting snf seems to have corrected the issue for now. On Thu, Mar 28, 2013 at 11:50 AM, Darin Cox wrote: > Richard, > > Do you have any directories with a large number of files (>4k)? We had a > similar problem a few months back with sniffer scans taking much longer to > complete and sniffer temporary files being left over. We finally traced > the performance issues to a frequently accessed directory with thousands of > files. We’ve also seen issues in the past with directories with a large > number of files being very poor performing. > > Darin. > > > *From:* Richard Stupek > *Sent:* Thursday, March 28, 2013 12:10 PM > *To:* Message Sniffer Community > *Subject:* [sniffer] Re: IP Change on rulebase delivery system > > Ok looking at the log I see quite a few messages taking over a second to > process (samples below): > > > > > > > > > > > r='Normal'/> > > > > > > > > > > > > > > > > > > > > > > r='Normal'/> > > > > > On Wed, Mar 27, 2013 at 4:42 PM, Pete McNeil > wrote: > >> On 2013-03-27 17:16, Richard Stupek wrote: >> >>> The spikes aren't as prolonged at the present. >>> >> >> Interesting. A short spike like that might be expected if the message was >> longer than usual, but on average SNF should be very light-weight. >> >> One thing you can check is the performance data in your logs. That will >> show how much time in cpu milleseconds it is taking for each scan and how >> long the scans are in bytes. This might shed some light. >> >> http://www.armresearch.com/**support/articles/software/** >> snfServer/logFiles/**activityLogs.jsp<http://www.armresearch.com/support/articles/software/snfServer/logFiles/activityLogs.jsp> >> >> Look for something like in each scan. >> >> >From the documentation: >> >> - Scan Performance Monitoring (performance='yes') >>> p:s = Setup time in milliseconds >>> p:t = Scan time in milliseconds >>> p:l = Scan length in bytes >>> p:d = Scan depth (peak evaluator count) >>> >>> >> Best, >> >> >> _M >> >> >> -- >> Pete McNeil >> Chief Scientist >> ARM Research Labs, LLC >> www.armresearch.com >> 866-770-1044 x7010 <866-770-1044%20x7010> >> twitter/codedweller >> >> >> ##**##**# >> This message is sent to you because you are subscribed to >> the mailing list . >> This list is for discussing Message Sniffer, >> Anti-spam, Anti-Malware, and related email topics. >> For More information see http://www.armresearch.com >> To unsubscribe, E-mail to: >> To switch to the DIGEST mode, E-mail to >> >> > >> To switch to the INDEX mode, E-mail to >> Send administrative queries to >> >> > >> >> >
[sniffer] Re: IP Change on rulebase delivery system
Ok looking at the log I see quite a few messages taking over a second to process (samples below): On Wed, Mar 27, 2013 at 4:42 PM, Pete McNeil wrote: > On 2013-03-27 17:16, Richard Stupek wrote: > >> The spikes aren't as prolonged at the present. >> > > Interesting. A short spike like that might be expected if the message was > longer than usual, but on average SNF should be very light-weight. > > One thing you can check is the performance data in your logs. That will > show how much time in cpu milleseconds it is taking for each scan and how > long the scans are in bytes. This might shed some light. > > http://www.armresearch.com/**support/articles/software/** > snfServer/logFiles/**activityLogs.jsp<http://www.armresearch.com/support/articles/software/snfServer/logFiles/activityLogs.jsp> > > Look for something like in each scan. > > From the documentation: > > - Scan Performance Monitoring (performance='yes') >> p:s = Setup time in milliseconds >> p:t = Scan time in milliseconds >> p:l = Scan length in bytes >> p:d = Scan depth (peak evaluator count) >> >> > Best, > > > _M > > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
It would be SNF routinely showing 80% utilization spikes for a 4 cpu system. I hadn't ever seen it do that before which was why I sent the message. Don't believe the load is any higher than normal. The spikes aren't as prolonged at the present. On Wed, Mar 27, 2013 at 4:08 PM, Pete McNeil wrote: > On 2013-03-27 16:49, Richard Stupek wrote: > >> Its odd because the number of messags snf is processing isn't more than >> usual and the % of spam being detected through snf is actually lower than >> typical yet is is routinely maxing out 4 processors at 100%. >> > > You're saying that SNF is maxing out 4 processors? ... or is the > combination of operations on your server maxing out 4 processors? > > We're using the same engine and ruelbase in our CGP server and humming > along nicely at between 2000 - 8000 msg/minute with nominal CPU loads. > > I don't see anything unusual in your telemetry and I haven't heard any > other complaints, so I can't explain why SNF would act differently on your > system. I hate a mystery though -- so I would love to get to the bottom of > it. > > Do you see anything else that might be causing the CPU load? > > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
Its odd because the number of messags snf is processing isn't more than usual and the % of spam being detected through snf is actually lower than typical yet is is routinely maxing out 4 processors at 100%. On Wed, Mar 27, 2013 at 3:20 PM, Pete McNeil wrote: > On 2013-03-27 14:38, Darin Cox wrote: > >> Probably unrelated... and due to a significant increase in spam over the >> past few days. >> > > I agree with that -- our inbound spamtrap pre-processor has seen 4x > increase over the past few days so that's likely to be related. > > Also, Richard, I took a quick look at your telemetry and verified that > your rulebase file(s) are up to date. > > Best, > > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: IP Change on rulebase delivery system
Not sure if its related but since yesterday SNFserver CPU utilization has been inordinately high (>50%) for the middle of the day with not any additional volume in mail being received. On Mon, Mar 25, 2013 at 9:13 AM, Pete McNeil wrote: > Hi Sniffer Folks, > > We are about to change the IP of the rulebase delivery system. This change > should be completely transparent and you should not need to take any > action; however if you do notice anything unusual please let us know. > > Thanks, > > _M > > -- > Pete McNeil > Chief Scientist > ARM Research Labs, LLC > www.armresearch.com > 866-770-1044 x7010 > twitter/codedweller > > > ##**##**# > This message is sent to you because you are subscribed to > the mailing list . > This list is for discussing Message Sniffer, > Anti-spam, Anti-Malware, and related email topics. > For More information see http://www.armresearch.com > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > > > To switch to the INDEX mode, E-mail to > Send administrative queries to > > > > >
[sniffer] Re: 3 million rules and counting.
Congratulations. Keep up the good work!
[sniffer] Re: curl couldn't connect to host
9 9:43:35.51 getRulebase.cmd called by SNFServer.exe due to > presence of UpdateReady.txt file > Mon 07/06/2009 9:43:35.53 Calling cURL to fetch the rulebase > Mon 07/06/2009 9:43:47.52 Calling snf2check to see if the download is > valid > Mon 07/06/2009 9:43:47.74 New rulebase is in effect. > Mon 07/06/2009 9:46:51.98 getRulebase.cmd called by SNFServer.exe due to > presence of UpdateReady.txt file > Mon 07/06/2009 11:11:52.52 getRulebase.cmd called by SNFServer.exe due to > presence of UpdateReady.txt file > Mon 07/06/2009 11:11:52.54 Calling cURL to fetch the rulebase > Mon 07/06/2009 11:12:03.97 Calling snf2check to see if the download is > valid > Mon 07/06/2009 11:12:03.99 New rulebase is in effect. > Mon 07/06/2009 11:15:08.12 getRulebase.cmd called by SNFServer.exe due to > presence of UpdateReady.txt file > > Checking further back shows that I get the "An error has occurred" message > a few times a day and hadn't noticed. > > Checking my ping times and traceroutes show that I have no packet loss but > there is random extra lag of zero to 85ms on AboveNet, which sits between my > provider and RackSpace where the updates server is. > > > Andrew. > > > -- > *From:* Message Sniffer Community [mailto:snif...@sortmonster.com] *On > Behalf Of *Richard Stupek > *Sent:* Monday, July 06, 2009 11:16 AM > *To:* Message Sniffer Community > *Subject:* [sniffer] curl couldn't connect to host > > I just started seeing this error for the getrulebase.cmd script. Is there > an issue going on? >
[sniffer] curl couldn't connect to host
I just started seeing this error for the getrulebase.cmd script. Is there an issue going on?
[sniffer] Re: New getRulebase.cmd and CURL utility for Windows
If we have a up to date snf file, will the script cause snf2check to print out "ERROR_RULE_FILE!"? On Mon, Mar 9, 2009 at 11:16 AM, Pete McNeil wrote: > Hello Sniffer Folks, > > We have determined that using the latest getRulbase.cmd script w/ CURL does > resolve the DST problem. > Please update your getRulebase.cmd script as soon as possible. > > You can find the latest getRulebase.cmd script and a copy of CURL here: > > http://www.armresearch.com/message-sniffer/download/CURL-getRulebase.zip > > Please install this new update script as soon as possible. > > 1. Open the .zip file in a new folder. > > 2. Open the new getRulebase.cmd in a text editor. > > 3. Open your existing getRulebase.cmd in a text editor. > > 4. Update your new getRulebase.cmd script with the correct directory, > license ID, and authentication string using your old getRuelbase.cmd script > as a reference. You should be able to cut and paste. > > 5. Double check your entries and save the new getRulebase.cmd script. > > 6. Close the text editors. > > 7. Make a backup copy of your old getRulebase.cmd script (copy it to > getRulebase.cmd.old). > > 8. Copy curl.exe into your working directory (where the getRulebase.cmd > script will run). > > 9. Copy the new getRulebase.cmd script into your working directory > (replacing the previous version). > > That's it! > > You can test the new getRulebase.cmd script by creating an UpdateReady.txt > file in your working directory (if it doesn't already exist) and then > running getRulebase.cmd from the command line. If your .snf file was out of > date or if it did not exist then it will be downloaded. > > Thanks, > > _M > > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > >
[sniffer] Re: xci scanner command
A question about using the XCI command. Assume an email passes through sniffer and does not trigger any rules, I then run it through and determine it is in fact spam. I send a command to let sniffer know the IP address had a bad event. Won't the event that would occur due the spam passing through nullify the bad event? Should I post 2 bad events for each mail that is caught after sniffer? On Tue, Feb 17, 2009 at 5:02 PM, Pete McNeil wrote: > Richard Stupek wrote: > >> Thanks for the info. Is there any diagnostic information available when a >> gbudb sync occurs? >> > You can always see the current status of GBUdb in your status.* files. If > you append these logs you can follow the state of the system through time > using pre-compiled statistics including the size of GBUdb. This can be done > with one entry per minute (status.minute) or one entry per hour > (status.hour) or both. > > In the same status log you can see when the last GBUdb condensation event > occurred. > > No other useful data is produced by a condensation run so none is recorded. > > If there is something you would like to see then please let us know and we > will consider adding features to support your request(s). > > > Best, > > _M > > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > >
[sniffer] Re: xci scanner command
Thanks for the info. Is there any diagnostic information available when a gbudb sync occurs? On Tue, Feb 17, 2009 at 4:35 PM, Pete McNeil wrote: > Richard Stupek wrote: > >> A question on GBUDB utilization. I show a current utilization of 95% >> (from the log file) which I assume means the amount of memory used from what >> is set aside for gbudb entries. Is that correct? >> > Yes. > >> What happens when more entries are added? Does the GBUdb grow or does it >> get pruned out? >> > Both. When more space is needed the ram allocated to GBUdb will grow to > accommodate the need. This should happen infrequently. When entries are no > longer active they are dropped to make room for additional entries. In > practice the GBUdb data size stabilizes quickly and then doesn't change > much. > > Once per day or as otherwise specified by GBUdb condensation triggers the > GBUdb data will be condensed. This means that all of the good and bad event > counts are divided in half. This has the effect of retaining the ratios > (probability of spam) while reducing the event counts (confidence figure). > Any ugly entries that drop to zero are dropped from the system (forgotten). > The remaining live entries are placed in a new GBUdb and the old one is > thrown away. If the GBUdb size can shrink during a condensation run then it > will. > >> Will gbudb XCI commands (like ) show up in a log file? >> > No. These are administrative entries so they don't get reported in scan > activity. We may change this later but at present there are no requests for > it. > > Best, > > > _M > > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > >
[sniffer] Re: xci scanner command
A question on GBUDB utilization. I show a current utilization of 95% (from the log file) which I assume means the amount of memory used from what is set aside for gbudb entries. Is that correct? What happens when more entries are added? Does the GBUdb grow or does it get pruned out? Will gbudb XCI commands (like ) show up in a log file? On Fri, Feb 13, 2009 at 3:27 PM, Pete McNeil wrote: > Richard Stupek wrote: > >> So there would not be a real benefit to passing the IP over when it is the >> is already in the mail having been added by the mail server? >> > Correct. > > The vast majority of the time a properly configured SNF + GBUdb can learn > the original source of the IP even if you have multiple gateways in your > infrastructure. > > You can even teach SNF + GBUdb to learn to see past the infrastructure of > other ISPs in many cases. For example you might teach it to see past a DSL > provider's outbound servers so that it can map IP reputations based on > individual message sources on their network provided they include Received > headers you can understand and predict (to some extent). This way GBUdb can > provide pinpoint accuracy instead of a "rough average" of every source on > that network. > > That said, there are still some times where you might want to explicitly > define the source IP even if it is present in the Received headers. > > For example, one of our larger customers has a complex infrastructure. They > found that it was easier to explicitly provide the source IP than to train > SNF + GBUdb to understand their structure and the inevitable changes that go > on through time. > > Another large customer has developed a very complex system for determining > the precise original source for a message even when it is relayed through > many large ISPs. They chose to provide that IP rather than have SNF + GBUdb > attempt to duplicate that effort. > > > _M > > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > >
[sniffer] Re: xci scanner command
So there would not be a real benefit to passing the IP over when it is the is already in the mail having been added by the mail server? On Fri, Feb 13, 2009 at 2:56 PM, Pete McNeil wrote: > Richard Stupek wrote: > >> Which of the 2 scan commands should we use to scan a message? Does >> sending the IP address help improve scanning? >> >> >> OR >> > ip='12.34.56.78'/> >> > That depends on your needs. > > If you want SNF + GBUdb to learn IPs by reading through the Received > headers then you would NOT include the ip= attribute. > > If you want to tell SNF + GBUdb what the source IP was for the message > explicitly then you DO include the ip= attribute. > > See: > > > http://www.armresearch.com/support/articles/software/snfServer/xci/scanner.jsp > > "The ip='12.34.56.78' attribute is optional and indicates that the source > IP for the message has already been determined as 12.34.56.78. If this > option is used then GBUdb training directives may not function as expected. > This option is best used when the calling application has already determined > the correct source IP for the message and wishes to force the source IP > value rather than have SNF+GBUdb discover it from Received headers in the > message. > > Note: It is often best to let SNF + GBUdb determine the source IP for a > given message based on the Received headers. If the connecting IP is not > already represented in the top Received header for the message then the > calling application should create one in the top of the temporary file SNF > is going to scan." > > Hope this helps, > > _M > > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to > >
[sniffer] xci scanner command
Which of the 2 scan commands should we use to scan a message? Does sending the IP address help improve scanning? OR
[sniffer] GBUdb
Does the snf XML command interface for GBUdb work? I was considering pumping in bad IPs as I find them into the GBUdb and also short-circuiting spam processing by calling the GBUdb to determine the status of an IP to reduce workload. Is this something that sounds like a workable idea?
[sniffer] Re: GBUdb
Ok. We are seeing a large amount of spam lately that is not being picked up through snf and most of it has the "from" and the "to" set the same. Are you seeing anything similar? On Thu, Dec 4, 2008 at 2:37 PM, Pete McNeil <[EMAIL PROTECTED]>wrote: > Hello Richard, > > > Thursday, December 4, 2008, 3:27:51 PM, you wrote: > > >> > > Is the GBUdb currently sharing information as described in the > documentation? > > > Yes. > > >> > > Do the GBUdb XCI commands detailed within snf_xci.xml work through the > tcp interface? > > > Yes. > > > The SNFClient utility simply translates your command line parameters into > XCI requests. > > > Best, > > > _M > > > > > -- > > Pete McNeil > > Chief Scientist, > > Arm Research Labs, LLC. > > # > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: <[EMAIL PROTECTED]> > To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> > To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> > Send administrative queries to <[EMAIL PROTECTED]> > > >
[sniffer] GBUdb
Is the GBUdb currently sharing information as described in the documentation? Do the GBUdb XCI commands detailed within snf_xci.xml work through the tcp interface?
