[sniffer] Re: xci scanner command
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] Re: xci scanner command
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] Re: ClamAID
Hi Andrew: I found the http://oss.netfarm.it/clamav build very useful. I don't recall any installation difficulty. It did have a successful installer and is able to install itself as a service. There is a .REG file that sets up a registry entry where the path is stored. ClamAID could update the program's registry, the service's registry if needed and adjust the two conf files as needed in case someone wants to change the default locations for the CONF, DB and LOG subdirectories. In their registry, I use the following: [HKEY_LOCAL_MACHINE\SOFTWARE\ClamAV] "ConfigDir"="C:\\Progra~1\\ClamAV\\conf" "DataDir"="C:\\Progra~1\\ClamAV\\db" For FreshClam.conf, I changed these parameters: DatabaseDirectory "C:\Program Files\clamAV\db" UpdateLogFile "C:\Program Files\clamAV\log\freshclam.log" LogTime yes For ClamD.conf, I changed these: LogFile "C:\Program Files\clamAV\log\clamd.log" LogTime yes TemporaryDirectory C:\Temp DatabaseDirectory "C:\Program Files\clamAV\db" For the service, I removed the spaces from the path (not sure if this was needed): "C:\Progra~1\ClamAV\clamd.exe" --daemon In Declude, you'd use: #ClamAV SCANFILE1 C:\Progra~1\ClamAV\ClamDScan.exe VIRUSCODE1 1 Of course, that still leaves the problem of the virus report file. I have contacted Declude and they said they would check if they can natively parse the report file. For now I still use my "middleware" to reformat the Report file to suit Declude. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Andrew Wallo Sent: Monday, February 02, 2009 1:44 PM To: Message Sniffer Community Subject: [sniffer] Re: Crosspost: ClamAV for Window (Summary of what I had posted last month on a different list) Team, Sniffer Folks, Andy: The ClamAID installer does handle the pthreads requirement for you. It does wrap ClamD as a service, (from the w32.clamav.net port ) , as well as wrapping freshclam.exe as a reoccurring service, and it finishes with a test of the eicar file. Older Port? Yes, again, you are correct. The port from ClamAV is old, and so the warning (From executing the ClamAV scanner at the command line), gives you a 36 out of 48 possible in your "upgrade score". ( Meaning, your database is up to date, but you have an older clamd.exe. ) This will be updated as soon as ClamAV releases a rebuild. We felt that while we could use one of the other two ports that were out there, people would be more comfortable using the .MSI that was issued from ClamAV. Sadly, this MSI does have limitations, that we've hopefully corrected. ( One of these is it fails to adjust the paths in data and config resources, if you install in an alternative folder. ) Every document we found said "Don't Change the Install Path!" Yet the ClamAV installer offers you the choice to put it anywhere. The problem seems to be that the Clamd.exe ignores its local config file if its installed somewhere other than C:\ClamAV\ The workaround is to always include the command line switch --config-file="" in all calls to clamdscan.exe or freshclam.exe. ClamAID handles correcting thoses issues. It uses command line config references for all calls from Declude or Icewarp, in order to enable you to install it in a location other than C:\ClamAV\ We thought that was a good upgrade just in itself. Let us know how it responds under fire. Thanks, Andrew Wallo - Original Message - From: "Andy Schmidt" To: "Message Sniffer Community" Sent: Monday, February 02, 2009 1:20 PM Subject: [sniffer] Crosspost: ClamAV for Window (Summary of what I had posted last month on a different list) > Hi, > > 1. http://www.clamwin.com is essentially a GUI/desktop build. It's kept > current - but doesn't have ClamD. So no good! > > 2. http://hideout.ath.cx/clamav/ needs CHP > (http://www.commandline.co.uk/chp/) to run in the "background", but was > unable to run this ClamD as a "service". > > 3. http://w32.clamav.net/ (the "official" build) does have ClamD and can > use > the current signature files - BUT the build is 10 month old (whatever the > consequence of that might be). It can be made to work with Declude, using > a > little Jscript that I'm attaching. > > a) Declude Configuration: > #ClamAV > SCANFILE1 c:\Windows\system32\cscript.exe //nologo > D:\CMDfiles\runClamAV.JS > VIRUSCODE1 1 > REPORT1 FOUND > > b) Schedule this hourly to get fetch signature updates: > freshclam --daemon-notify > > The Jscript file trims off the trailing "\" that Declude uses (otherwise > ClamDScan exits with code "2", file/path not found) and generates a > Report.txt file that matches Declude's expected format. > > > It would be helpful if someone were to either take over the "official > builds" and bring the version up to date (and teaches ClamDScan to accept > paths with trailing backslashes). > > Best Regards, > Andy > > -Original Message- > From: Andy Schmidt [mailto:andy_sch
