[sniffer] Re: What is your oldest production CPU?
Actually - this one is older: Dell PE 1600SC (x86) Intel XEON Family F (15) Model 2 Stepping 9 -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Friday, December 27, 2013 9:44 AM To: Message Sniffer Community Subject: [sniffer] What is your oldest production CPU? Hello Sniffer Folks, We would like to know what your oldest production CPU is. When building new binaries of SNF or it's utilities we would like to select the newest CPU we can without leaving anybody behind. We're also evaluating whether we should split binaries into a compatible version base on Intel i686 (or equivalent AMD), and a current version based on Intel Core2 (or equivalent AMD). Please respond here. Thanks for your time!! _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: 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 # 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: 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: What is your oldest production CPU?
Dell PE 2950 Intel Xeon CPU 5050 Type 0 Family F Model 6 Stepping 4 Revision 2 -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Friday, December 27, 2013 9:44 AM To: Message Sniffer Community Subject: [sniffer] What is your oldest production CPU? Hello Sniffer Folks, We would like to know what your oldest production CPU is. When building new binaries of SNF or it's utilities we would like to select the newest CPU we can without leaving anybody behind. We're also evaluating whether we should split binaries into a compatible version base on Intel i686 (or equivalent AMD), and a current version based on Intel Core2 (or equivalent AMD). Please respond here. Thanks for your time!! _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: 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 # 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: 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] Upgrading Stand-Alone Sniffer (for Declude)
Now that Declude forces us to use the stand-alone version again - time for me to upgrade the old stuff I had laying around. Currently I'm running (with SrvAny): SNFMulti Engine Version 3.0.11 Build: Aug 21 2009 18:42:53 SNF Server Version 3.0.2 Build: Jul 28 2009 14:48:00 and it's working. On the web site, I see a download link for the distribution: http://www.armresearch.com/products/index.jsp#distros Unfortunately, it seems that all the options want to do a full install - including installing the service (even though I already have it running with SrvAny, and have a working update script that I had customized). What's the best way to get the latest code without the Windows installer messing around with my working services and files? Best Regards, Andy # 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: 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] Reputation Lookup DNSBL?
Hi, I suppose I should have paid attention in the past 12 months. Is there a GBUdb IP based lookup that is recommended to get the benefit of all Sniffer customers' experiences? Or is it not worth the effort? Best Regards, Andy # 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: 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: GBUdb.com Web Site is Up - truncate.gbudb.net text records updated
Hi,
In case anyone wants to use it in ORF, attached the updated definition file.
(Pete, I didn't post it on their newsgroup because I didn't know if you
wanted the word out).
Best Regards,
Andy
-Original Message-
From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf
Of Pete McNeil
Sent: Sunday, May 23, 2010 3:12 PM
To: Message Sniffer Community
Subject: [sniffer] GBUdb.com Web Site is Up - truncate.gbudb.net text
records updated
Hi Sniffer Folks,
The GBUdb.com web site is up http://www.gbudb.com
We have also updated the generator for the truncate.gbudb.net list so
that the TXT records include a link to the list descriptor at
http://www.gbudb.com/truncate/ and the IP address in [square brackets].
Please tell us what you think.
Thanks!
_M
--
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com
#
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: 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
?xml version=1.0 encoding=utf-8?
definitions
blacklistshort_nameGBUdb/short_namefull_nameGBUdb Cloud/full_namedescriptionGBUdb stands for Good, Bad, Ugly database. It is a real-time
collaborative IP reputation system.
IPs are added to this list when substantially all recorded events
for a given IPv4 address indicate the message content was
spam, scam, virus, or other malware. Specifically the collective
statistics for this category indicate that greater than gt; 95% of
all recorded events from all active GBUdb nodes indicate a bad
message and that there are a sufficient number of recorded
events for the data available to be considered reliable./descriptiondomaintruncate.gbudb.net/domainip_reversedyes/ip_reversedsupports_txtyes/supports_txtsite_urlhttp://www.gbudb.com//site_urllookup_urlhttp://www.gbudb.com/truncate/index.jsp/lookup_urldns_record_typeA/dns_record_typeany_dns_result_blocksno/any_dns_result_blocksactionsactionenabledYes/enabledis_dynamicNo/is_dynamicresult127.0.0.2/resultsmtp_code550/smtp_codesmtp_text5.7.1 Message refused. Your IP address {IP} is blacklisted using {BLACKLISTNAME}. Details: {TXTDATAORWEBLOOKUP}./smtp_text/action/actionsaction_on_any_result_blocksactionenabledYes/enabledis_dynamicNo/is_dynamicresult/resultsmtp_code550/smtp_codesmtp_text/smtp_text/action/action_on_any_result_blocks/blacklist
/definitions
#
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: 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: GBUdb.com Web Site is Up - truncate.gbudb.net text records updated
Hi, An annual donation is not a problem - of course, we are already paying for Sniffer and supplying feedback that is incorporated into GBUdb - so to us it's just another way to access information for which we are already licensed (using an RBL instead of the Sniffer API) - just a bit earlier. It's a little different for non-clients who would just be free-riding. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Saturday, May 29, 2010 6:55 PM To: Message Sniffer Community Subject: [sniffer] Re: GBUdb.com Web Site is Up - truncate.gbudb.net text records updated On 5/29/2010 4:01 PM, Andy Schmidt wrote: Hi, In case anyone wants to use it in ORF, attached the updated definition file. (Pete, I didn't post it on their newsgroup because I didn't know if you wanted the word out). I appreciate it -- It's not a secret, but we do want to get a donation mechanism and some for-pay features in place before we push it so that we can cover the growth in hosting costs. Hopefully we'll have that stuff going soon - there are already quite a few folks using it! I would like to know what folks think about that. Our community is pretty smart about hosting, costs, and what is reasonable / expected, so I value everyone's opinion. Thanks! _M -- Chief Scientist ARM Research Labs, LLC www.armresearch.com # 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: 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 # 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: 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] Declude: Sniffer IP vs. Sniffer IP Reputation vs. Sniffer Truncate
Hi Pete, I'm look over Declude's recommended Sniffer configuration and trying to understand how much (if any) overlap there is between these options they implemented and recommend: IPREPUTATIONSNFIPREPx 0 10 -5 SNFIPCAUTIONSNFIP x 4 5 0 SNFIPBLACK SNFIP x 5 10 0 SNFIPTRUNCATE SNFIP x 6 10 0 SNFTRUNCATE SNF x 20 10 0 SNIFFER-IP-RULESSNF x 63 10 0 Looking at the Sniffer documentation IP test result codes http://www.armresearch.com/support/articles/software/snfClient/resultCodes.j sp it seems that the SNFIP tests for 4, 5 and 6 (SNFIPCAUTION, SNFIPBLACK, SNFIPTRUNCATE) might coincide with 40, 63 and 20. However, Declude ALSO tests for your Rule Group Result Codes 20 and 63 which are documented here: http://www.armresearch.com/support/articles/software/snfServer/core.jsp 1. It seems to me, as if their SNFTRUNCATE is the same as their SNFIPTRUNCATE, and their SNIFFER-IP-RULES is the same as their SNFIPBLACK -- effectively artificially inflating (doubling) the weights for these tests? 2. How do those Caution/Black/Truncate exit codes relate to SNFIPREP. There, any reputation 0 (up to 1) is given an extra weight of 10. But doesn't SNFIPREP report from the same reputation data as the SNFIP (and possibly even group result codes 20 and 63)? In other words, are those IP addresses that generate a reputation factor of 0 ALSO reported as Caution/Black or Truncate - if so, we'd now TRIPLE count that score. Best Regards, Andy # 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: 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: Message Sniffer DLL now used in Declude
Hi Pete, I saw their announcement. Dave says they are using THEIR rule base (not the one specific to the Sniffer customer). Any hints what I have to do (on the Sniffer side) to move over to their service? Which part of my current stand-alone installation do I have to undo (e.g., the Sniffer service?), what about the update script and the uploading of log files? Does that still apply, if it's under the Declude rule base? Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Monday, January 04, 2010 8:34 PM To: Message Sniffer Community Subject: [sniffer] Message Sniffer DLL now used in Declude Hello Sniffer Folks, The Declude folks have announced version 4.10.42. With this version Declude now integrates Message Sniffer via our DLL. Benefits: * Improved performance -- Not an external test, so no program must be launched -- Uses the message already in RAM thus saving disk IO -- SNFMulti engine runs inside of the Declude service (one less program / service) -- No XCI calls required to request scans (reduced communications overhead) * Provides direct access to the GBUdb IP Reputation system for additional scoring options Here is a link to their announcement as archived on The Mail Archive http://www.mail-archive.com/declude.junkm...@declude.com/msg33094.html Best, _M # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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 # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: RulePanic on 2654821
Dito here - already reported it as a False Positive: s u='20090908183815' m='D:\IMail\spool\proc\work\Dd948c4c42c68.smd' s='54' r='2654821' m s='54' r='2654821' i='1905' e='1952' f='m'/ p s='0' t='15' l='4270' d='38'/ g o='0' i='64.78.17.17' t='u' c='0.071429' p='0' r='Normal'/ /s From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Darin Cox Sent: Tuesday, September 08, 2009 4:49 PM To: Message Sniffer Community Subject: [sniffer] Re: RulePanic on 2654821 Neglected to mention it is a Sniffer-Porn rule. Darin. - Original Message - From: Darin Cox mailto:dc...@4cweb.com To: Message mailto:sniffer@sortmonster.com Sniffer Community Sent: Tuesday, September 08, 2009 4:47 PM Subject: [sniffer] RulePanic on 2654821 We had to put a RulePanic on 2654821. We were getting a ton of FPs on it. Pete, let us know what's going on with this rule, please. Darin.
[sniffer] Re: DST update problem - server changes
Hi, That's why the enhanced version of your script (which properly supports Sniffer's ability to keep the rulebase and the workspace in subfolders!) that I sent you checks for CURL success AND for an existing file. curl http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -s -R -f -o %RULEBASE_PATH%\%LICENSE_ID%.new -z %RULEBASE_PATH%\%LICENSE_ID%.snf --compressed -u sniffer:ki11sp8m -D %SNIFFER_PATH%\curlhdr.txt if %ERRORLEVEL% NEQ 0 goto CLEANUP if not exist %RULEBASE_PATH%\%LICENSE_ID%.new goto CLEANUP snf2check.exe %RULEBASE_PATH%\%LICENSE_ID%.new %AUTHENTICATION% goto DONE I recommend you go to Cleanup - where the .LCK file will be cleaned up if it exists. Best Regards, Andy From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, March 10, 2009 7:59 AM To: Message Sniffer Community Subject: [sniffer] Re: DST update problem - server changes David Moore wrote: I to have the same problem I have reverted back to the old script. (We are windows based) snip/ Shawn wrote: Pete, I upgraded to the latest getRulebase file and followed the instructions, but now all I see on my windows system (DST) is the following: (I replaced my license ID # with ) snf2check: .new ERROR_RULE_FILE! 1 file(s) copied.R:2349772 [0/12 - 0] W:0 C:0 B:0 T:0 S:0 snf2check: .new ERROR_RULE_FILE! 1 file(s) copied.R:2349772 [0/12 - 0] W:0 C:0 B:0 T:0 S:0 This is most likely NOT a problem -- This happens when the update script runs and the file on the server is not newer than the file on your system. CURL will refuse to download the file and then snf2check produces an ERROR_RULE_FILE! error because it cannot find the new rulebase file it is looking for. We are reworking the script to include line to test for this and exit the script instead of producing the error. You can add the following line just before the snf2check.exe line: if not exist %LICENSE_ID%.new goto DONE In this case the ERROR_RULE_FILE error itself is harmless. _M
[sniffer] Re: DST update problem - server changes
1 checks for a new file from CURL. It also uses the -v (verbose) option with CURL and captures it's output to the getRulebase.txt file for reporting. If there is an error then the details will be seen. I'm glad to see that (after a few tries), your script finally looks like the one I had sent last September G The benefit for checking the CURL errorlevel: if %ERRORLEVEL% NEQ 0 goto CLEANUP is that it gracefully handles incomplete .NEW files that might result from interrupted file transfers. There's no reason for snf2check to Hick Up and report on a SNF file, if the download was never successful! 2. Agreed on complexity. Just to keep things in perspective - the added two lines below shoe how complex the support for dedicated rulebase and work subfolders really is G: Nothing changes for clients who don't use subfolders - nothing changes in the installer! REM - Edit This Section SET SNIFFER_PATH=C:\SNF SET RULEBASE_PATH=%SNIFFER_PATH% SET WORKSPACE_PATH=%SNIFFER_PATH% But clients who do choose to set up subfolders, would at least be able to use your standard script: REM - Edited to Support Dedicated Subfolders SET SNIFFER_PATH=D:\IMail\declude\SNF SET RULEBASE_PATH=%SNIFFER_PATH%\Rulebase SET WORKSPACE_PATH=%SNIFFER_PATH%\Workspace I'm a big believer in keep dynamic data separate from static program/config files. Prevents things from being overlooked, things from accidentally being cleaned up that shouldn't be, allows proper execute/change permissions being set - and by avoiding mistakes ultimately improves stability. I'm not complaining. Last year I had pointed out that CURL should be used to maintain file dates and had submitted the simple change to the script (including checking the return code AND checking for the existence of a downloaded file AND cleaning up the Log File.!) - which were finally incorporated. So there's hope that some future event will eventually make the benefits of dedicated data subfolders equally apparent G. Best Regards, Andy From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, March 10, 2009 10:20 AM To: Message Sniffer Community Subject: [sniffer] Re: DST update problem - server changes Andy Schmidt wrote: Hi, That's why the enhanced version of your script (which properly supports Sniffer's ability to keep the rulebase and the workspace in subfolders!) that I sent you checks for CURL success AND for an existing file. curl http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf http://www.sortmonster.net/Sniffer/Updates/%25LICENSE_ID%25.snf -s -R -f -o %RULEBASE_PATH%\%LICENSE_ID%.new -z %RULEBASE_PATH%\%LICENSE_ID%.snf --compressed -u sniffer:ki11sp8m -D %SNIFFER_PATH%\curlhdr.txt if %ERRORLEVEL% NEQ 0 goto CLEANUP if not exist %RULEBASE_PATH%\%LICENSE_ID%.new goto CLEANUP The newest version (just posted before I received this note) checks for a new file from CURL. It also uses the -v (verbose) option with CURL and captures it's output to the getRulebase.txt file for reporting. If there is an error then the details will be seen. curl -v http://www.sortmonster.net/Sniffer/Updates/%25LICENSE_ID%25.snf http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf; -o %LICENSE_ID%.new -s -S -R -z %LICENSE_ID%.snf -H Accept-Encoding:gzip --compressed -u sniffer:ki11sp8m 2 getRulebase.txt if not exist %LICENSE_ID%.new echo New rulebase file NOT downloaded getRulebase.txt if not exist %LICENSE_ID%.new goto CLEANUP snf2check.exe %RULEBASE_PATH%\%LICENSE_ID%.new %AUTHENTICATION% goto DONE I recommend you go to Cleanup - where the .LCK file will be cleaned up if it exists. The new script does this and it also reports success explicitly snf2check.exe %LICENSE_ID%.new %AUTHENTICATION% 2 getRulebase.txt if errorlevel 1 goto CLEANUP echo New rulebase file tested OK getRulebase.txt The script we are using does not yet support alternate/sub folders because we have not built that capability into our windows installer. Using alternate/sub folders is a custom modification and is likely to be different on each system so we aren't (yet) making any attempt to have our installer predict or understand this kind of configuration. A later version of the script might include some hooks to do that but they will need to be ignored by the installer for the time being. Trying to keep things simple. Thanks, _M
[sniffer] Re: Daylight Savings Time Update Problem.
Yes, with the OLD version (before the upgrade) I used to run my own script - and it successfully used: curl http://www.sortmonster.net/Sniffer/Updates/MyRuleBase.snf -o MyRuleBase.snf.gz -s -S -R -z MyRuleBase.snf -H Accept-Encoding:gzip -u sniffer-userid:sniffer-pwd if exist nwb655oh.snf.gz goto :Check -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Monday, March 09, 2009 9:45 AM To: Message Sniffer Community Subject: [sniffer] Daylight Savings Time Update Problem. Hello Sniffer Folks, IMPORTANT! We have discovered a problem with the rulebase update mechanism that is currently installed on most systems; and this problem combined with daylight savings time is causing trouble with rulebase updates. There has long been a bug in the getRulebase script using wget which causes the rulebase file that is downloaded to have the local system's timestamp. Under normal circumstances this does not cause a problem because most system clocks are synchronized and the local timestamp is generally newer than the timestamp of the rulebase file on our servers. HOWEVER, with daylight savings time starting this past Sunday there is a problem: The local timestamp for the rulebase file is almost always older than the timestamp shown on our servers. As a result the update mechanism continues to go back to get a new rulebase file over, and over, and over again. We have a newer update script that uses CURL and we are testing this newer script to see if it will solve this problem even when the local server's daylight savings time starts later than our server. (The start date of daylight savings time has change recently) We are hopeful that the new script and the use of CURL will solve the update problem by fixing the timestamp bug. We will let you know shortly about the results of our testing. In any case, there are clearly a large number of servers that are not yet on daylight savings time and that in itself is likely to cause some problems. We will post again shortly, Best, _M # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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 # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: Daylight Savings Time Update Problem.
Hm - seems that I may have commented out WGET and have been using CURL even with the new version (because of date mismatches). So - maybe the enclosed will help. It SEEMS as if my /rulebase/ folder has been updated at least twice since 8:30 AM this morning... -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Monday, March 09, 2009 9:45 AM To: Message Sniffer Community Subject: [sniffer] Daylight Savings Time Update Problem. Hello Sniffer Folks, IMPORTANT! We have discovered a problem with the rulebase update mechanism that is currently installed on most systems; and this problem combined with daylight savings time is causing trouble with rulebase updates. There has long been a bug in the getRulebase script using wget which causes the rulebase file that is downloaded to have the local system's timestamp. Under normal circumstances this does not cause a problem because most system clocks are synchronized and the local timestamp is generally newer than the timestamp of the rulebase file on our servers. HOWEVER, with daylight savings time starting this past Sunday there is a problem: The local timestamp for the rulebase file is almost always older than the timestamp shown on our servers. As a result the update mechanism continues to go back to get a new rulebase file over, and over, and over again. We have a newer update script that uses CURL and we are testing this newer script to see if it will solve this problem even when the local server's daylight savings time starts later than our server. (The start date of daylight savings time has change recently) We are hopeful that the new script and the use of CURL will solve the update problem by fixing the timestamp bug. We will let you know shortly about the results of our testing. In any case, there are clearly a large number of servers that are not yet on daylight savings time and that in itself is likely to cause some problems. We will post again shortly, Best, _M # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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 REM @ECHO OFF SETLOCAL REM - Edit This Section SET SNIFFER_PATH=D:\IMail\declude\SNF SET RULEBASE_PATH=%SNIFFER_PATH%\Rulebase SET WORKSPACE_PATH=%SNIFFER_PATH%\Workspace SET AUTHENTICATION=myauthcode SET LICENSE_ID=mylicensekey REM CD /d %SNIFFER_PATH% if not exist %WORKSPACE_PATH%\UpdateReady.txt GOTO DONE REM The next line may cause trouble if your system stops while this REM script is running. It is not needed when this script is run REM from SNF's update-script/ feature since only one copy will run REM at a time. However, if you are going to run a version of this REM script as a scheduled task you will want to uncomment the next REM line to make sure only one copy runs at a time-- just be sure to REM clean out any stale .lck files after a restart. REM if exist %WORKSPACE_PATH%\UpdateReady.lck GOTO DONE :DOWNLOAD COPY %WORKSPACE_PATH%\UpdateReady.txt %WORKSPACE_PATH%\UpdateReady.lck REM wget http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -O %RULEBASE_PATH%\%LICENSE_ID%.new.gz --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m REM if exist %RULEBASE_PATH%\%LICENSE_ID%.new.gz gzip -d -f %RULEBASE_PATH%\%LICENSE_ID%.new.gz curl http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -s -R -f -o %RULEBASE_PATH%\%LICENSE_ID%.new -z %RULEBASE_PATH%\%LICENSE_ID%.snf --compressed -u sniffer:ki11sp8m -D %SNIFFER_PATH%\curlhdr.txt if %ERRORLEVEL% NEQ 0 goto CLEANUP if not exist %RULEBASE_PATH%\%LICENSE_ID%.new goto CLEANUP snf2check.exe %RULEBASE_PATH%\%LICENSE_ID%.new %AUTHENTICATION% if errorlevel 1 goto CLEANUP if exist %RULEBASE_PATH%\%LICENSE_ID%.old del %RULEBASE_PATH%\%LICENSE_ID%.old rename %RULEBASE_PATH%\%LICENSE_ID%.snf %LICENSE_ID%.old rename %RULEBASE_PATH%\%LICENSE_ID%.new %LICENSE_ID%.snf if exist %WORKSPACE_PATH%\UpdateReady.txt del %WORKSPACE_PATH%\UpdateReady.txt if exist %WORKSPACE_PATH%\UpdateReady.lck del %WORKSPACE_PATH%\UpdateReady.lck :CLEANUP if exist %RULEBASE_PATH%\%LICENSE_ID%.new del %RULEBASE_PATH%\%LICENSE_ID%.new if exist %WORKSPACE_PATH%\UpdateReady.lck del %WORKSPACE_PATH%\UpdateReady.lck :DONE ENDLOCAL # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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] 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 andy_schm...@hm-software.com To: Message Sniffer Community sniffer@sortmonster.com 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_schm...@hm-software.com] Sent
[sniffer] Re: [Declude.JunkMail] Errorlevel not working
Serge: if errorlevel 0 means if errorlevel = 0. You are NOT comparing to equal - it will return TRUE if the error level is AT LEAST the number 0 - which is true for any positive value. Best Regards, Andy -Original Message- From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Serge Sent: Sunday, February 08, 2009 7:50 PM To: declude.junkm...@declude.com Subject: Re: [Declude.JunkMail] Errorlevel not working Hello sandy Not true even if i comment echo line, i still get gzip OK errorlevel 0, Unzipping even if the file if corrupted gzip -d -f -t zydt3crn.snf.gz if errorlevel 0 goto gziperr0 if errorlevel 1 goto gziperr1 GOTO END :gziperr0 Echo gzip OK errorlevel 0, Unzipping GOTO END :gziperr1 Echo gzip errorlevel 1 Echo gzip .gz file did not test OK GOTO END :END - Original Message - From: Sanford Whiteman sa...@cypressintegrated.com To: Serge declude.junkm...@declude.com; Message Sniffer Community sniffer@sortmonster.com Sent: Monday, February 09, 2009 12:39 AM Subject: Re: [Declude.JunkMail] Errorlevel not working I have a problem with the branching in the batch below even when the test fails and echo %errorlevel% shows 1 the branching still goes to gziperr0 Does enyone knows why and how to fix ? When you echo the errorlevel, the errorlevel is reset to the value returned by echo(). --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: sa...@cypressintegrated.com SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release / Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/downloa d/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re lease/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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
RE: [Declude.JunkMail] Errorlevel not working
Serge: if errorlevel 0 means if errorlevel = 0. You are NOT comparing to equal - it will return TRUE if the error level is AT LEAST the number 0 - which is true for any positive value. Best Regards, Andy -Original Message- From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Serge Sent: Sunday, February 08, 2009 7:50 PM To: declude.junkm...@declude.com Subject: Re: [Declude.JunkMail] Errorlevel not working Hello sandy Not true even if i comment echo line, i still get gzip OK errorlevel 0, Unzipping even if the file if corrupted gzip -d -f -t zydt3crn.snf.gz if errorlevel 0 goto gziperr0 if errorlevel 1 goto gziperr1 GOTO END :gziperr0 Echo gzip OK errorlevel 0, Unzipping GOTO END :gziperr1 Echo gzip errorlevel 1 Echo gzip .gz file did not test OK GOTO END :END - Original Message - From: Sanford Whiteman sa...@cypressintegrated.com To: Serge declude.junkm...@declude.com; Message Sniffer Community sniffer@sortmonster.com Sent: Monday, February 09, 2009 12:39 AM Subject: Re: [Declude.JunkMail] Errorlevel not working I have a problem with the branching in the batch below even when the test fails and echo %errorlevel% shows 1 the branching still goes to gziperr0 Does enyone knows why and how to fix ? When you echo the errorlevel, the errorlevel is reset to the value returned by echo(). --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: sa...@cypressintegrated.com SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release / Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/downloa d/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re lease/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[sniffer] Re: ClamAID
Dear Matt: Things for pointing out http://oss.netfarm.it/clamav/. That is ONE build I had not yet run across (actually, I recognize the page, but somehow never bookmarked it). I had been unable to get http://hideout.ath.cx/clamav to run as a service - but the netfarm one explicitly states that it supports Windows service mode. I'll definitely give that one a try. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Mxuptime.com Sent: Wednesday, February 04, 2009 11:44 PM To: Message Sniffer Community Subject: [sniffer] Re: ClamAID Hi Just to add to the following topic. We've been bundling win32 builds of ClamD together with our product since the beginning and have some experience working with the win32 versions. These are my observations and thoughts : 1. http://w32.clamav.net/ has not been updated quite awhile and is rather outdated. 2. There are no official Win32 builds of ClamAV at the moment but from what I understand/read the next release .95 will have a native official win build 3. There are 3 popular updated win32 builds that include ClamD. One that runs in Cygwin (http://www.sosdg.org/clamav-win32) by Brielle Burns and the other 2 native win32 builds available at http://hideout.ath.cx/clamav and http://oss.netfarm.it/clamav. If i am not mistaken both of these win32 builds were actually built from http://w32.clamav.net and then updated to the current versions The Sosdg build has been extremely solid but sometime back Brielle mentioned that the project would be discountinued. But Later decided to continue with the project. The only shortcoming is that if you have other Cygwin daemon/services running you might have issues if there are different versions of the cygwin1.dll in use. For what its worth, SmarterMail uses this build. Overall, I have not found a lot of difference in both the other 2 native win32 builds. And they appear to be updated fairly quickly and frequently. Its fairly straightfoward to have clamD running as services but the ClamD daemon (in my experience) has known to have crashed once in awhile and as such you will need to have a watchdog/recovery service monitor the daemon and restart when necessary. Cheers -Matt # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: ClamAID
Hi, http://oss.netfarm.it/clamav seems to be ideal. I just installed it. a) runs as a Windows Service (using clamd --install) b) has registry settings to point to db and conf subfolders c) accepts trailing backslash The only remaining issue with Declude is the Declude's inability of extracting the infected file name and virus name from the Reports.txt file - but that's really a problem with Declude's lack of parsing ability. Gee - I wish Sniffer had a configuration option to tie into ClamD... Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Mxuptime.com Sent: Wednesday, February 04, 2009 11:44 PM To: Message Sniffer Community Subject: [sniffer] Re: ClamAID Hi Just to add to the following topic. We've been bundling win32 builds of ClamD together with our product since the beginning and have some experience working with the win32 versions. These are my observations and thoughts : 1. http://w32.clamav.net/ has not been updated quite awhile and is rather outdated. 2. There are no official Win32 builds of ClamAV at the moment but from what I understand/read the next release .95 will have a native official win build 3. There are 3 popular updated win32 builds that include ClamD. One that runs in Cygwin (http://www.sosdg.org/clamav-win32) by Brielle Burns and the other 2 native win32 builds available at http://hideout.ath.cx/clamav and http://oss.netfarm.it/clamav. If i am not mistaken both of these win32 builds were actually built from http://w32.clamav.net and then updated to the current versions The Sosdg build has been extremely solid but sometime back Brielle mentioned that the project would be discountinued. But Later decided to continue with the project. The only shortcoming is that if you have other Cygwin daemon/services running you might have issues if there are different versions of the cygwin1.dll in use. For what its worth, SmarterMail uses this build. Overall, I have not found a lot of difference in both the other 2 native win32 builds. And they appear to be updated fairly quickly and frequently. Its fairly straightfoward to have clamD running as services but the ClamD daemon (in my experience) has known to have crashed once in awhile and as such you will need to have a watchdog/recovery service monitor the daemon and restart when necessary. Cheers -Matt -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Andrew Wallo Sent: Thursday, February 05, 2009 4:38 AM To: Message Sniffer Community Subject: [sniffer] Re: ClamAID Sniffer Folks, - ASchmidt... snip ClamAV's web site states that they won't [ continue to support] and development has been stopped? http://w32.clamav.net/ /snip Oddly, I would have bet hard cash that page didn't say that just a week ago. I went there just recently in order to affirm I had the same dated MSI as was on their site prior to release of ClamAID. Plus a live webinar I attended with ClamAV folks at the end of Dec, personally reassured me that they intended to move forward on the Win Updates. ( Which is why that page out-and-out shocked me. ) Nevermind the fact that a lot of the emulation ports were dieing off because of the 'official' native win32 was easier to utilize. However, all is not lost. If you read the ClamAV site... Nigel Horn has been recently promoted in their organization and it was his efforts that kept the Windows port alive. I've included a recent letter from him to the ClamAV win32 list below, ( just posted ) which claims they will resume support at some (undefined) time in the future. Based on other expectations, probably not until after their main codebase rewrite releases in March of 09. Add deadline extentions etc. and you are probably well into fall. ( Clearly to long to rely on an outdated engine. ) But Nigel seems inclined to enable interested parties to push the ports independantly. Since the other two independant win32 ports do not include the clamd.exe port, Pete and I are in discussion about whether it will be more efficient to take on an ArmResearch port to win32, and throwing out the ClamAV MSI altogether. This would solve a lot of the ClamAID's complexity in fixing the install issues that come with the existing ClamAV MSI and it would get us an updated engine a lot sooner than is likely with the waiting list of upgrades from ClamAV. We'll keep you posted. Andrew Wallo Folks, I'm sorry that I've not been able to put time and effort into continuing the support of ClamAV on the Windows system. The ClamAV team intend to restart support for Windows as soon as we can. In the meantime I am also aware that not much has been happening on the Powertools front. For those of you that don't know, the Powertools is a suite of programs that enhance the features of ClamAV under Windows. * clamdService - a service to start clamd and freshclam * clamAVShellExt - an
[sniffer] Re: ClamAID
Hi Andrew: I agree, offering a functioning Win32 port that doesn't rely on Cygwin might give your firm additional exposure. Heck, I would gladly pay an annual fee for ClamAID if it included a current, native Win32 port of ClamD and would make my go-between script obsolete. PS: I would have thought that http://hideout.ath.cx/clamav/ would have been a good base to start from. All that's needed is to work on their ClamD to enable it to run as a service. Best Regards, Andy -Original Message- From: Andrew Wallo [mailto:awa...@armresearch.com] Sent: Wednesday, February 04, 2009 3:38 PM To: Message Sniffer Community Cc: andy_schm...@hm-software.com Subject: Re: ClamAID Sniffer Folks, - ASchmidt... snip ClamAV's web site states that they won't [ continue to support] and development has been stopped? http://w32.clamav.net/ /snip Oddly, I would have bet hard cash that page didn't say that just a week ago. I went there just recently in order to affirm I had the same dated MSI as was on their site prior to release of ClamAID. Plus a live webinar I attended with ClamAV folks at the end of Dec, personally reassured me that they intended to move forward on the Win Updates. ( Which is why that page out-and-out shocked me. ) Nevermind the fact that a lot of the emulation ports were dieing off because of the 'official' native win32 was easier to utilize. However, all is not lost. If you read the ClamAV site... Nigel Horn has been recently promoted in their organization and it was his efforts that kept the Windows port alive. I've included a recent letter from him to the ClamAV win32 list below, ( just posted ) which claims they will resume support at some (undefined) time in the future. Based on other expectations, probably not until after their main codebase rewrite releases in March of 09. Add deadline extentions etc. and you are probably well into fall. ( Clearly to long to rely on an outdated engine. ) But Nigel seems inclined to enable interested parties to push the ports independantly. Since the other two independant win32 ports do not include the clamd.exe port, Pete and I are in discussion about whether it will be more efficient to take on an ArmResearch port to win32, and throwing out the ClamAV MSI altogether. This would solve a lot of the ClamAID's complexity in fixing the install issues that come with the existing ClamAV MSI and it would get us an updated engine a lot sooner than is likely with the waiting list of upgrades from ClamAV. We'll keep you posted. Andrew Wallo # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: ClamAID
Hi Andrew: The ClamAID installer does handle the pthreads requirement for you. Understood, that's convenient. It does wrap ClamD as a service, (from the w32.clamav.net port ) , as well as wrapping freshclam.exe as a reoccurring service Yep, same thing can be accomplished with the SRVANY resource kit tool. This will be updated as soon as ClamAV releases a rebuild. Their web site states that they won't and development has been stopped? http://w32.clamav.net/ 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. Agreed. Every document we found said Don't Change the Install Path! Yet the ClamAV installer offers you the choice to put it anywhere. I had no problem configuring ClamAV to run in C:\Program Files\ClamAV. But it's convenient to have your installer take care of the config file. Best Regards, Andy # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: Announcing ClamAID - Clam AV installer for windows.
1. We haven't detected a trailing backslash issue with clamdscan.exe being called from Declude. My Declude creates a temporary folder C:\imail\spool\proc\work\Dxx.vir\ where it unravels the nested MIME attachments that belong to a single mail as individual files and then it attempts to scan the entire temporary folder content by launching: CLAMDSCAN.EXE -v --no-summary -l report.txt C:\imail\spool\proc\work\Dxx.vir\ The problem is that the W32.ClamAV.net build will return No such file or directory (under Windows 2003) if you pass a trailing slash. It WOULD work and scan the entire folder ONLY if the trailing backslash is omitted. I'm curious - in your system, what happens when you do: ClamDScan c:\windows\ vs. ClamDScan c:\windows 2. Your page http://www.armresearch.com/tools/arm/clamAID.jsp states: Navigate to the mail-application\declude\ directory under Imail or Smartermail. Find the virus.cfg file. The file should now have an entry: #CLAMAV_CLAMAID SCANFILE D:\PROGRA~1\ClamAV\CLAMDS~1.EXE -v --config-file=D:\PROGRA~1\ClamAV\conf\clamd.conf --no-summary -l D:\PROGRA~1\ClamAV\log\report.txt VIRUSCODE 1 If this is true, then on a busy server, multiple concurrent ClamAV processes would be attempting to write into the SAME report.txt file in the CLAMAV program files folder - causing concurrency problems or locked file problems. The best approach would be to leave out the path information and let ClamAV create a unique Report.txt file in the distinct temporary folder that is created for each message! I have read about this in some reports, and I've used the Declude recommended call for calling Clam... I'd like more information if you have The ClamAV report file will have the following format: -- C:\Maintenance\Eicar.com: Eicar-Test-Signature FOUND Declude will parse that Report.txt file and NOT expect to see the --- divider line AND will look for the word FOUND and expect the virus name AFTER the search token FOUND. Consequently the parsing will fail. Declude WILL recognize the error level and know that the email was infected, but neither the Declude log NOR the virus notification emails will report a sensible virus name. So the correct view of what is happening should be being logged on the ClamAV side, if not fully transparent through Declude. The virus notification emails are wrong and those of us who generate anti-virus reports by scanning the declude virus logfiles will get nonsense reporting. if you have it on your specific solution of the name-dissconnect Well, it's fairly simply. The script I had sent in my post two days ago does the following: a) trim the trailing backslash from the path if any is found b) read and parse the ClamAV report.txt file and outputs a new Report.txt file that uses a format that's parsable by Declude. Best Regards, Andy Schmidt # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: Announcing ClamAID - Clam AV installer for windows.
Hi Pete, Very cool. I just went through this a few weeks ago. Here's the issues I encountered: - The engine for official Windows build I found (http://w32.clamav.net/) was out of date (but still usable) and had problems with trailing backslashes the way that Declude was passing them. - The ClamWin build was current, but resisted any attempt to run it as a service. - Either one had the problem that the virus report generated by ClamAV is not understood by Declude (which looks only for one, very specific pattern) - so one doesn't get the proper virus name passed to messages, log files and virus statistics I ended up scripting some middleware between Declude and Clam that would address the trailing backslash on the input side and the virus name on the output site. Are all these issues addressed in your installer? How? Then I'd be happy to migrate my incarnation over to yours. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Monday, February 02, 2009 12:49 PM To: Message Sniffer Community Subject: [sniffer] Announcing ClamAID - Clam AV installer for windows. Hello Sniffer Folks, We've noticed that folks often have trouble getting Clam AV (the free open source anti-virus scanner) working correctly on their mail servers, so we've created a free product to help solve that. ClamAID (Clam AV Assisted Install Device). http://www.armresearch.com/tools/arm/clamAID.jsp What ClamIAD does is collect all of the bits and pieces that make ClamAV work, configure them, install them, and get them running with your email / filtering platform. So far ClamAID supports IceWarp, Declude/IMail, and Declude/SmarterMail. We will add support for additional platforms as requested (time permitting). Please take a look, keep us posted on your progress, and tell your friends about ClamAID if it helps you. If you have any questions or run into problems then please let us know (support@). Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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 # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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] 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_schm...@hm-software.com]
Sent: Sunday, January 04, 2009 6:39 PM
Hi,
The official Win32 build seems to work just fine, ClamD service and all?
a) I downloaded and installed the MSI file
b) I downloaded the pthread DLL that it required
c) I confirmed that clamscan (the command line scanner) was working - it
was.
d) I confirmed that I could run clamd from the command line. The I used
clamdscan from a second command window to scan for eicar.com, but this time
using the clamd instance - and it detected it instantly.
e) I installed clamd as a Window service:
C:\Program Files\Windows Resource Kits\Tools\Instsrv.exe ClamAV ClamD
C:\Program Files\Windows Resource Kits\Tools\Srvany.exe
Then added the necessary registry entry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClamAV
ClamD\Parameters]
Application=C:\\Program Files\\clamAV\\clamd.exe
f) started the ClamAV ClamD service - and again confirmed with clamdscan
that it detected eicar beautifully.
Not sure if that helps anyone?
Best Regards,
Andy
// Application Constants
var strClamAV = C:\\Program Files\\clamAV\\ClamDScan.exe;
// Get Command Line Parameter
if ( WScript.Arguments.Count() == 0 )
// nothing to scan
WScript.Quit();
var strPath = WScript.Arguments(0);
// Trim last backslash
if ( strPath.substr( strPath.length - 1 ) == \\ )
strPath = strPath.substr( 0, strPath.length - 1 );
// Run ClamAV
var objShell = new ActiveXObject(WScript.Shell);
WScript.Echo( Launching: + strClamAV + + strPath );
var objExec = objShell.Exec( strClamAV + + strPath );
var strLine;
var nSeperator, nFound;
var bHaveFound = false;
while ( !objExec.StdOut.AtEndOfStream )
{
// Process ClamAV Output
strLine = objExec.StdOut.ReadLine();
if ( bHaveFound )
continue;
nFound = strLine.indexOf( FOUND );
if ( nFound 0 )
{
nSeperator = strLine.indexOf( : );
if ( nSeperator 1 )
continue;
// Appears to be a possible virus report
bHaveFound = true;
WScript.Echo( Reporting: + strLine.substring( 0, nSeperator
) + FOUND + strLine.substring( nSeperator + 2, nFound ) );
var objFS = new ActiveXObject(Scripting.FileSystemObject);
objTS = objFS.CreateTextFile( Report.txt ); //
Create Declude Report File
objTS.WriteLine( strLine.substring( 0, nSeperator ) + FOUND
+ strLine.substring( nSeperator + 2, nFound ) );
objTS.Close();
}
}
// Wait for completion to be able to obtain exit code
while ( objExec.Status != 1 )
WScript.Sleep(100);
WScript.Echo( strClamAV + returned: + objExec.ExitCode );
WScript.Quit( objExec.ExitCode );
#
This message is sent to you because you are subscribed to
the mailing list sniffer@sortmonster.com.
To unsubscribe, E-mail to: 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: Announcing ClamAID - Clam AV installer for windows.
They offer a ClamAV tie-in: http://sssolutions.net/ew/tutor.php?topic=setup From: Message Sniffer Community [mailto:snif...@sortmonster.com] On Behalf Of Pete McNeil Sent: Monday, February 02, 2009 2:53 PM To: Message Sniffer Community Subject: [sniffer] Re: Announcing ClamAID - Clam AV installer for windows. Hello Steve, Monday, February 2, 2009, 2:31:17 PM, you wrote: Any plans on an eWall version? We may look into that -- however, eWall is a very fast, lightweight solution; SNF is easily fast enough to work during the SMTP conversation; Clam AV is decidedly not that fast. It might not be a good fit to put Clam AV in an SMTP proxy. SNF will reject most email borne malware seen within eWall. None the less, we will look into it-- I'm sure Clam AV could be scripted into eWall-- perhaps only running on those messages that don't get rejected up-front. _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: 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: ASSP Threshold
Hi Pete, Then let me approach it from a different angle: Is there a way in the Sniffer config files to silence certain groups? This way, if someone doesn't want to outright block email based on certain groups, they could just exclude those groups from triggering at all. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, October 17, 2008 12:41 PM To: Message Sniffer Community Subject: [sniffer] Re: ASSP Threshold Hello Andy, Thursday, October 9, 2008, 3:28:44 PM, you wrote: Hi: The design of the plugin at the moment is a binary decision-- either the message is spam, or not. I understand - but currently the plugin has a config option that performs a Resultcode = Threshold test. I think it would be more appropriate to have a Resultcode in (n, n, n...) test. It doesn't affect the logic and doesn't add more complexity Actually, this would add some complexity. The vast majority of folks currently treat all nonzero SNF results the same. ASSP 2.0 is new and the API doesn't yet provide the flexibility to multiplex results from plugins -- Perhaps we missed it or perhaps that will change. At this time we will keep things as they are. Once a few people are using the plugin and we have some feedback then we will be able to consider upgrades. Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: SNF Now directly supported in IMGate!
Hi, Hopefully, you'll be able to convince Alligate and ORF next to use your new DLL API to scan the content during the SMTP connection without needing the command line environment... Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, October 09, 2008 12:12 PM To: Message Sniffer Community Subject: [sniffer] SNF Now directly supported in IMGate! Hello Sniffer Folks, Message Sniffer is now directly supported in Len Conrad's IMGate. IMGate + SNF allows you to move your spam filtering out in front of your mail server improving scalability, stability, and performance. Here are some links: http://www.imgate.net/?page_id=101 http://www.imgate.net/?page_id=111 Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] ASSP Threshold
Hi Pete, SNF code spam threshold (ASSP_SNF_Threshold) The SNF result code threshold that is considered spam. SNF result codes at this level or above will be considered spam for the purposes of ASSP scoring. The default value of 20 is good in most cases. Are the result codes these: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.R esultCodes If so, I don't think that this can be handled with a greater than type of threshold, since your list from 20 to 63 are not at all in order of severity (e.g., Caution is higher than Truncate, Experimental is higher than Malware etc.). I would say this parameter would have to be a comma-delimited list of result codes that you want to treat as Spam - or, if there is some confidence factor that Sniffer uses internally, then that could be translated into an ASSP score... Best Regards, Andy # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: ASSP Threshold
Hi: The design of the plugin at the moment is a binary decision-- either the message is spam, or not. I understand - but currently the plugin has a config option that performs a Resultcode = Threshold test. I think it would be more appropriate to have a Resultcode in (n, n, n...) test. It doesn't affect the logic and doesn't add more complexity - but would allow more control over what is rejected as SPAM on the same level as ORF (where you can configure which Resultcodes to block outright), albeit not quite as much as Declude. I would want to block some result codes outright during the connection (based on a resultcode list as in ORF) and allow other resultcodes (in which I have lesser confidence) to go through and be subject to other tests. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, October 09, 2008 3:01 PM To: Message Sniffer Community Subject: [sniffer] Re: ASSP Threshold Hello Andy, Thursday, October 9, 2008, 2:00:49 PM, you wrote: SNF code spam threshold (ASSP_SNF_Threshold) The SNF result code threshold that is considered spam. snip/ If so, I don't think that this can be handled with a greater than type of threshold, since your list from 20 to 63 are not at all in order of severity (e.g., Caution is higher than Truncate, Experimental is higher than Malware etc.). Strictly speaking, SNF doesn't really use a weighting or severity paradigm. SNF is a discrete logic system-- something either matches or it doesn't. There are different result codes for different rule groups but with few exceptions a match in any rule group is an accurate indicator of spam. Where the pattern matching engine crosses with the IP reputation system (GBUdb) the only result code you might not want to trust at the same level is the caution result -- but in most cases there is no meaningful distinction. I would say this parameter would have to be a comma-delimited list of result codes that you want to treat as Spam - or, if there is some confidence factor that Sniffer uses internally, then that could be translated into an ASSP score... I'm not sure what is possible with the plugin interface. The design of the plugin at the moment is a binary decision-- either the message is spam, or not. There is no way to say how spammy except to tune the plugin overall. Based on that limitation we ended up with a threshold. As a matter of convention, all nonzero SNF results indicate spam. The exception to this is when we create specialized rules. When we do this we usually code those rule groups with a symbol value (result code) at or below 10. For example, system specific white rules are usually coded to result code 1. After that there are really only 3 significant levels associated with SNF result codes. The caution result (40) _might_ be considered less certain that the other rules-- though the default tuning for the caution range is very conservative. The ordinary result codes for pattern matches are considered reliable. Finally, a truncate (20) result indicates that the IP reputation is so bad that there is no need to look at the contents. This result could be considered more certain than ordinary. --- With regard to the caution result - that can be tuned using the GBUdb parameters-- or it can even be turned off. That would leave the remaining result codes 20 and above which are all considered reliable. --- In the best world you would be able to translate any SNF result code to any weight you want but that doesn't seem possible in the ASSP plugin API. If it is then please let me know and I'll look into making that adjustment. That said though-- even when SNF users have the ability to translate SNF results individually, in practice they don't. There doesn't seem to be a need as each nonzero result is a very accurate indicator of spam. The one exception that some systems might find is the caution result and if that proves to be a problem they can turn off that result in the SNF configuration. Hope this helps, Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: Update Script - Replace WGET and GZIP with CURL
Hi Pete, Agreed, with WGET it gets quite a bit complicated (because it really doesn't understand the GZ format). That's why you currently have to override the filename, call it GZ, then call GZIP to unzip it. I've come to the conclusion that it's not worth the trouble with WGET (as you surmised, it would make the script more complicated - so forget that approach.) The reason to switch to CURL is that behaves like a true HTTP application with GZIP support. You don't need to ship an extra GZIP on top of WGET in your distribution. CURL requests your file from your server, asks for it to be GZ compressed during transport, receives it, decompresses it before saving it - and sets timestamp from the server. All that in ONE command. Basically, you would replace these TWO lines in your current script: wget http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -O %RULEBASE_PATH%\%LICENSE_ID%.new.gz --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m if exist %RULEBASE_PATH%\%LICENSE_ID%.new.gz gzip -d -f %RULEBASE_PATH%\%LICENSE_ID%.new.gz with this single line: curl http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -R -o %RULEBASE_PATH%\%LICENSE_ID%.new -z %RULEBASE_PATH%\%LICENSE_ID%.snf --compressed -u sniffer:ki11sp8m Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, October 08, 2008 1:36 AM To: Message Sniffer Community Subject: [sniffer] Re: Update Script - Choice of WGET Parameter Prevents TimeStamping Hello Andy, Wednesday, October 8, 2008, 1:13:50 AM, you wrote: Hi Pete, Thanks for giving it your consideration. If you decide to revise these parameteres, then it will require an extra command in your script (because the WGET command will output the compressed file as .SNF). There is actually a bit more to it than that -- The existing script generally works even though it doesn't preserve the servers's timestamp because: 1. It is usually triggered from the SNFServer when SNF detects a newer rulebase file. 2. Any rulebase fill recently downloaded is guaranteed to be newer provided the local server's clock is correct (or close to it). Also -- are you saying that with the parameters you've provided WGET would decompress the file on it's own so that we wouldn't need to do that in our script? If so, how does it know for sure where to find GZIP? If not then it would be a little dangerous to have a .snf file around that looked correct but was in fact not yet decompressed. Another consideration is that if the file name is going to collide with the existing rulebase file we would want to move that into another location so that we don't stomp the existing rulebase file until we've tested the new one. It would be preferable to use WGET since there's nothing wrong with it and we've been using it long enough that most SNF folks already have it. That doesn't mean you shouldn't provide an alternate script that works with CURL just in case someone has a preference. Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Rulebase, bogus UTC Timestamps?
Hi Pete, I'm running a Sniffer service on a secondary system so that I can test my rulebase update script. After I changed to curl (to maintain the server timestamps), I'm now seeing the following in the status.minute.log: rulebase utc=20081008183610 / active utc=20081008183610 / update ready=no utc=20081008143610 / The update ready note matches the timestamp of 2:36 PM of actual rulebase SNF file. Which is correct, because when it downloaded from your server at 11:35 AM EDT, your server presented this HTTP header: Date: Wed, 08 Oct 2008 15:33:44 GMT Server: Apache/2.0.46 (Red Hat) Last-Modified: Wed, 08 Oct 2008 14:36:10 GMT ETag: 3ec4df2-cb96c0-458bed6588a80 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Transfer-Encoding: chunked Content-Type: application/x-sortmonster But, how is the rulebase and active UTC determined? Where is this 18:36:10 coming from. It seems to me as if somehow Sniffer adjusted the (already) GMT time of 14:36 by yet ANOTHER 4 hours, giving it a fantasy timestamp of 18:36. The net effect appears to be that my test machine doesn't get an UpdateReady.txt until 4 hours have passed. My improved getRulebase.cmd works perfectly, but it will only get launched every four hours, at best. Best Regards, Andy
[sniffer] Re: Updated getRuleBase.cmd
Hi, Yes, recent Windows curl builds will convert between UTC and local time. I was just caught off-guard, that Sniffer is using an external datum which is subject for wanted or unwanted manipulation for something as crucial as determining the file version of the rule base? If (due to copying files between servers) a sniffer file has a bogus file date, Sniffer would actually rely on that and be thrown out of whack? I would have expected that the SNF file was self-contained (e.g., contained an internal version id or timestamp) so that it was not subject to outside interference. Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, October 08, 2008 1:30 PM To: Message Sniffer Community Subject: [sniffer] Re: Updated getRuleBase.cmd Hello Andy, Wednesday, October 8, 2008, 12:52:59 PM, you wrote: Hi, After resolving the issues with UTC vs. local time (apparently the Sniffer service doesn't actually use a version identifier inside the SNF file, but relies on the Windows file date to determine what rulebase version is in place), here the updated getRuleBase.cmd. snip/ 1. Get the latest CURL.EXE for Win 2000 or higher from http://curl.haxx.se/latest.cgi?curl=win32-nossl-sspi http://curl.haxx.se/latest.cgi?curl=win32-nossl-sspi (don't use older builds to avoid timezone issues). Does this resolve the timestamp issues you indicated in your previous message? SNF gets the timestamp from the file system the using gmtime() of the modification timestamp on the file. The same call is made in the SYNC server software when the rulebase timestamp is provided to the SNF node for comparison. gmtime() provides the UTC time (used to be known as GMT) for any timestamp. _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC.
[sniffer] How to deal with False Positives and other Documentation Issues
Hi, 1. I read this page: http://www.armresearch.com/support/articles/procedures/falsePositives.jsp and it seems to be the same. However, should this chapter be expanded to contain information about what to do if some of the new technologies are responsible for the false positive? The panic rule instructions don't really apply in cases like this where there IS no rule: s u='20081007153730' m='D:\IMail\spool\proc\work\D822c0199026c.smd' s='20' r='0' p s='0' t='0' l='10306' d='0'/ g o='0' i='207.45.161.16' t='u' c='0.226425' p='1' r='Truncate'/ /s Instead you should have some ready-made sample that shows how to except an IP that has ended up on the Truncate list, or at least move it to the caution list? 2. The explanation of the Log files is incomplete: http://www.armresearch.com/support/articles/software/snfServer/logFiles/acti vityLogs.jsp As you can see from the log snippet I posted, there is a node s:r=0. However, s:r is not in the documentation. Best Regards, Andy
[sniffer] Re: GBUdb False Positives vs. Rule IDs
Hi Pete, You can drop the record for the IP from GBUdb with SNFClient -drop IP, but if the system is not configured properly then the IP will quickly rise back into the truncate list. The IP address in question was a third party IP address, not related to us, not a gateway. It was not in the ignore list and shouldn't be - does that qualify as configured properly? If that is being caused by a pattern rule then you need to discover the pattern rule from logs first and then panic that rule and report the FP. Hm - so if we have such a GBUdb FP issue, we would need to first go into the log for the message ID in question and locate the IP address. THEN, we have to search the log files to find where this IP address may have occurred (possibly several days of logs, before someone noticed legitimate email from being missing) in hopes of eventually still finding some log entry that relates to the original rule-ID, before we can add it to the panic list? I suppose it would be technically impossible to include the underlying rule in the GBUdb, so that it can be properly reported when messages are blocked? Are you reporting such an FP? Yes, your FP support identified the underlying rule and reported it back to me. Of course, I need to have a panic procedure in place that doesn't rely on outside assistance. Doesn't happen often, but better ask the questions now than when the brown matter hits to air circulation enhancer. Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, October 07, 2008 1:59 PM To: Message Sniffer Community Subject: [sniffer] Re: How to deal with False Positives and other Documentation Issues Hello Andy, Thanks for this -- I will address the documentation issues shortly. Regarding GBUdb FP issues-- to date we've not had a truncate (result code 20) false positive report from any system that was configured properly. Are you reporting such an FP? Depending upon the circumstances you may want to add the IP to your ignore list. You can drop the record for the IP from GBUdb with SNFClient -drop IP, but if the system is not configured properly then the IP will quickly rise back into the truncate list. If that is being caused by a pattern rule then you need to discover the pattern rule from logs first and then panic that rule and report the FP. Hope this helps, _M Remainder for reference... Tuesday, October 7, 2008, 12:58:43 PM, you wrote: Hi, 1. I read this page: http://www.armresearch.com/support/articles/procedures/falsePositives.jsp http://www.armresearch.com/support/articles/procedures/falsePositives.jsp and it seems to be the same. However, should this chapter be expanded to contain information about what to do if some of the new technologies are responsible for the false positive? The panic rule instructions don't really apply in cases like this where there IS no rule: s u='20081007153730' m='D:\IMail\spool\proc\work\D822c0199026c.smd' s='20' r='0' p s='0' t='0' l='10306' d='0'/ g o='0' i='207.45.161.16' t='u' c='0.226425' p='1' r='Truncate'/ /s Instead you should have some ready-made sample that shows how to except an IP that has ended up on the Truncate list, or at least move it to the caution list? 2. The explanation of the Log files is incomplete: http://www.armresearch.com/support/articles/software/snfServer/logFiles/act ivityLogs.jsp http://www.armresearch.com/support/articles/software/snfServer/logFiles/acti vityLogs.jsp As you can see from the log snippet I posted, there is a node s:r=0. However, s:r is not in the documentation. Best Regards, Andy -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: GBUdb False Positives vs. Rule IDs
Thanks Pete - I'll save that command. I also suggest that some of your instructions might be helpful to see in the documentation in the chapters on how to deal with false positives. From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, October 07, 2008 3:41 PM To: Message Sniffer Community Subject: [sniffer] Re: GBUdb False Positives vs. Rule IDs Hello Andy, Tuesday, October 7, 2008, 2:40:01 PM, you wrote: Hi Pete, You can drop the record for the IP from GBUdb with SNFClient -drop IP, but if the system is not configured properly then the IP will quickly rise back into the truncate list. The IP address in question was a third party IP address, not related to us, not a gateway. It was not in the ignore list and shouldn't be - does that qualify as configured properly? Yes. If that is being caused by a pattern rule then you need to discover the pattern rule from logs first and then panic that rule and report the FP. Hm - so if we have such a GBUdb FP issue, we would need to first go into the log for the message ID in question and locate the IP address. THEN, we have to search the log files to find where this IP address may have occurred (possibly several days of logs, before someone noticed legitimate email from being missing) in hopes of eventually still finding some log entry that relates to the original rule-ID, before we can add it to the panic list? Yes-- more or less. It's not as bad as it seems though. In order for an IP to get into the truncate range in GBUdb it has to consistently send messages that match pattern rules. That is 95% of the time if a message is sent from this IP it matches a pattern rule AND it has to send a bunch of them. If the messages come in over separate days the statistics condense every day -- so on any given day it is likely a number of messages would have to come in and match pattern rules. That means that a message matching the offending pattern rule is likely to be listed in the same log file and previous days (if any). It also means that if you find that IP in that log you are virtually guaranteed that the message you find will have either matched the pattern rule or been truncated. In this case the probability figure is 1 indicating that all messages from this IP have matched pattern rules. GBUdb override results (caution, black, truncate) do not change IP statistics... so the only way for an IP to get into the truncate range is by consistently producing messages that match pattern rules. Presumably if substantially all messages from this legitimate source were to be tagged as spam then they would be reported as false positives. Even if they were not immediately reported as false positives then the daily condensation of GBUdb statistics would force the IP out of the truncate range until more messages were tagged by the pattern rule -- and presumably one or more of those would be reported as false positives. Bottom line -- it should not be difficult to find log records associated with this IP that are also associated with the pattern rules that pushed it into the truncate range. I suppose it would be technically impossible to include the underlying rule in the GBUdb, so that it can be properly reported when messages are blocked? Yes. The GBUdb engine only stores the statistics about the IPs and the data needed to index and access these records quickly. However, as I've said, information on the pattern rules should be relatively easy to find -- especially for truncate cases. Are you reporting such an FP? Yes, your FP support identified the underlying rule and reported it back to me. Of course, I need to have a panic procedure in place that doesn't rely on outside assistance. Doesn't happen often, but better ask the questions now than when the brown matter hits to air circulation enhancer. This case is somewhat unique. The pattern rule has been around for a very long time -- so it is extremely unlikely that a similar case would arise again. A short-term and immediate fix for such a case -- while figuring out what is really going on -- is to reset the statistics on the IP so that they are not in the truncate range and so that it would take a large effort to get them there. For example, you could SNFClient -set IP ugly 0 32 This would move the IPs statistics far toward the white so that a truly large number of hits would be required to push it back into truncate even if every message failed a pattern rule. In the mean time the IP would be in the normal range. This gives you immediate relieve with a fire and forget command. The GBUdb statistics for the IP will eventually return to the correct value for the IP and by the time that happens you will have resolved the underlying pattern rule issue or made some other decision regarding the IP. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm
[sniffer] Re: Update Script - Choice of WGET Parameter Prevents TimeStamping
PS: And, for bonus points, to correctly support your sub-directory feature in your sample script, you would do that with the -P parameter, e.g.: wget http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -N -P %RULEBASE_PATH% --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 12:41 AM To: 'Message Sniffer Community' Subject: Update Script - Choice of WGET Parameter Prevents TimeStamping Hi, I've spent some time over the last few days trying to integrate the new sniffer update scheme into my current scripts and kept hitting a wall because the update script was downloading the rulebase file with the CURRENT date/time instead of your webserver's date/time. In the past I had used CURL instead of WGET, but I'm trying to stick with the provided samples, the best I can (to make future upgrades easier). I finally figured out why the downloaded files were timestamped incorrectly (and why the conditional download that I had working with CURL was not working with WGET. The reason was your choice of WGET parameters in your sample. You currently are using: wget http://www.sortmonster.net/Sniffer/Updates/(licensecode).snf -S -O (licensecode).snf --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m However, the -O parameter is not an output file parameter, but rather an OVERRIDE parameter intended for cases where MORE than one file is downloaded from the server. The '-O' parameter allows you to combine ALL these downloaded files into a SINGLE file. Since all files are combined into one large file, the file date is simply set to the current time. Clearly, this entire scenario does NOT apply to the rulebase download! Worse, this overrides the normal handling of downloads, where the output filename is controlled by the server AND the timestamp of the local file would be set to the Last-Modified header of your web server. The effect is, that the downloaded files have the wrong timestamp and thus will prevent employing a conditional download scheme in cases where the local file already exists with the correct size and timestamp. The normal command (and the one intended for YOUR application) would be: wget http://www.sortmonster.net/Sniffer/Updates/(licensecode).snf -S -N --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m This will: a) Download the file, maintain the filename and (by omitting the -O) inherit the original timestamp from the web server -as it should be. b) The -N parameter will further improve the situation. If the local file already exists with the correct file size and time stamp, then an unnecessary download will be skipped! Again, I know, that you are only providing your script as a sample - but, the closer your sample tracks reality the fewer customers will see a need to adapt it and thus reducing YOUR tech support effort if the customer modifications lead to errors. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206
[sniffer] Re: Update Script - Choice of WGET Parameter Prevents TimeStamping
Hi Pete, Thanks for giving it your consideration. If you decide to revise these parameteres, then it will require an extra command in your script (because the WGET command will output the compressed file as .SNF). If you don't insist on using WGET, then CURL (also free/open software) actually has more flexible parameters that will simplify your script because it will let you compare the timestamp of the unzipped, local .SNF file against the server timestamp, e.g.: curl http://www.sortmonster.net/Sniffer/Updates/(licensecode).snf -o (licensecode).snf.gz -s -S -R -z (licensecode).snf -H Accept-Encoding:gzip -u sniffer:ki11sp8m Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, October 08, 2008 1:03 AM To: Message Sniffer Community Subject: [sniffer] Re: Update Script - Choice of WGET Parameter Prevents TimeStamping Hello Andy, Wednesday, October 8, 2008, 12:50:23 AM, you wrote: PS: And, for bonus points, to correctly support your sub-directory feature in your sample script, you would do that with the -P parameter, e.g.: wget http://www.sortmonster.net/Sniffer/Updates/%LICENSE_ID%.snf -N -P %RULEBASE_PATH% --header=Accept-Encoding:gzip --http-user=sniffer --http-passwd=ki11sp8m snip/ Thanks for your help. We have to cover a lot of ground so we often get solutions from our customers and others that just want to help out. We do our best to test and edit. I will see that your suggestions / corrections are reviewed and included in our updates. In any case they will be in the mailing list archives ;-) THANKS! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: Update Script - Path apparently doesn't tolerate embadded blanks
Hi Pete: http://www.armresearch.com/support/articles/software/snfServer/config/node /network/update-script.jsp http://www.armresearch.com/support/articles/software/snfServer/config/node/ network/update-script.jsp%3c%3c Yep, had read that - but that page just instructs me to use the full path, which I did. Does NOT tell me that the Windows platform requires to quote the string or use DOS style paths - or, how to test if the script will launch and, if not, where to see the return codes that the service encounters. I had looked through your log files and I expected to see some XML row similar to: MMDD HHMMSS: Update Script %1 launched. RC=%2 - but didn't. Knowing how to trigger it manually is good to know - thank you for sharing this. In this case, it still wouldn't have helped me debug the problem, since neither the fact THAT a call had occurred at all and the return code apparently were being logged. We are considering some features for the next minor upgrade to help test this feature such as the ability to trigger it and a log entry that returns whatever system() returned (that will have to be interpreted by the user according to their platform's documentation for that call). I think that would be necessary. Everything in call= is passed to system() as a string. As you know, there are a few different ways to launch programs in Windows - some of them accept a full path as a separate parameter (spaces allowed). I don't think it's safe to assume that your customers would know which function call you had chosen, and to predict what its limitations might be. Some of us are Win32 API programmers - many probably aren't. I really don't have a problem with either including the string in quotes or using DOS style paths, etc. - it's just that there was nothing helpful in the product or documentation that would have lead me to conclude that either before or after it didn't work. Thanks again for your time and consideration. Best Regards, Andy
[sniffer] Update Script - Path apparently doesn't tolerate embadded blanks
Hi Pete, Found a bug (I think): update-script on-off='on' call='D:/Program Files/SNF/getRulebase.cmd' guard-time='180'/ With THIS configuration, the script apparently gets never launched. What's particularly disturbing is, that I didn't find any place where the service reports/logs any errors about the update process? I had tested the script itself (by copying and pasting the string directly to the commandline), and thus knew it worked - but never thought about checking whether the .SNF file was actually updating. Once I realized that the timestamp of the .SNF file never advanced over the course of a day. After spending some time, trying to narrow down the problem but not finding any diagnostic info, I eventually decided to eliminate spaces from the path: update-script on-off='on' call='D:/Progra~1/SNF/getRulebase.cmd' guard-time='180'/ and now it DOES seem to work. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206
[sniffer] Sniffer 3.0 Installed
:DONE ENDLOCAL Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206
[sniffer] Re: Sniffer 3.0 Froze Mail Server
Ouch - 3.0 didn't even last 12 hours. Imail was frozen up because it apparently couldn't launch any more Sniffer client instances. Event Log was full with: Event Type:Information Event Source:Application Popup Event ID: 26 Description: Application popup: SNFClient.exe - Application Error : The application failed to initialize properly (0xc142). Click on OK to terminate the application. Had to manually kill a HUGE multiple list of imailsrv.exe's (taskkill /im imailsrv.exe /f ) and a similar long list of SNFClient.exe's. Normally, this Imail Server runs unattended for weeks until a Windows security update requires reboot! Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Saturday, October 04, 2008 2:13 AM To: Message Sniffer Community Subject: [sniffer] Sniffer 3.0 Installed Hi, Didn't realize I had been uninstalled for a few months. I saw that V3 was released, so I gave it a shot. I unzipped the installation files to a new /SNF folder. All files were expanded into the same folder (your zip file had not subfolders!). Following the instructions I customized the XML files. I noticed THESE parameters: node identity='D:/IMail/declude/SNF/identity.xml' paths log path='D:/IMail/declude/SNF/Log/'/ rulebase path='D:/IMail/declude/SNF/Rulebase/'/ workspace path='D:/IMail/declude/SNF/Workspace/'/ /paths I'm a believer in keeping different data in their distinct subfolders, so I set up the /Log, /Rulebase and /Workspace subfolders by hand and updated the XML file. The I took a wild guess that SOME files would have to be moved into those subfolders - but there are NO instructions WHAT files go WHERE for things to actually work! I found it annoying that further down in the same XML File was yet another path that was NOT included in the paths node in the top of the XML file: update-script on-off='on' call='D:/IMail/declude/SNF/getRulebase.cmd' guard-time='180'/ Next I had to customize the getRuleBase.cmd - because it too does NOT support the use of the rulebase/workspace paths. Here was yet ANOTHER place where I had to manually configure the same path information again, as well as the license key. Needless to say, I'm not a friend of having redundant path information in several locations as this is an unnecessary source of error. Through testing I determined that some more files had to be moved to certain sub folders for things to work: UpdateReady.txt - /Workspace GBUdbIgnoreList.text - /Workspace Your .SNF - /Rulebase Then I had to further adapt the getRuleBase.cmd because throughout this procedure, you need to prefix references to the rulebase and the UpdateReady.* files with the appropriate paths for things to actually work. At this point, I'm still no clear where the mingwm10.dll, exchndl.dll and AuthenticationProtocol.swf need to reside! I didn't move them, but I'm not sure if that creates a problem down the road. Here are my suggestions: a) Snf_engine.xml should have one ApplPath parameter where I can just define 'D:/IMail/declude/SNF'. Unless I OVERRIDE any of the other paths, it should know the that by default the other paths are all assumed to be below the ApplPath and no extra parameters are necessary: identity.xml getRulebase.cmd Log/ Rulebase/ Workspace/ b) There should be a simple command line utility (e.g., SNFClient.exe -Paths) to automatically create Environment Variables for the paths. This way, this command can just be included at the beginning of the getRuleBase script and one doesn't have to manually hardcode those same paths into yet another location. PS: Here is my corrected version of the getRuleBase CMD file that looks for the files in the correct subfolders: @ECHO OFF SETLOCAL REM - Edit This Section SET SNIFFER_PATH=D:\IMail\declude\SNF SET RULEBASE_PATH=%SNIFFER_PATH%\Rulebase SET WORKSPACE_PATH=%SNIFFER_PATH%\Workspace SET AUTHENTICATION=authenticationxx SET LICENSE_ID=licenseid REM CD /d %SNIFFER_PATH% if not exist %WORKSPACE_PATH%\UpdateReady.txt GOTO DONE REM The next line may cause trouble if your system stops while this REM script is running. It is not needed when this script is run REM from SNF's update-script/ feature since only one copy will run REM at a time. However, if you are going to run a version of this REM script as a scheduled task you will want to uncomment the next REM line to make sure only one copy runs at a time-- just be sure to REM clean out any stale .lck files after a restart. REM if exist %WORKSPACE_PATH%\UpdateReady.lck GOTO DONE :DOWNLOAD COPY %WORKSPACE_PATH%\UpdateReady.txt %WORKSPACE_PATH%\UpdateReady.lck wget
[sniffer] Re: Sniffer 3.0 Installed
Hi Pete, My best thinking at the moment is to perhaps do something like this Right, exactly. As long as the parameters are already there to be modified and the script uses those parameters, then the script is ready to go for any user (with or without distinct directories). Of course doing that would mean rewriting our installer too (Since it needs to modify/generate the getRulebase script. Yes, if you want the installer to handle the subdirectory layout, then it would have to adapt the additional two lines in the getRulesbase script - which would make it more flexible to deal with different customer scenarios. Best Regards, Andy From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, October 04, 2008 3:52 PM To: Message Sniffer Community Subject: [sniffer] Re: Sniffer 3.0 Installed My best thinking at the moment is to perhaps do something like this: REM - Edit This Section - SET LICENSE_ID=licenseid SET AUTHENTICATION=authenticationxx SET SNIFFER_PATH=D:\IMail\declude\SNF REM Modify the next two lines if you modify SNF's directory structure. SET RULEBASE_PATH=%SNIFFER_PATH% SET WORKSPACE_PATH=%SNIFFER_PATH% REM - Of course doing that would mean rewriting our installer too (Since it needs to modify/generate the getRulebase script. For the immediate future this discussion is archived and searchable and I will add a task to the web site project to describe some of these getRulebase.cmd scenarios. How does that sound? _M
[sniffer] Re: FW: [sniffer] Re: Sniffer 3.0 Froze Mail Server
Hi Pete, Well, I eliminated WeightGate for the time being, just to do my due diligence. Also, since there is a fix sized buffer, I assume actually LOWERING the 3rd number (the allocation for each non-interactive process) would allow for MORE parallel processes to run (as long as the value is still large enough to support each of the applications that rely on it.) Of course, I assume the heap issue in reality is actually a SECONDARY problem ( a symptom of too many non-interactive tasks being launched and not completing). Since the 'heap' space is finite, there is a hard limit as to how many processes can be in a wait state at the same time. The problem to focus on is not the known, limited heap, but rather the reason why these processes were unable to complete and thus eventually too many processes being active. Best Regards, Andy From: Pete McNeil [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2008 10:07 PM To: Andy Schmidt Cc: [EMAIL PROTECTED] Subject: Re: FW: [sniffer] Re: Sniffer 3.0 Froze Mail Server Hello Andy, Saturday, October 4, 2008, 9:22:39 PM, you wrote: Hi Pete, Here the log files. I can't tell you WHEN the problem was triggered. I was off site and was alerted around noon that the SMTP service had become unresponsive. I assumed it had crashed, but found it running. Thus I tried restarting the SMTP service, but after shutting down, it wouldn't allow me to restart. That's when I started looking a bit more closely. Once I realized that I had all these SNFclient processes running (I checked the event log to see if it would give me any clue - but since the errors had been occurring for a while, my system event log had wrapped around, so I couldn't tell when it actually started and how long it may have taken between the actual problem and until the SMTP service became unresponsive. This Imail server is a PowerEdge 2950, Quad CPU, 3GHz. 2 GB of RAM and normally using about 1.5 GB of virtual RAM and on weekends, CPU load is usually below 10%. When this was going on, I didn't pay close attention because I wasn't quite sure yet what was going on and was trying to figure out how to get out of it. But, based on the memory use graph, I would guess it had maxed out 4 GB of virtual RAM, which eventually starved the SMTP service and prevented it from accepting more connections.. As soon as I flushed the command line programs, the memory curve dropped very sharply by easily half. Sorry - don't have anything more specific. I've been watching your telemetry and I don't think the problem was triggered by an ordinary overload. Your message rate is not high enough to cause that -- SNFClients will only wait about 30 seconds or so at most if they are unable to make contact - - even on the busiest systems. The other thing that strikes me is that you had to kill a lot of imailsrv.exe instances as well-- this is new and very different. Once the mystery heap was exhausted I would expect SNFClient instances to build up in a broken state (0x142) but there is no good reason for imailsrv instances to build up that I can think of -- except maybe some kind of list processing event? (IIRC, imailsrv is called to handle list processing requests through an alias -- it's been a while). I will check the SNF log to see if I can identify anything useful. Thanks, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC.
[sniffer] Imail QueueMgr.exe consumes all Paged Pool
Sorry for cross-posting. I'm not sure whether Declude and/or Sniffer still rely on the Paged Pool - and whether their usage would be reported under the Imail QueueMgr.exe or under some other .exes? So I have 3 possible culprits. The symptom started as a Webmail problem because customers noticed they couldn't send emails any longer due to Bad Socket State. However, when I log into the physical machine, the REAL problem is that I cannot open ANY TCP/IP connections to any IP address (on that same machine or on neighboring machines). I can still PING (is ICMP works), but TELNET, FTP, HTTP - all are unable to create a socket. FTP.exe reported that it doesn't have enough buffer space. That caused me to turn on Task Manager and add the columns for VM Size and Paged Pool. Normally, the various processes only use less than 100K of Paged Pool - even the IIS Web Process uses only 300K. However, QueueManager was up to 4500K. Restarting QueueMgr.exe service reset it to 200K or so. But, I there are time spans where it consumes an extra K every second - now already up to 800 K again - before it levels off for a while and then keeps doing it again. Oddly enough, this problem only started yesterday - even though 2006.21 has been running since 7/16/2007 - and now seems to accelerate (happened twice today!) My obvious suspicion is that there is a 'certain' email or type of spam that's causing this QueueMgr behavior - what else would account for this to start happening NOW.
[sniffer] Re: Spam
I recommend SpamSource, if you are an Outlook user. It's a little toolbar applet that you can configure any recipient of the forwarded spam and it will include all the original mail headers - just the way Sniffer, Spamcop etc. like it. All you do is press the button on the toolbar and the message will be forwarded, deleted from your inbox and not even appear in your sent folder (all configurable). Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of David Moore Sent: Tuesday, May 29, 2007 4:54 PM To: Message Sniffer Community Subject: [sniffer] Re: Spam Long time in getting back to you about this but: preferably to a spam collection pop3 box on your system I am happy to send it to a box called [EMAIL PROTECTED] password sort!231#6eh will you arange for your bot to collect ? When I send spam to [EMAIL PROTECTED] in the past I have been laborusly opening the header, coping header content, forwarding email, past header content to beginning of email and sending is there a quicker way. If I send spam to [EMAIL PROTECTED] how would I stop our system from re tagging the email as spam from me. Regards David Moore [EMAIL PROTECTED] J.P. MCP, MCSE, MCSE + INTERNET, CNE. www.adsldirect.com.au for ADSL and Internet www.romtech.com.au for PC sales Office Phone: (+612) 9453 1990 Fax Phone: (+612) 9453 1880 Mobile Phone: +614 18 282 648 POSTAL ADDRESS: PO BOX 190 BELROSE NSW 2085 AUSTRALIA. - This email message is only intended for the addressee(s) and contains information that may be confidential, legally privileged and/or copyright. If you are not the intended recipient please notify the sender by reply email and immediately delete this email. Use, disclosure or reproduction of this email, or taking any action in reliance on its contents by anyone other than the intended recipient(s) is strictly prohibited. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, 14 May 2007 9:27 PM To: Message Sniffer Community Subject: [sniffer] Re: Spam Hello David, Monday, May 14, 2007, 2:59:16 AM, you wrote: Do not send spam to the sniffer@ list. Submit un-captured spam to [EMAIL PROTECTED], or preferably to a spam collection pop3 box on your system that can be picked up by our bots. Thanks! _M # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: How to incorporate a white list?
Hi Phil, Yes, it seems as if some Sniffer rules, e.g., 1367683, is broadly targeting Google's IPs. I've submitted 3 false positive reports since last night, at least two of them were Google users, one located in the U.S. and the other in the Netherlands! Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Cohen Sent: Tuesday, April 03, 2007 6:30 AM To: Message Sniffer Community Subject: [sniffer] How to incorporate a white list? I am getting a large number of false positives and not sure why. Mostly mail from newsletters or lists, such as DMXZone, but I am also still unable to receive some mail from my own internal users. I am filtering on a per mailbox right now and I have been sending spam from my mailbox into its own holding directory so I can see what I am missing. It appears that while it gets most spam there are also some real messages getting zapped as well. How do I add a whitelist of domains, or do i send in the false positives in hopes they will somehow be added to the rulebase. I am fairly new at this and it is not real obvious looking at the documentation online as to how this all works. This is running on an old vopmail server. Thanks, Phil # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: How to incorporate a white list?
Hi, Unless I'm mistaken, rule 1370762 was targeting the same address range. If I may make a suggestion: Before the spam-trap robots are allowed to block major, well-known and easily recognizable email providers, how about the robot script pulls a WHOIS and a Reverse DNS and runs that data against a table of can't block entities - or at least spits those out for human review. If that can't be done, then how about the robots issue an hourly report of suspect IPs. A no-brainer script can pull matching WHOIS and RevDNS for quick human review and overriding (if necessary). I would rather those obvious bad rules are caught before or very quickly after they go live. There is always some delay before I get first reports until I realize that this is a real problem. Then I have to try to get headers from end-users before I can dig into logs... Hours and hours pass (especially if it's overnight events). In the meantime the problem escalates all around me. Thanks, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, April 03, 2007 11:09 AM To: Message Sniffer Community Subject: [sniffer] Re: How to incorporate a white list? Hello Andy, Tuesday, April 3, 2007, 9:36:17 AM, you wrote: Hi Phil, Yes, it seems as if some Sniffer rules, e.g., 1367683, is broadly targeting Google's IPs. I've submitted 3 false positive reports since last night, at least two of them were Google users, one located in the U.S. and the other in the Netherlands! This IP rule has been pulled. FP processing will happen shortly. _M # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: How to incorporate a white list?
Hi Pete, Thanks for taking the time to respond. The rule was in place from 20070326. The first reported false positives arrived today Except that reports from end users lingered in my email since Friday. Not your fault - but just to better demonstrate the ultimate effect it had. To be certain, I wasn't dissatisfied with your reaction time after I finally got around to looking at the user reports and compiling reports to you. My argument is, that for big email providers, there could be procedures in place to identify possible bad rules and flag them for review without waiting for FP reports. To clarify, it was blocking precisely one IP. The F001 bot only tags a single IP at a time (not ranges, ever) Except that there were multiple rules (I remember seeing at least two) - and each one (if I recall correctly) targeting a different IP in the same block. Thus, the difference is merely technical (whether n rules are needed for n IPs or whether one rule covers multiple). Once upon a time, IP rules were created in very much the way you describe -- candidate IPs were generated from spamtraps and the live spam corpus and then reviewed (manually and automatically) against RevDNS, WHOIS, and other tools. At that time, IP rules had the absolute worst reliability of any test mechanism we provided. I can't follow the logic. If F001 would continue to be used (but certain IPs are reviewed), then this can't possibly increase the false positive rate. At worst, a rule may be prohibited unnecessarily... But that's our job - to err on the save side and let the GOOD mail go through. If we block good mail, then the system has failed the user. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, April 03, 2007 6:31 PM To: Message Sniffer Community Subject: [sniffer] Re: How to incorporate a white list? Hello Andy, Tuesday, April 3, 2007, 5:15:12 PM, you wrote: Hi Jonathan: That's exactly the problem. These particular rules were blocking Google mail servers - NOT specific content. To clarify, it was blocking precisely one IP. The F001 bot only tags a single IP at a time (not ranges, ever), and only after repeated appearances at clean spamtraps where the message also fails other tests (often including content problems like bad headers, obfuscation, heuristic scam text matching etc.) The rule was in place from 20070326. The first reported false positives arrived today (just after midnight). The rule was removed just less than 12 hours from that report (due to scheduling and heavy spam activity this morning that requiring my immediate attention). The report was ordinary (not a rule panic). As is the case with all FPs, the rule cannot be repeated (without special actions). Obviously, as already discussed in the past, it IS necessary that these IP-based blocks are put under a higher scrutiny. I'm not suggesting that the automatic bots should be disabled, I'm just proposing that intelligence must be incorporated that will use RevDNS and WHOIS to identify POSSIBLY undesirable blocks and to flag those for human review by Sniffer personnel so that they don't end up poisoning mail severs of all their clients. While interesting, these mechanism are not foolproof nor trivial to implement. Also - our prior research has taught us that direct human involvement in IP rule evaluation leads to far more errors we can allow. Once upon a time, IP rules were created in very much the way you describe -- candidate IPs were generated from spamtraps and the live spam corpus and then reviewed (manually and automatically) against RevDNS, WHOIS, and other tools. At that time, IP rules had the absolute worst reliability of any test mechanism we provided. Upon further RD, we created the F001 bot that is in place and now the error rate has been significantly reduced and our people are able to focus on things that computers can't do better. Please don't get me wrong, I'm definitely not saying that the F001 bot can't be improved - it certainly can, and will if it survives. What I am saying is that it is accurate enough now that any improvements in accuracy would be non-trivial to implement. Our current development focus is on developing the suite of applications and tools that will allow us to complete the alpha and beta testing of the next version of SNF*. That work has priority, and given that these events are rare and easily mitigated we have not deemed it necessary to make enhancements to the F001 bot a higher priority. The following factors make it relatively easy to mitigate these IP FP events (however undesirable): Rule panics can make these rules immediately inert, FP report/response times are sufficiently quick, The IP rule group is sequestered at the lowest priority so that it can easily be weighted lower than other tests. Also, it is likely that the F001 bot and IP rules group will be eliminated once the next SNF version is
[sniffer] Re: Documentation Problem
Hi, I was trying to learn about panic rules. I was on this link: http://kb.armresearch.com/index.php?title=Message_Sniffer.FAQ.FalsePositives #When_we_report_these_to_false.2C_what_kind_of_time_frame_should_excpect_for _a_response.3F Then I clicked on the rule-panic hyperlink, which tried to link to: http://kb.armresearch.com/index.php?title=Message_Sniffer.FAQ.FalsePositives #RulePanic - which appears to be a bad link? (Eventually I found that the CFG file is self-documented.) Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Rules for Large International ISPs
Hi, This morning I had to file to false positive reports because emails from Wanadoo.FR and UOL.COM.BR were triggering SNIFFER-IP. I don't know if this is a coincidence or if this is a worrisome new trend caused by someone new in this field how is now coding Sniffer rules without even a basic understanding the major players in this field. Needless to say, both Wanadoo and UOL are legitimate providers, in fact, they are some of the world's largest providers. They certainly are THE dominant providers in their respective (European / South American) markets. (For anyone subscribing to American Isolationism, it would be equivalent to Sniffer blacklisting the smtp relay servers of Google, Yahoo, AOL, etc.) Because of their market dominance, these relay servers are more likely to be abused by their customers - but that doesn't mean they can be black-listed. After all, they are THE major source of legitimate emails for their respective markets. Somebody's got to apply some common sense before coding these kind of rules. 20061228150347 16 0 Match 799799 63 1 48 75 20061228150347 16 0 Final 799799 63 0 174475 20061228110558 15 16 Match 1235160 63 1 46 73 20061228110558 15 16 Final 1235160 63 0 298073 Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: Rules for Large International ISPs
Hi Pete, Thanks. Let me apologize for the accusatory tone of my message. Someone pointed out to me that my annoyance made me cross the line of being offensive. I would suggest to add some intelligence to the bot F001, where it compares implicated address ranges against a table of excepted IPs, which you would build over time (or use some public sources of known-good IP ranges to get a start). I understand the reporting rate of false positives is low. But that may just be because most false positives simply are never reported. In my case, I couldn't use Sniffer to block outright - so for years I never worried much about false positives. Only very recently, I have tightened some weights AND I have improved the reporting to the point that it's now easier for me to spot certain false positives and have started to report them more consistently. Yet, I only review ONE out of a thousand mail boxes and many hundreds of domains - so chances are a large number of false positives are never even noticed by me on a daily basis (and I'm a very small operation). So - the FP rates might be misleading, because they only reflect REPORTED FPs - no one knows how tiny or possibly how huge UNREPORTED FPs might be. Consequently, it may be worthwhile to improve F001 as mentioned before. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, December 28, 2006 12:04 PM To: Message Sniffer Community Subject: [sniffer] Re: Rules for Large International ISPs Hello Andy, Thursday, December 28, 2006, 10:34:15 AM, you wrote: Hi, This morning I had to file to false positive reports because emails from Wanadoo.FR and UOL.COM.BR were triggering SNIFFER-IP. I don't know if this is a coincidence or if this is a worrisome new trend snip/ Our IP rule coding policies have not changed in quite some time and the false positive rates for IP rules have dropped significantly since the last change. IP rules are now coded only by a specialized bot which has very strict rules and looks only at clean spamtraps for recurring abuse. 20061228150347 16 0 Match 799799 63 1 48 75 20061228150347 16 0 Final 799799 63 0 174475 The above rule had been in place for 346 days without any false positive reports. The rule was coded by the previous robot and at the time was verified by 3 additional blacklists. 20061228110558 15 16 Match 1235160 63 1 46 73 20061228110558 15 16 Final 1235160 63 0 298073 This was coded by the new bot (F001) approximately 28 days ago - no prior false positives. IP rules are currently coded by the F001 bot based on direct, repeated observations at clean spamtraps. IP rules are excluded on the first false positive report so that they cannot be reactivated without direct human intervention. It is not practical for us to keep tabs on, nor deeply research every possible IP that may be used by any large (or otherwise) ISP. Instead we have the above policy and very strict observational rules to prevent the addition of IPs that are likely to produce significant legitimate traffic and to quickly and permanently remove IPs that cause false positives. (some exceptions, of course, apply). It is inevitable that there will be a nonzero error rate - but that error rate is demonstrably small given our current process, and we are constantly researching and developing techniques to improve on that rate. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: Declude header not modified correctly
Hi David, When I tried to use their ticketing system, I got an automated reply with a ticket number. After a lack of response, I called their support line, left a voice mail and also posted the ticket number to the Declude list - and was told that they couldn't find my ticket number in their own system... I have read about the lack of any response to open tickets in the past. Seem as if you'll have to escalate this by calling them - or make it a public issue by posting your tickets and the lack of response to the list (that triggered an immediate reaction in my case.) Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of David Waller Sent: Wednesday, October 25, 2006 09:42 AM To: Message Sniffer Community Subject: [sniffer] Re: Declude header not modified correctly Yes, we do it expires June 2007. Still waiting for a response for a support email sent on the 4/10/2006 with a kick-up-the-bum reminder sent on the 16/10 - only the initial automated response received so far. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Computer House Support Sent: 25 October 2006 14:11 To: Message Sniffer Community Subject: [sniffer] Re: Declude header not modified correctly David Waller wrote: they don't respond to support emails from this registered user... Dear David, I am curious to know if you have an active Service Agreement with Declude? Among the hundreds of vendors that I deal with, I found their support to be one of the best. I seldom wait more than an hour for a response. Michael Stein Computer House # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Re: Declude List
Hi, for discussions on Declude, you need to subscribe to "Declude.Junkmail" or "Declude.Virus" at [EMAIL PROTECTED] Here's their standard trailer line: 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. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Herb GuentherSent: Wednesday, October 25, 2006 10:06 AMTo: Message Sniffer CommunitySubject: [sniffer] Re: Declude header not modified correctly I have an active SA, I sent in some service requests and got a ticket number by return email, never a follow up. Then called in and a chap named Chris Asaro fixed the settings on our account so that I could download the correct version and was quite helpful with that. However, that does not solve the problem and all emails of examples and requests for status since 10/18/06 have gone unanswered.So, basically their answer was install the latest version, and beyond that nothing, not even a reply or a we are working on it and will have something to try on X. Out users are seeing hundreds of spam messages unmarked in their email boxes a day, and of course want to know why when it is identified as spam they are still getting it. I personally know that this has been an issue for at least a year. If I were a spammer I would sure code my emails to exploit this.Anyway, have used Declude for about 5 years as I recall and getting kind of to the end of the line.I also spent some time yet again on their web site, and do not see a discussion board or anything to discuss this issue there vs here.Herb
[sniffer] FW: Summary, Form #21539
Pete, I have the same concern. I have been submitting the below spam (possible Words virus) almost daily for more than week - yet, it still is not discovered. Am I submitting correctly? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- Received: from localhost [84.42.20.245] by hm-software.com (SMTPD32-8.15) id A759D33F0100; Wed, 23 Aug 2006 04:52:41 -0400 Message-ID: [EMAIL PROTECTED] From: Madalyn Boyd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Summary, Form #21539 Date: Wed, 23 Aug 2006 12:51:12 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0001_01C6C68F.CB4BC000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Declude-Note: Domain localhost returns a server failure for MX or A records. X-Declude-Note: Message failed WEIGHTFILTER test (line 63, weight 2) X-RBL-Warning: Failed HELOBOGUS, WEIGHTFILTER, WEIGHTSNIFFER [5] X-Declude: Version 2.0.6.10; D1759D33F010010D4.SMD from pppoe-54.dep.tver.ru [84.42.20.245] X-Declude: Triggered [5] HELOBOGUS, WEIGHTFILTER, WEIGHTSNIFFER X-Countries: RUSSIAN FEDERATION-destination Return-Path: [EMAIL PROTECTED] X-RCPT-TO: [EMAIL PROTECTED] Status: U X-UIDL: 456022130 From: Madalyn Boyd [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 04:51 AM To: [EMAIL PROTECTED] Subject: Summary, Form #21539 Refers to any fields that may be on an attached commercial invoice. Forward original invoice with attached invoice transmittal sheet to the contracting officer. --=_NextPart_000_0001_01C6C68F.CB4BC000 Content-Type: application/msword; name=Form21539.doc Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=Form21539.doc 0M8R4KGxGuEAPgADAP7/CQAGAAABKgAA EAAALAEAAAD+ACkAAAD/ ///spcEAcWAJBAAA+BK/EAAABgAA 2AgAAA4AYmpianFQcVAJBBYALhAAABM6AQATOgEA2AAA AAD//w8AAAD//w8AAAD//w8A AKQAAJIEkgQAAJIEkgQAAACSBAAA AJIEkgQAABQAAMwEAAC0CAcIBwgH CAcAAAwUBwAADIAFegkAAOwsBwAAFgAAAEIH QgcAAABCBwAAAEIHHQgdCB0I+QgAAAIA AAD7CPsI+wgAAAD7CPsI+wgAACQAAABmCgAA aAIAAM4MAACGHwkAABUAkgQdCAAA AAAdCB0IHQgdCB8J AACSBJIEQgcAAEIHAADbNAkAABYA AABpCGkIaQgdCAAAEJIEQgcAAACSBAAA AEIH+QgAAGkI HQgAAAD5CAAA aQgAAGkIkgQAAACSBAAA aQgAAABCBwAA ACAHAAAMEMujlT/AxgEAAAgHLQgAABYAAABpCAAA 7QgAAAwAAABKCQAAMHoJaQgAAABUDQAAAEMIAAAc VA0AAABpCAAA AFQNAACSBAAA AGkIAACEHQgdCGkIHQgdCAAA HQgdCB0I HwkfCQAAXwgAAAoA AB0IHQgdCAAA AHoJHQgdCB0IHQgAAIAF gAUAAACABQAAZAEAAOQGAAAkgAUAAACABQAAAIAF 5AYAAACmBAAAFLoEAAAOyAQAAAQAAACSBJIEkgQA AACSBJIEkgQAAAD/AAIADAEA
RE: [sniffer] IP Blacklist rules
Hi, Thanks. I will treat result code 63 with a combo filter so that any parallel hit with a regular RBL won't end up counting twice. That should take care of it. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 24, 2006 03:38 PM To: Andy Schmidt Subject: Re: [sniffer] IP Blacklist rules On Friday, February 24, 2006, 2:56:02 PM, Andy wrote: AS Hi, AS I'm realizing that some Sniffer rules amount to nothing more than IP AS blacklists. AS received:~+[nnn\.nnn\.nnn\.nnn] AS AS Are all sender IP rules properly grouped so that I can identify AS and ignore them by return code. I already use IP blacklists (and AS other means) to cross check Sniffer and add to my confidence AS value before a mail is finally blocked. AS I can't afford Sniffer to effectively double up those sender-IP tests. AS Ideally, Sniffer should perform content checking. Please review the result code explanations here: http://www.sortmonster.com/MessageSniffer/Help/ResultCodesHelp.html IP rules are coded to symbol 63. The voting system on each SNF node sees rules with lower symbol values as more fit, so the only time you will see a result code of 63 is when no other rule matches that message. You may want to reconsider ignoring this result code - there is added value. When an IP rule is in the SNF rulebase, it indicates that: * The rule is from a message that reached our spamtraps. * Additional algorithms were used to classify the IP as a spam source. * The source has been consistently and recently active and detected at our user's system. Inactive IP rules are forgotten after a short period. * There have been no false positives reported against the rule. We remove IP rules on the first FP case and place the rule in a problematic rule group so that it cannot be reinstated without a strict review. * No other rules in our system are currently identifying the associated message content. Though we do focus on content, it is clear that in some cases an IP is the most efficient indicator. Since most other blacklisting services focus on a broad spectrum of IPs, there is bound to be overlap between them and also with SNF IP rules. However the fact that the IP shows up in our system does carry some unique information about that IP (see above). We explicitly do not aggregate IP rules from other lists. We recognize that other IP black lists are used in spam filters along with SNF and we encourage that as well as the use of other tests. (Even though SNF encapsulates diversity in it's algorithms and continues to expand this diversity, the best filtering systems will always use as many useful mechanisms as possible.) Additionally, as we move forward, IP rules in the SNF ruelbase will be gathered by unique, sophisticated mechanisms such as wavefront detection and cross-feature source correlation, etc. As a result, IP rules found in the SNF rulebase will increasingly represent some unique characteristics not found in other IP lists. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] False Positive - no reaction?
Hi, I filed this false positive report a day ago and never heard back. Just trying to see if my emails are blocked again. Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 10:41 AM To: '[EMAIL PROTECTED]' Subject: License ID nwb655oh This message was a GIF image from one individual to another. Log Entries: nwb655oh20060219172434 DA9CC319600AA9394.SMD 31 360 Match 836625 61 2245238871 nwb655oh20060219172434 DA9CC319600AA9394.SMD 31 360 Final 836625 61 0 32767 71 Original Message: Received: from mailout08.sul.t-online.com [194.25.134.20] by hm-software.com with ESMTP (SMTPD32-8.15) id A9CC319600AA; Sun, 19 Feb 2006 12:24:28 -0500 Received: from fwd34.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1FAsIN-00064u-06; Sun, 19 Feb 2006 18:24:27 +0100 Received: from athome ([EMAIL PROTECTED] ]) by fwd34.sul.t-online.de with smtp id 1FAsIB-0X4oka0; Sun, 19 Feb 2006 18:24:15 +0100 Message-ID: [EMAIL PROTECTED] From: Bjoern Schmidt [EMAIL PROTECTED] To: Jochen Schug [EMAIL PROTECTED], Harald Mergard [EMAIL PROTECTED] Subject: Hier das Bild zu meinem Service-request Date: Sun, 19 Feb 2006 18:24:15 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0005_01C63581.B0813970 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ID: GWI0CrZ-Ye-ErQseZpWkpcMBFfC4ce2pefaSy9EIpXJHQ-BFOxDqQt X-TOI-MSGID: bdd1884c-5835-410b-822a-2343e2bb5047 This is a multi-part message in MIME format. --=_NextPart_000_0005_01C63581.B0813970 Content-Type: multipart/alternative; boundary==_NextPart_001_0006_01C63581.B0813970 --=_NextPart_001_0006_01C63581.B0813970 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ciao Bjoern Schmidt [EMAIL PROTECTED] www.barchetta.cc =20 Barchetta - The Classic and Sports Car Channel Updated News as It = Happens. --=_NextPart_001_0006_01C63581.B0813970 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=3DContent-Type content=3Dtext/html; = charset=3Diso-8859-1 META content=3DMSHTML 6.00.2900.2802 name=3DGENERATOR STYLE/STYLE /HEAD BODY bgColor=3D#ff DIVnbsp;/DIV DIVFONT face=3DArial size=3D2CiaoBRBjoern SchmidtBRA=20 href=3Dmailto:[EMAIL PROTECTED][EMAIL PROTECTED]/ABRA=20 href=3Dhttp://www.barchetta.cc;www.barchetta.cc/Anbsp;nbsp; = BRBarchetta -=20 The Classic and Sports Car Channel Updated News as It=20 Happens./FONT/DIV/BODY/HTML --=_NextPart_001_0006_01C63581.B0813970-- --=_NextPart_000_0005_01C63581.B0813970 Content-Type: image/gif; name=Neues Projekt erstellen.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Neues Projekt erstellen.gif R0lGODdhAAUABHcAACwAAAUABIcAAACAgACAgICAAIAAgIDAwMDA3MCmy vAB NwAnHQAwLQwxMzgYCVwPLFYAO3M1OEgyPXEPVBARVjgRZw4eaSo0WTA9ZQosdDEfVkEaZ EkZZ3A5 SFszT3ksdEckbXtKOExmLGVFVhZKUTJHaBVIcyhwWTdsdipPU1lbW2xIbUhNY39qQF5ud Epwb2QL MJcHLKMxP7wvPdwdSJoYQaUMYK4qT5EmUrgxZZo6cL0ZUsQUftoIdusjWtgtUuUpZNsuc+ZCPoVS U4VOU7tObJlQe6VrVYd0co1zeKtXXcZFW/BGZstGbNRLcc5IcNJaZ8xUdttPeehtdM1nf ucGlQAB swA1jzU7qTo9l0A+pUAAygAA8wAuzy5HjzVEoztijAZshS50qgx6uyRKmUlCj2NLp0tfo swA1jzU7qTo9l0A+WBpk1J8 jHxgoV9urm514XU9g74UgtkPkuoVrfE5lds3g+4wrvQay/UjxvVOlYBKhbF/gIB3k6l/u jHxgoV9urm514XU9g74UgtkPkuoVrfE5lds3g+oBRldBJ j+1boNRRs/Rlhtxlm8xmnNV0h9x7l8l5ld5njOBohvxqkeBjm/t3juNwjf98muF7mf9+o j+uVYwvZz yvahEwG3Nw2FWDeVazW2UBqjRCGqZCaIU0iTW3aPc0mVZXe4WUuuYVqtaHrGOAf/AAD+N QPUSgjB XizbZg33ShP4Tyb0chHMZFPHcHD1aEmTbISudYzCdoGahgaaky2ZoCesjwq6jD6upSmKi FCIknCF p3Svmk+I0QyBySaa7AvCngvOhzrQqw7OuyL9kQT2iinzrA70rDDflkHQjGb2l07pk3X2r p3Svmk+lL1sWf5 zQ7+30H1xGn841L8622MjIyMkKeJvIiPor2vgZyxjamrqJigoKCTl8aBneGXq9KMq+e2t9Otu+yS wpKlzZ+zxail/7WJ0PazxNO5zPOs4f/akIPXp4vzmIjsuYT6tqjBzLX2zJHz1bX8+JXn/ wpKlzZ+6nT0tnY 2OTZ5NTX5Pjq1ND9/dTo6OgAAACgoKSAgID//wD//wAAAP//AP8A//9YqUYI/ wALCRTo RAqggwcNKTSEqKHDhw0XSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjy pxJs6bN mzhz6tzJs6fPnx4RCpXiZGChJQcHNZFSyJFTR9miSp1KtarVq1izat3KtavXr2DDih1Lt qzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4DnPi0kpckgQFEONgHUFKrVbZAjS55MubLly 5gza97M ubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7ZtyYFz697Nu7dvudvUOmWklEoUKosFP nX6u7nz 59CjS59Ovbr169iza9/OvXv15eDDX/8bf40RceRLokQZZHTg8qrh48ufT7++/fv48+vfz This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] False Positive - no reaction?
Sorry - didn't mean to be pushy. I just thought that false positives are worse than missed spam, so I had assumed that they would always be at the top of the queue. I can wait (PS - would have calmed my nerves, if there had been some automatic ticket number response that reassured me that my email was received. The web site makes it sound as if there's a million reasons why a false positive might not be accepted - so an automatic confirmation might be a good self-service tool. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, February 21, 2006 09:55 AM To: Andy Schmidt Subject: Re: [sniffer] False Positive - no reaction? I'm a little behind. I'm going to do false positives in the next 10 minutes. I only have 20 to do it should go fast. Sorry for the delay. Thanks, _M On Tuesday, February 21, 2006, 9:40:07 AM, Andy wrote: AS Hi, AS I filed this false positive report a day ago and never heard back. AS Just trying to see if my emails are blocked again. AS Phone: +1 201 934-3414 x20 (Business) AS Fax:+1 201 934-9206 AS -Original Message- AS From: Andy Schmidt [mailto:[EMAIL PROTECTED] AS Sent: Monday, February 20, 2006 10:41 AM AS To: '[EMAIL PROTECTED]' AS Subject: License ID nwb655oh AS This message was a GIF image from one individual to another. AS Log Entries: AS nwb655oh20060219172434 DA9CC319600AA9394.SMD 31 360 AS Match 836625 61 2245238871 AS nwb655oh20060219172434 DA9CC319600AA9394.SMD 31 360 AS Final 836625 61 0 32767 71 AS Original Message: Received: from mailout08.sul.t-online.com [194.25.134.20] by hm-software.com with ESMTP (SMTPD32-8.15) id A9CC319600AA; Sun, 19 Feb 2006 12:24:28 -0500 Received: from fwd34.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1FAsIN-00064u-06; Sun, 19 Feb 2006 18:24:27 +0100 Received: from athome ([EMAIL PROTECTED] 6 ]) by fwd34.sul.t-online.de with smtp id 1FAsIB-0X4oka0; Sun, 19 Feb 2006 18:24:15 +0100 Message-ID: [EMAIL PROTECTED] From: Bjoern Schmidt [EMAIL PROTECTED] To: Jochen Schug [EMAIL PROTECTED], Harald Mergard [EMAIL PROTECTED] Subject: Hier das Bild zu meinem Service-request Date: Sun, 19 Feb 2006 18:24:15 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0005_01C63581.B0813970 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ID: GWI0CrZ-Ye-ErQseZpWkpcMBFfC4ce2pefaSy9EIpXJHQ-BFOxDqQt X-TOI-MSGID: bdd1884c-5835-410b-822a-2343e2bb5047 This is a multi-part message in MIME format. --=_NextPart_000_0005_01C63581.B0813970 Content-Type: multipart/alternative; boundary==_NextPart_001_0006_01C63581.B0813970 --=_NextPart_001_0006_01C63581.B0813970 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ciao Bjoern Schmidt [EMAIL PROTECTED] www.barchetta.cc =20 Barchetta - The Classic and Sports Car Channel Updated News as It = Happens. --=_NextPart_001_0006_01C63581.B0813970 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=3DContent-Type content=3Dtext/html; = charset=3Diso-8859-1 META content=3DMSHTML 6.00.2900.2802 name=3DGENERATOR STYLE/STYLE /HEAD BODY bgColor=3D#ff DIVnbsp;/DIV DIVFONT face=3DArial size=3D2CiaoBRBjoern SchmidtBRA=20 href=3Dmailto:[EMAIL PROTECTED][EMAIL PROTECTED]/ABRA=20 href=3Dhttp://www.barchetta.cc;www.barchetta.cc/Anbsp;nbsp; = BRBarchetta -=20 The Classic and Sports Car Channel Updated News as It=20 Happens./FONT/DIV/BODY/HTML --=_NextPart_001_0006_01C63581.B0813970-- --=_NextPart_000_0005_01C63581.B0813970 Content-Type: image/gif; name=Neues Projekt erstellen.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Neues Projekt erstellen.gif R0lGODdhAAUABHcAACwAAAUABIcAAACAgACAgICAAIAAgIDAwMDA3MCm y vAB NwAnHQAwLQwxMzgYCVwPLFYAO3M1OEgyPXEPVBARVjgRZw4eaSo0WTA9ZQosdDEfVkEa Z EkZZ3A5 SFszT3ksdEckbXtKOExmLGVFVhZKUTJHaBVIcyhwWTdsdipPU1lbW2xIbUhNY39qQF5u d Epwb2QL AS MJcHLKMxP7wvPdwdSJoYQaUMYK4qT5EmUrgxZZo6cL0ZUsQUftoIdusjWtgtUuUpZNsuc+ZCPoVS U4VOU7tObJlQe6VrVYd0co1zeKtXXcZFW/BGZstGbNRLcc5IcNJaZ8xUdttPeehtdM1n f ucGlQAB swA1jzU7qTo9l0A+pUAAygAA8wAuzy5HjzVEoztijAZshS50qgx6uyRKmUlCj2NLp0tf swA1jzU7qTo9l0A+o swA1jzU7qTo9l0A+WBpk1J8 jHxgoV9urm514XU9g74UgtkPkuoVrfE5lds3g+4wrvQay/UjxvVOlYBKhbF/gIB3k6l/ jHxgoV9urm514XU9g74UgtkPkuoVrfE5lds3g+u jHxgoV9urm514XU9g74UgtkPkuoVrfE5lds3g+oBRldBJ j+1boNRRs/Rlhtxlm8xmnNV0h9x7l8l5ld5njOBohvxqkeBjm/t3juNwjf98muF7mf9+ j+o j+uVYwvZz
RE: Re[2]: [sniffer] False Positive - no reaction?
Hi Pete, I agree that the email notification is tricky - because you might respond to spam - and, you may NOT respond to someone who did not use an authorized address. On the other hand, if I KNEW there was an auto-response and I did NOT get a response, it would be an indication to me, the user, that I must have done something wrong. So - in a sense - no response is also a message I can act on. The only other suggestion I have is to create a 24 hour 'queue' display on the web site. All you need to show is a column of the sender domain names of the email (not the entire sender email address). If I submit a false positive I can confirm that it made it into your queue by checking the web page. This way, you don't need to send automated emails. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, February 21, 2006 11:04 AM To: Andy Schmidt Subject: Re[2]: [sniffer] False Positive - no reaction? On Tuesday, February 21, 2006, 10:16:11 AM, Andy wrote: AS Sorry - didn't mean to be pushy. I just thought that false AS positives are worse than missed spam, so I had assumed that they AS would always be at the top of the queue. It is a very tough balancing act. Don't feel bad at all - you're not being pushy. The current goal is to respond in less than 24 hours and if possible to review twice per day. Yesterday a number of urgent tasks toppled that schedule. The first review happened (at around 0600) but there were no FPs at that time. I'm working to increase the review cycle... there are just a lot of things going on right now. Just so everyone knows, we do hear - loud and clear - that responding to FPs is important, and we have been much better about it over the recent past. I expect that service aspect to improve moving forward along with other things. AS I can wait (PS - would have calmed my nerves, if there had been some AS automatic ticket number response that reassured me that my email AS was received. The web site makes it sound as if there's a million AS reasons why a false positive might not be accepted - so an automatic AS confirmation might be a good self-service tool. That's a good point. I'll look at that possibility when I rewrite the false processing bot. We're getting a lot of spam lately at our false@ address and I would want to make sure that there was no outscatter. I can tell the bot to only respond to validated senders, but then there is the issue of email reliability in the response... what if you don't get the response I mean. ... There are still folks that occasionally (some frequently) send false reports from unauthorized addresses --- those would not get a response... I'm overthinking this now %^b When I get to the false processing bot I will add a response mechanism. Thanks! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] [Declude.JunkMail] 3.05.5 issues
So this may be the known Declude problem with 3.x Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Thursday, October 06, 2005 07:13 AM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues Dual processor Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Wednesday, October 05, 2005 5:49 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues Single CPU or Dual Processor CPU? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Wednesday, October 05, 2005 05:28 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues And you also have sniffer working in persistent mode? Plus there is no spam leaking out? Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Hickman Sent: Wednesday, October 05, 2005 5:09 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues I had the exact same problem. I increased the process threads for Declude, and it fixed the problem. I set it to 100 for the number of threads. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 1:46 PM To: Declude.JunkMail@declude.com Cc: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues I have got it down to 15 and tried to set sniffer back to persistent mode again However I find that with sniffer in persistent mode as David suggested, the proc directory starts back logging. which means the system is not keeping up with the flow of mail. Within 20 minutes I had 1400 files in the proc directory. I stopped the sniffer service and now it is gradually catching up. Any more suggestions as to what can get tuned? I appreciate the assistance Thank you Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Tuesday, October 04, 2005 1:06 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues Trial and error is best. Set it to some thing like 20 and watch what happens. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 9:27 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues thank you I was under the understanding given me by David from Declude that it was appropriate given the amount of power my hardware has. What would you recommend for my hardware? Thanks John, I always appreciate your active involvement in the list Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Tuesday, October 04, 2005 12:11 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues Your threads is way too high, and I suspect that there are time outs occurring and not all scanning is being done. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 6:17 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] 3.05.5 issues I find that since being on the new version that more spam is slipping through. We have imail v8.05, declude and sniffer on win 2000 server dual xeon 3.4Ghz with 2Gb ram. Threads are set to 50 with no other setting
RE: [sniffer] [Declude.JunkMail] 3.05.5 issues
Single CPU or Dual Processor CPU? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Wednesday, October 05, 2005 05:28 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues And you also have sniffer working in persistent mode? Plus there is no spam leaking out? Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Hickman Sent: Wednesday, October 05, 2005 5:09 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues I had the exact same problem. I increased the process threads for Declude, and it fixed the problem. I set it to 100 for the number of threads. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 1:46 PM To: Declude.JunkMail@declude.com Cc: sniffer@SortMonster.com Subject: RE: [sniffer] [Declude.JunkMail] 3.05.5 issues I have got it down to 15 and tried to set sniffer back to persistent mode again However I find that with sniffer in persistent mode as David suggested, the proc directory starts back logging. which means the system is not keeping up with the flow of mail. Within 20 minutes I had 1400 files in the proc directory. I stopped the sniffer service and now it is gradually catching up. Any more suggestions as to what can get tuned? I appreciate the assistance Thank you Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Tuesday, October 04, 2005 1:06 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues Trial and error is best. Set it to some thing like 20 and watch what happens. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 9:27 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues thank you I was under the understanding given me by David from Declude that it was appropriate given the amount of power my hardware has. What would you recommend for my hardware? Thanks John, I always appreciate your active involvement in the list Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Tuesday, October 04, 2005 12:11 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 3.05.5 issues Your threads is way too high, and I suspect that there are time outs occurring and not all scanning is being done. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harry Vanderzand Sent: Tuesday, October 04, 2005 6:17 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] 3.05.5 issues I find that since being on the new version that more spam is slipping through. We have imail v8.05, declude and sniffer on win 2000 server dual xeon 3.4Ghz with 2Gb ram. Threads are set to 50 with no other setting in declude.cfg Any advice you can give me to tighten it to where we had it before? I have had several clients complaining Other than changing from V2.06.16 to 3.05 nothing else has changed on the server thank you Harry Vanderzand inTown Internet Computer Services 11 Belmont Ave. W., Kitchener, ON,N2M 1L2 519-741-1222 This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription
[sniffer] FW: AVERT Medium Threat Advisory: W32/Sober.r@MM
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Subject: AVERT Medium Threat Advisory: W32/[EMAIL PROTECTED] Advisory This is a Medium Threat Advisory for W32/[EMAIL PROTECTED] Justification W32/[EMAIL PROTECTED] has been deemed Medium due to prevalence. Read About It Information about W32/[EMAIL PROTECTED] is located on VIL at: http://vil.nai.com/vil/content/v_136390.htm Detection W32/[EMAIL PROTECTED] was first discovered on October 5, 2005 and detection will be added to the 4598 dat files (Release Date: October 5, 2005). The EXTRA.DAT IS AVAILABLE. If you suspect you have W32/[EMAIL PROTECTED], please submit a sample to http://www.webimmune.net. Risk Assessment Definition For further information on the Risk Assessment and AVERT Recommended Actions please see: http://www.mcafeesecurity.com/us/security/resources/risk_assessment.htm Best Regards, McAfee AVERT - Anti Virus and Vulnerability Research, Analysis, and Solutions visit us at www.avertlabs.com You are currently subscribed to avertalert as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Integration with today's new ORF version:
http://www.vamsoft.com/orf/agentdefs.asp It says to contact vendor. Here I am G. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206
RE: [sniffer] Integration with today's new ORF version:
Congratulations! (Sorry for having wasted band-width, I just saw the contact vendor link - never clicked on the link that contained the XML definitions G Found it now...). Anyway - thanks for the integration. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, September 05, 2005 10:43 AM To: Andy Schmidt Subject: Re: [sniffer] Integration with today's new ORF version: On Monday, September 5, 2005, 9:26:38 AM, Andy wrote: AS http://www.vamsoft.com/orf/agentdefs.asp AS AS It says to contact vendor. Here I am G. Yes indeed. How may I help you? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] New Spam Storm
Yes, these messages were caused by Sunday'sSober.O and Sober.P remote update of previouslyinfected PCs, causing them to send out millions of neo-nazi mail. The next update (likely a new spam-wave) is scheduled in 10 days. Somepublic mailboxes got as many as 50,000 emails in 48 hours to a single account. SURBL will catch many of them for a while - big problem are returns to faked senders that are not as easily blocked. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim MatuskaSent: Tuesday, May 17, 2005 01:27 PMTo: sniffer@SortMonster.comSubject: [sniffer] New Spam Storm Is anyone else seeing a huge amount of spam increase over the last couple days. Most is being caught by sniffer but the overall number of messages especial foreign language spam messages seems to be very high. Jim Matuska Jr.Computer Tech2, CCNANez Perce TribeInformation Systems[EMAIL PROTECTED]
RE: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Wow - inline Virus scanning - and if I read the flow chart correctly, their heuristic engine actually sounds like a scoring system for DNSBL and various other indicators and reject a message during connection. Now that's the kind of SMTP engine I've been wanting all along. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, April 18, 2005 06:57 PM To: sniffer@sortmonster.com Subject: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo Hello Sniffer folks, For those of you who are MDaemon users and may not know, we have developed a plugin version of Message Sniffer that works on the latest version of MDaemon (v8). The folks on the MDaemon beta list have had access to it for a while now and it has been working well. There are no known bugs at this time :-). You can find the plugin on the MDaemon installation page of our site: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The plugin is VERY, VERY fast and much easier to use than the command line utility. If you are still using the command line utility I highly recommend that you switch to the plugin version right away :-) Now that version 8 of MDaemon is out, it is time to finish testing this new version and to get the word out. To help with testing, we have been providing a fully updated rulebase to our beta testers. To help with this next phase of testing we are making this fully updated license public for MDaemon users who want to try the new plugin!! :-) This will only last until the end of April though ;-) Please help us to get the word out about this -- tell all your MDaemon friends what they have been missing. Most of our customers come from your recommendations and we really appreciate that. Remember to tell your friends to let us know about your help when they purchase Message Sniffer so that we can give you your free month! Every new user makes Message Sniffer more powerful! Thanks for all your help! Best, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] RAID level for spool
Even if you break it into smaller blocks, you still need to transfer the data to the controller, then the controller has to employ overhead to break up the block, create the parity information, determine the location for each block, etc. With RAID-1 the controller can just write through and duplicate the operation as is on the second bank. http://www.acnc.com/04_01_05.html vs. http://www.acnc.com/04_01_01.html RAID-1 has less overhead during writing. Since the spool folder probably has a 1:1 read/write ratio - it is sensitive to write performance. RAID-5 works well for write once - read many times applications, such as file and database servers. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Goran Jovanovic Sent: Wednesday, March 16, 2005 11:26 AM I guess this is going against what I think should be happening. In a RAID 5 array the write to the drives is broken into many smaller writes along with the data protection/CRC info and then those writes are written to different drives. It seems to me that it should be faster to do a bunch of small writes rather than 1 big write. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] RAID Levels for Spool Folder
Uh, sorry, I had thought that discussion was RAID-5 vs. RAID-1? If someone is running RAID-5, I assume that it's hardware based. If so, then that person could use the same hardware to configure a RAID-1 array instead - so why even bother with software RAID then? If the discussions is software RAID-1 vs. no-raid, then the answer is: Sure, software RAID is a cost effective solution if the system has sufficient head-room to deal with whatever possible overhead that may cause. However, if we are talking about a machine that is already taxed, then I would suggest plugging in a RAID controller instead of adding software RAID to the mix. I have several (older) systems running Windows 2000 RAID-1. At least ONE of the servers I later upgraded to Hardware RAID. I can't say that I've noticed any difference (but then again, I have not run benchmarks and the server was not really taxed before either.) From what I understand, there are many factors involved and it much depends on your systems configuration. CPU availability is critical. A server that is already CPU taxed may suffer if software RAID is added. Having the drives split on two SCSI controllers should also help with software RAID-1. Doing software RAID-1 with a master/slave ATA drive, however, may slow things down. There may not be a single answer... Best Regards Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Wednesday, March 16, 2005 02:05 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail OK that is for hardware level RAID. I had thought that you would offset the extra processing time by being able to write less to each drive. Now does anyone know how much overhead Windows 2000/2003 software RAID 1 on dynamic disks produces over hardware level RAID 1? This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Interesting Article
Also, leading Internet service company AOL (NYSE: AOL) said it noticed a sharp drop in spam being sent to its members during 2004. Yet most observers say spam is at least as bad A result of AOL's aggressive legal stand (helped by their location in VA and the support by their local law enforcement) - so I have been told by someone in the industry. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 01:14 PM To: Computer House Support Subject: Re: [sniffer] Interesting Article On Friday, February 18, 2005, 12:43:14 PM, Computer wrote: CHS Hi Sniffer Folks, CHS CHS Here's an interesting article: CHS http://www.technewsworld.com/story/39578.html I think this is a rehash of a story that showed up a few weeks ago. One of the advantages of SNF is that it doesn't use DNS for anything - so this entire threat is a non-issue for SNF users, at least for the most part. Slow news day I guess... Thanks! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] IIS SMTP Integration
It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. Huh? Why would it need to be a transport sink? Why first accept and store the message - and then generate bounce messages (in case it's a false positive)? Scanning at protocol time will take just as long (a few milliseconds) - but you'll be able to drop connection as soon as you determine you don't want the mail. This way, the other party has notice in case of FP and you are not responsible for generating bounces and you are not going to spam job-jobbed users. In a protocol sink, the sink can pass the in-memory email directly to the Sniffer service - no need to write to disk/read from disk and starting command-prompt tasks etc etc. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, February 18, 2005 07:23 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] IIS SMTP Integration Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). Yes, that really is a key issue. It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. I'm not sure that Peter from VamSoft understands the large market out there for non-Exchange based setups, or even for going the extra mile that is necessary for this stuff, though that might be an issue with resources and not just simply understanding. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] IIS SMTP Integration
The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for , if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your tarpit/graylist list. Use that for subsequent upon connections Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] IIS SMTP Integration
Hi Andrew: The idea being that you don't want any more content searching than is necessary The content searching happens at the very end of the protocol conversation. By that time you already have processed your IP, HELO, SENDER etc. policies (e.g. DNS BL, local BLs, etc.) Or are you saying you want to only search for content when there is NO dictionary attack - but if you happen to be under dictionary attack you want to let all the spam go through unchecked? Seems counterintuitive to me. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Changes - another reminder.
If I may suggest: - at least 24 hours before the cut-over, change DNS timeout for A and CNAME records to 4 hours. - on the day of the cutover, change DNS timeouts to 1 hour That will minimize any impact. - after the cutover was successful, change DNS timeouts for the updated records to longer values. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, February 14, 2005 02:06 PM To: sniffer@sortmonster.com Subject: [sniffer] Changes - another reminder. Hello Sniffer Folks, This is a _special_ reminder that we are in the process of migrating our servers and applications to a new facility. Over the past few weeks we have been testing and tweaking software, the new hardware, networks, firewalls, configurations, procedures... and occasionally we've been letting you know that we're getting ready to do this so that you won't be surprised by any unavoidable interruptions. What is _special_ about this reminder is that we are very close to the switch-over. If all goes as planned, the switch-over may occur any time in the next 48 hours. There is no specific moment in time that the switch-over will occur. It is a large process requiring the coordination of several hundred steps. During this period you may see the following problems or issues: * You may not receive one or more update notifications. * You may not be able to download your rulebase file(s). * You may not be able to upload your log file(s). * You may not be able to access special applications. All of these are likely to occur at one point or another - at least for short periods - while DNS records are changed, data is transferred to new servers, etc. It is our plan that most of these events will be so short-lived as to pose no problem to you and perhaps even to go un-noticed. IMPORTANT Your Message Sniffer software will continue to work normally! We have designed Message Sniffer to be resilient in the face of any kind of temporary interruption. At most you might see a slight increase in spam leakage if/when rulebase updates are delayed. --- Thanks to all of you for your support and patience. See you on the other side ;-) Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Spam Ratios, specifically: Sniffer and SURBL
Hi Matt, Well, statistics are a tricky thing. When you had posted on the Sniffer or Declude lists over the weekend that I should provide more specific numbers, I had no yet understood how you calculated your percent of SPAM. The key is always how one defines 100%. Now that I read your post on the Sniffer list, I realize what number you are looking for. You call it percent of SPAM, I call it percent of HELD messages (which, in reality, is only a subset of all Spam.) Total Messages Processed: 13,077 Messages That Failed ANY Test(s): 11,323 (86.59%) Total Messages DELETE, HOLD, BOUNCE, ROUTETO: 7,737 (59.16%) Average Message Weight: 22.00 (Hold weight is 10) Note: Before anyone jumps down my throat for the low hold ratio, we simply whitelist a lot of internal mail based on SMTP AUTH and based on clients' static IPs. Of those 7,737 spam messages: INV-URIBL...7,737...59.16% IPNOTINMX...7,620...58.27% SNIFFER.7,396...56.56% - or 95% of the messages that were held (which, matches your capture rate of 95 - 96% exactly!) Note: As stated in my original post, I ran additional reports to break out the unique hits by SURBL vs. Sniffer, vs. the combined hits. From that I concluded that SURBL is NOT an irrelevant subset of Sniffer - but rather there is about an 80 - 90% overlap. On both ends there are messages that one flags - but not the other. Thus my previous statement that by using both together I'm able to tag about 10 - 20% more messages than what each one individually would have tagged (tapping into the 40.84% of non-held messages). NOLEGITCONTENT..7,215...55.17% SPAMCOP.4,611...35.26% XBL-DYNA4,228...32.33% SORBS...4,221...32.28% DSBLSINGLE..3,686...28.19% REVDNS..2,967...22.69% WEIGHTFILTER2,841...21.73% SORBS-DUHL..2,436...18.63% HELOBOGUS...2,277...17.41% SENDERDB-BLOCK..2,095...16.02% SPAMROUTING.1,977...15.12% NJABLDYNA...1,958...14.97% DYNAMIC-IP..1,486...11.36% SPAMHEADERS.1,442...11.03% AHBL1,424...10.89% BLITZEDALL..1,359...10.39% NJABLPROXIES1,342...10.26% BCC41,313...10.04% SORBS-WEB...1,0267.85% BCC6..9277.09% BADHEADERS9267.08% AHBLPROXIES...9237.06% SBL...9187.02% SPAMDOMAINS...8346.38% SURBL-FROM7986.10% OPEN-RELAY7335.61% SORBS-HTTP7045.38% SNIFFER-PORN..6985.34% BCC8..6685.11% SORBS-SOCKS...6254.78% AHBLSOURCES...4913.75% RHSBL.3772.88% AHBLDOMAINS...2932.24% SPFFAIL...2762.11% SPFPASS...2351.80% BASE641871.43% MAILFROM..1821.39% NJABLDUL..1791.37% SENDERDB-SUSP.1451.11% SNIFFER-SCAMS.1110.85% FORMMAIL...850.65% NJABLSOURCES...710.54% SORBS-BADCONF..550.42% COMMENTS...410.31% SORBS-MISC.410.31% SNIFFER-MALWARE380.29% MULTI-RELAY330.25% DSBLMULTI..330.25% WEB-O-TRUST260.20% SORBS-ZOMBIE...230.18% SORBS-SMTP.230.18% MAILPOLICE-PORN220.17% SNIFFER-OBFUSC.150.11% ORDB...100.08% RDNSBL..50.04% NJABLRELAYS.50.04% HIL.40.03% Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, January 10, 2005 11:35 AM To: sniffer@SortMonster.com Subject: Re: [sniffer] Still having problems I just wanted to add some stats that I thought might be of some use here. I gathered info on my block rates over the past three days and compared my Sniffer hits to them. There has been no measurable change to my system with an average of 96% of spam getting tagged by Sniffer. I'm at least not seeing any issues. FRIDAY == Blocked:89.45% of Total Message Volume Sniffer: 85.74% of Total Message Volume - Sniffer Capture Rate on Spam: 95.85% SATURDAY == Blocked:96.57% of Total Message Volume Sniffer: 92.55% of Total Message Volume - Sniffer Capture Rate on Spam: 95.84% SUNDAY
RE: [sniffer] new spam storm?
many of them for ... my cheating wife. Sorry to hear about your marital problems. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Mitchell Sent: Tuesday, January 04, 2005 05:56 PM To: sniffer@SortMonster.com Subject: [sniffer] new spam storm? Seems like I've been getting a ton of spam in the last few days that's been scored as either LOW or CLEAN, many of them for cheap drugs, watches or my cheating wife. I have AutoSNF running every 2 hours, so it shouldn't be due to outdated rulesets. Is anyone else seeing this, or could I be missing something? Thanks, -- Kirk Mitchell-General Manager[EMAIL PROTECTED] Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Downloads are slow...
While the output file is named .new, it IS comparing the file named in the URL, in his case fp0o4jye.snf against a file with the same name in the current directory. The output (-o) option only comes into play IF an download is actually occurring (after the timestamp condition). With CURL things are a bit more flexible - you can specify WHICH file is used for comparison. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Tuesday, December 28, 2004 02:39 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] Downloads are slow... Quick question if when you have a sucessful download if abcdef.new is renamed than what is wget comparing on the next run of the script? Darrell Jim Matuska writes: So far it seems to be working, at least it doesn't seem to be downloading the rulebase yet, I'll have to see if it does later when there is an updated rulebase. My script uses a copy at the end rather than a move. It's listed below for reference. Do you see any issues? wget -N http://www.sortmonster.net/Sniffer/Updates/fp0o4jye.snf -O abcdefg.new --http-user=* --http-passwd=* if exist abcdefg.new goto Replace goto Done :Replace rename abcdefg.new abcdefg.tst snf2check.exe abcdefg.tst abcdefg if errorlevel 1 goto Done echo New File Tested GOOD! if exist abcdefg.old del abcdefg.old rename abcdefg.snf abcdefg.old rename abcdefg.tst abcdefg.snf copy /V /Y abcdefg.snf C:\sniffer\abcdefg.snf :Done if exist abcdefg.tst del abcdefg.tst Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Jim Matuska sniffer@SortMonster.com Sent: Tuesday, December 28, 2004 11:12 AM Subject: Re[2]: [sniffer] Downloads are slow... On Tuesday, December 28, 2004, 12:49:21 PM, Jim wrote: JM I agree that something needs to be done about the update scripts JM that are JM inadvertently downloading the full rulebase all the time. I JM didn't even JM know it but we were doing this until I went through our update JM script again JM this morning and found it didn't have the -N option in Wget, so JM we were Watch out - you may still have not fixed it. One of the tricks with the -N option is that the file downloaded previously must still be in it's place for the comparison. If it has been moved then the -N will not matter. This make things a little bit more complex since you can't download a rulebase file on top of the one that is running. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, MRTG Integration, and Log Parsers. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Conditional Sniffer Updates
Hi, The one thing I have not seen mentioned is the ability to do CONDITIONAL downloads - which is crucial for timed downloads when most of the time there may not even BE a more current .SNF file. Just like your browser, the HTTP Request for your latest .SNF file should ALWAYS provide the date/time stamp of your CURRENTLY active .SNF file. This way, the server will compare both dates and a download will occur ONLY, if there is LATER .SNF file on the server. (This is how your web browser controls, whether it needs to download new pages/images from sites you visited before.) Here is how CURL is used to do conditional downloads: curl http://www.sortmonster.net/Sniffer/Updates/[mylicensecode].snf -o [mylicensecode].snf.new -s -S -R -z [mylicensecode].snf -u [mywebuserid]:[mywebpassword] The -o option defines the output file. The -R option makes sure that the output file will inherit the timestamp from the Sniffer Server (if one is downloaded at all). The -z option sends the timestamp of the CURRENT SNF file to the server (in the GET request!) Since my local .SNF file has the same timestamp as the SERVER, and since every new GET request will allow the server to recognize if/that there may me no LATER .SNF file, I am only downloading when a new file is actually present! Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, December 27, 2004 12:50 PM To: Russ Uhte Subject: Re[2]: [sniffer] Sniffer Updates On Monday, December 27, 2004, 11:45:59 AM, Russ wrote: RU Kevin Stanford wrote: Our updates seem to be taking a very long time. I am 85% updated and the ETA shows 07:00. Is it me? RU I see stuff like this come and go... Our updates are (finally) RU triggered from the email notifications... Below is a snippet of the RU last update that shows exactly what speeds we saw, which ran at 10:45 RU EST this morning... Every once in a while, I will see it slow down to RU about 8KB/s, but rarely slower than that... There are going to be random events like this for a while - as long as some folks still download based on a schedule rather than responding to update notifications. What happens is that sometimes a group of systems will agree to all download their rulebase files at the same time - when that happens our bandwidth gets saturated and things go slowly. (We are working on this in a number of ways.) Most of the time there is plenty of bandwidth, and if everyone always downloaded only when there was an update notification then there would always be plenty (our system paces updates to make sure this is the case as much as possible). We are in a transitional period where existing connectivity contracts prevent us from moving without incurring a significant cost (a cost we would rather not pass on to our customers). Over the next 6-9 months we will make the transition to a new rulebase format and distribution method and we will also be migrating to new hosting facilities (already running in case we encounter a serious DL problem). Since rulebase downloads should always be automated in some way, the occasional slow download should not be a problem. We will continue to monitor the situation closely - and we appreciate the reports we get. The things that you can do to help are: 1. If you haven't already, please upgrade your scripting so that your automated downloads are triggered from our update notifications. 2. If you are not going to use update notifications please be sure to use the staggered schedule we've posted here: http://www.sortmonster.com/MessageSniffer/Help/LogsHelp.html#When 3. AVOID using accelerated download software! This is the kind of software that downloads large files by opening multiple connections to the same server. Almost all of the slowdowns we experience have been associated with someone downloading a rulebase with this kind of software -- they open 100+ connections for themselves (sometimes more) and that slows things down for everyone else. We have adjusted our server's setting to mitigate this, but we can't turn it off completely without causing other performance problems ;-) Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Downloads are slow...
Pete, With all due respect - I think the download problem is self-inflicted, because your web site is providing unsuitable examples to your customers! Even with moderate bandwidth, your server would be able to handle tens of thousands of hits a day. Checking if an updated file exists should barely be noticeable - as long as it doesn't result in an unnecessary download. You probably suffer TWO problems: A) Most of your customers are downloading rules based on a schedule, even if no rules exists. Potential savings: 100% per download attempt. B) Your customers are not downloading compressed rule files. Potential savings: about 66%, but that's not bad either. One likely explanation is that at least THREE of your sample scripts do an unconditional and uncompressed download! Here the 3 URLs you list on your web site and WGET command they are using: http://www.sortmonster.com/MessageSniffer/Help/UserScripts/david_snifferUpda teMethod.zip wget http://www.sortmonster.net/Sniffer/Updates/.snf -O .new --http-user=username --http-passwd=password http://www.sortmonster.com/MessageSniffer/Help/UserScripts/Hank_SnifferScrip ts.zip wget http://www.sortmonster.net/Sniffer/Updates/.snf -O .new --http-user=sniffer --http-passwd=ki11sp8m http://www.sortmonster.com/MessageSniffer/Help/UserScripts/Michiel_AutoUpdat e.zip wget http://sniffer:[EMAIL PROTECTED]/Sniffer/Updates/12345678.snf -O serial.tst My recommendation: Replace these with examples that implement conditional, compressed downloading. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, December 27, 2004 08:10 AM To: Chuck Schick Subject: Re: [sniffer] Downloads are slow... On Monday, December 27, 2004, 1:17:21 AM, Chuck wrote: CS Pete: CS It appears on weekends the sniffer downloads are really slow. I am CS downloading at 14 minutes past the hour and I am about 1/20 th of CS the normal speed. That is an unusual observation - I don't think weekends have anything to do with making things slower. I will look at the logs to see if I can figure out what heppened. You're not manually downloading I hope? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] How are folks doing with the latest version?
Running without known problems. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, November 19, 2004 03:28 PM To: [EMAIL PROTECTED] Subject: [sniffer] How are folks doing with the latest version? Hello Sniffer Folks, I am curious to know how many folks have been using Version 2-3.1i2. I have not heard any problem reports, so I'm assuming it's going well with you as it is on our systems... or, perhaps, nobody has tried it yet?? I would like to move this interim to the official version. If I can get a show of hands on how many folks are using the new version successfully then I would really appreciate it. Thanks! _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool
Hi, Oh, and yes, net start shows the Sniffer service running That can be misleading. The Sniffer service shows running, because srvany.exe is executing! (Check your task manager, you'll see an instance of srvany.exe - that's why it shows running.). It showed running on my end all the time. However in my case, on start, srvany.exe launched my sniffer.exe - which then promptly ended because it didn't have the necessary files. Yet, the Sniffer (srvany.exe) service kept showing running (and technically, it was). and I have a LicenseID.persistent.stat That's the only true measure - then you should be alright! Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry William Sent: Monday, November 01, 2004 03:32 AM To: '[EMAIL PROTECTED]' Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool Oh, and yes, net start shows the Sniffer service running and I have a LicenseID.persistent.stat fine on both of my IMail/Declude/Sniffer servers and it is periodically updated (cat or type the file and you will see that the data it contains updates every second, I believe). Bill -Original Message- From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Sunday, October 31, 2004 11:38 PM To: [EMAIL PROTECTED] Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool I suspect you typed your application startup parameters into the services control panel window? That's one way to do it - although the SrvAny documentation seemed to imply, that these startup parameters (if typed into the Control Panel window, would only apply to manual starts, not automatic starts. Of course, mine is Windows 2000 Server Resource Kit - yours may be different. And, I assume you have checked your sniffer folder to confirm a presence of the persistent.stat file with the very current time-stamp? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry William Sent: Monday, November 01, 2004 02:15 AM To: '[EMAIL PROTECTED]' Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool Hmmm, that's strange, since I use SrvAny, as well. And it has worked with all Sniffer updates since the first persistent version was released. Also, my Parameters registry entry does not look anything like yours: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer\Parameters] Application:REG_SZ:m:\imail\declude\tpa\sniffer\LicenseID.exe AuthCode persistent Bill -Original Message- From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Sunday, October 31, 2004 10:23 PM To: [EMAIL PROTECTED] Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool Hi, I had set up the previous version of Sniffer in persistent mode using the Win2k Server Resource Kit tool SrvAny (I don't like to install forth party utilities on my production machines, if Microsoft tools are readily available). In the NEW Sniffer version I noticed that my log files were not rotating. Upon further investigation it became clear, that Sniffer was no longer running in persistent mode since the upgrade (thus ignoring the rotate command). The clue was a missing *.persistent.stat file. After some experimenting I determined that the problem was that (at least on MY machine) Sniffer now requires the explicit specification of a an application working directory. Here is my updated SrvAny configuration: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer\Parameters] Application=D:\\IMAIL\\Sniffer\\Win32\\MyLicenseKey.exe AppParameters=MyAuthorizationCode persistent AppDirectory=D:\\IMAIL\\Sniffer\\Win32 Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Sunday, October 31, 2004 09:19 PM To: [EMAIL PROTECTED] Subject: [sniffer] LogRotate no longer working? Hi, After 10/28 the log files have not been rotation. I even logged into the server and executed the send-rotate - but the current log files just continues to grow: 10/24/2004 11:00p 1,324,321 x.log.20041025040052 10/25/2004 05:44a 1,303,683 x.log.20041025104510 10/25/2004 01:37p 1,711,062 x.log.20041025183751 10/25/2004 08:25p 1,403,988 x.log.20041026012528 10/26/2004 03:19a 1,100,582 x.log.20041026082022 10/26/2004 11:17a 2,158,910 x.log.20041026161756 10/26/2004 07:11p 1,999,926 x.log.20041027001129 10/27/2004 01:53a 1,619,614 x.log.20041027065310 10/27/2004 09:52a 1,689,744 x.log.20041027145244 10/27/2004 04:41p 1,591,043 x.log.20041027214159 10/28/2004 01:11a 1,598,140 x.log
RE: [sniffer] Your Sniffer Setup
Hi Keith, It's pretty straightforward: A) Download the Windows 2000 Server Resource Kit utilities. B) Locate the path to srvany.exe. C) run: instsrv Sniffer c:\path-to-resource-kit\srvany.exe Sniffer is just the name that will appear in the services applet later D) Start RegEedit and add the following entries to the new Sniffer service you just created: Add a new Parameters subkey in the following registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer Add new subkeys to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer\Parameters as follows: Application: REG_SZ: C:\Your.Path.to.your\sniffer-license-code.exe AppParameters: REG_SZ: sniffer-license-code.exe your-authorization-code AppDirectory: REG_SZ: C:\Your.Path.to.sniffer\ E) Start the Service Control Panel application, and START the service. Soon, you should see a *.Persistant.stat file in your sniffer folder. Once that appears, you are running in persistent mode. F) Change the Service from manual start to automatic start. Other list-members seem to have different ways to use SRVANY.exe - I followed the instructions from the Resource Kit Tool Help that I was able to find. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Keith Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 08:54 AM To: Andy Schmidt Subject: Your Sniffer Setup Andy, I saw your posting on the Sniffer forum and wanted to contact you regarding your Sniffer Persistent setup. We push over 200K emails on 3 servers (Win2K SP4) and are still running Sniffer in the general sense. I noticed you were using SrvAny and the like, do you have any documentation you don't mind sharing on your steps to get sniffer in a persistent mode? Thanks for the aid and time. --- Keith Johnson Senior Network Engineer Network Advocates, Inc. 9001 Shelbyville Road Burhans Hall, Suite 260 Louisville, KY 40228 TEL: 502.992.5928 FAX: 502.412.1058 This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Your Sniffer Setup
Hi Landry: These simplified instructions only apply if the application needs no parameters, as it only covers the application key: Value Name: Application Data Type : REG_SZ String : path\application.ext If there was a SnifferPersistent.exe that needed no further options, these simplified instructions would work For Sniffer however, you (supposedly) do need to pass along the authorizaton code and the persistent option, which are defined in the AppParameters value in the registry. That's how the previous version worked for me. Immediately upon upgrading to the latest version, Sniffer would no longer find its directory when executed as a service, so I had to add the AppDirectory key to set the working directory. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry William Sent: Monday, November 01, 2004 11:03 AM To: '[EMAIL PROTECTED]' Subject: RE: [sniffer] Your Sniffer Setup See http://support.microsoft.com/default.aspx?scid=kb;en-us;137890 for simplified instructions. Bill This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Your Sniffer Setup
Hi Bill, Thanks. That's curious. I'm not at all doubting your experiences - I'm just trying to reconcile the KB article (which says to ONLY define the path, program name and extension) with the Sniffer documentation (which says, you must define the persistent option and your authorization code). Somewhere documentation and your experience does not match - so (for my better understanding, and for providing proper instructions to others), I'm trying to figure out what is actually correct If based on that knowledge base article all you've defined is: Value Name: Application Data Type : REG_SZ String : path\application.ext e.g. c:\Imail\Sniffer\Win32\yoursnifferlicense.exe then where/how did you define your authorization code and the persistent option? Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry William Sent: Monday, November 01, 2004 01:23 PM To: '[EMAIL PROTECTED]' Subject: RE: [sniffer] Your Sniffer Setup Andy, these simplified instructions work just fine with Sniffer, as I can certainly attest. Bill This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] LogRotate no longer working?
Hi, After 10/28 the log files have not been rotation. I even logged into the server and executed the send-rotate - but the current log files just continues to grow: 10/24/2004 11:00p 1,324,321 x.log.20041025040052 10/25/2004 05:44a 1,303,683 x.log.20041025104510 10/25/2004 01:37p 1,711,062 x.log.20041025183751 10/25/2004 08:25p 1,403,988 x.log.20041026012528 10/26/2004 03:19a 1,100,582 x.log.20041026082022 10/26/2004 11:17a 2,158,910 x.log.20041026161756 10/26/2004 07:11p 1,999,926 x.log.20041027001129 10/27/2004 01:53a 1,619,614 x.log.20041027065310 10/27/2004 09:52a 1,689,744 x.log.20041027145244 10/27/2004 04:41p 1,591,043 x.log.20041027214159 10/28/2004 01:11a 1,598,140 x.log.20041028061150 10/28/2004 07:22a 1,137,471 x.log.20041028122216 10/28/2004 02:27p 1,518,661 x.log.20041028192727 10/31/2004 09:09p 16,790,875 x.log Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] LogRotate no longer working?
Pete, Another test: - stopped IMAIL SMTP and QUEUE service - stopped SNIFFER service - there were no more sniffer tasks in the task manager list - I ran mylicense.exe stop (it returned) - I ran mylicense.exe rotate (it returned) - I started the SNIFFER service - I restarted the IMAIL QUEUE then the SMTP service - I checked my Sniffer win32 folder - the OLD .log file continues to grow and be updated with new dates. NO new log file was created, no old one was renamed. Where do I look for any error messages/indicators/return codes? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Sunday, October 31, 2004 11:48 PM To: Andy Schmidt Subject: Re[2]: [sniffer] LogRotate no longer working? On Sunday, October 31, 2004, 11:33:49 PM, Andy wrote: AS 1. on 10:28 5:46PM I downloaded and installed the new Sniffer AS version. AS 2. I just ran: AS D:\IMAIL\Sniffer\Win32mylicense.exe myauthcode rotate -- this had no effect AS D:\IMAIL\Sniffer\Win32mylicense.exe myauthcode stop AS D:\IMAIL\Sniffer\Win32mylicense.exe myauthcode persistent -- this created a new log file, but, this command NEVER returns - the AS command window is STILL running! AS Now what? The command window will continue to run since you launched a persistent instance within it. That is designed never to return. There were no changes in the latest version that should effect the log rotate command so this will take some hunting. Normally when you run a persistent instance you would run it from a utility that allows the program to run as a service. I suggest you open a new dos window and re-issue the stop command. You shouldn't need that authentication code - in testing we never use it and had no trouble. Both windows should return to the command prompt. Once you are sure your persistent instance has been stopped, you can go to your service control panel and stop, then start the persistent instance service that you set up. (If this doesn't make sense then please explain how you have your persistent instance running under normal conditions.) If the program accepts and processes the stop command then it should also answer the rotate command - they are processed by the same patch of code - only the final details are different. I've not tested log rotation when there might be interference - such as a duplicate file name or having the log file open when it must be renamed. If you find that your persistent instance is answering to the stop command but not answering to the rotate command then check for anything that might be holding on to the log file or otherwise causing a problem that might prevent it from being renamed. I have not yet been able to duplicate the conditions you are describing. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[4]: [sniffer] LogRotate no longer working?
Hi, A) for what it's worth, I ran: rename mylicense.log mylicense.log.20041101051900 and the command prompt was able to rename the file WITHOUT problems (I didn't even stop the IMAIL or Sniffer services. So it appears that nothing locks the .log file. B) Under normal conditions the persistent server will see this file, delete it, and process the command it represents. Well - in my case it's 30 MINUTES later and the .rotate file still exists! What version operating system are you using? Windows 2000 Server, Service Pack 4 on a dual-processor Dell machine Hotfixchecker lists no missing security fixes What does your licenseid.persistent.stat file contain? Hm - interesting - that file does NOT exists. However, I DID see it exist while I had executed mylicenseid.exe persistent from the command line what is the build information? build - v2-3.1 Oct 26 2004 22:03:06 Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, November 01, 2004 12:14 AM To: Andy Schmidt Subject: Re[4]: [sniffer] LogRotate no longer working? On Monday, November 1, 2004, 12:02:30 AM, Andy wrote: AS Pete, AS - okay, I ran the STOP command - it never ended AS - the persistent command window never ended AS - I finally stopped the SERVICE and the stop command ended AS - I finally CLOSED the command window to flush the persistent task AS Then I saw a whole bunch of sniffer tasks launch in the task window AS - so I assume it was no longer running in persistent mode. After AS watching this for 2 minutes, I restarted the server. Ok. AS Now I tried against AS mylicense.exe rotate AS from the command line. AS - It DOES return, I see no error message. AS - It creates an EMPTY mylicense.ROTATE file !? That is a signal to the Persistent instance. Under normal conditions the persistent server will see this file, delete it, and process the command it represents. When the issuing instance sees the file dissapear - or times out - then it returns. AS - It does NOT rename the active log and continues to use it. This means that the Persistent instance did not recognize or process the command. When you issued the command it returned after 30 seconds or so simply because it had finished waiting - there is a time-out. What version operating system are you using? What does your licenseid.persistent.stat file contain? If you run your sniffer exe from the command line with no parameters what is the build information? Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool
I suspect you typed your application startup parameters into the services control panel window? That's one way to do it - although the SrvAny documentation seemed to imply, that these startup parameters (if typed into the Control Panel window, would only apply to manual starts, not automatic starts. Of course, mine is Windows 2000 Server Resource Kit - yours may be different. And, I assume you have checked your sniffer folder to confirm a presence of the persistent.stat file with the very current time-stamp? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry William Sent: Monday, November 01, 2004 02:15 AM To: '[EMAIL PROTECTED]' Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool Hmmm, that's strange, since I use SrvAny, as well. And it has worked with all Sniffer updates since the first persistent version was released. Also, my Parameters registry entry does not look anything like yours: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer\Parameters] Application:REG_SZ:m:\imail\declude\tpa\sniffer\LicenseID.exe AuthCode persistent Bill -Original Message- From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Sunday, October 31, 2004 10:23 PM To: [EMAIL PROTECTED] Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool Hi, I had set up the previous version of Sniffer in persistent mode using the Win2k Server Resource Kit tool SrvAny (I don't like to install forth party utilities on my production machines, if Microsoft tools are readily available). In the NEW Sniffer version I noticed that my log files were not rotating. Upon further investigation it became clear, that Sniffer was no longer running in persistent mode since the upgrade (thus ignoring the rotate command). The clue was a missing *.persistent.stat file. After some experimenting I determined that the problem was that (at least on MY machine) Sniffer now requires the explicit specification of a an application working directory. Here is my updated SrvAny configuration: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sniffer\Parameters] Application=D:\\IMAIL\\Sniffer\\Win32\\MyLicenseKey.exe AppParameters=MyAuthorizationCode persistent AppDirectory=D:\\IMAIL\\Sniffer\\Win32 Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Sunday, October 31, 2004 09:19 PM To: [EMAIL PROTECTED] Subject: [sniffer] LogRotate no longer working? Hi, After 10/28 the log files have not been rotation. I even logged into the server and executed the send-rotate - but the current log files just continues to grow: 10/24/2004 11:00p 1,324,321 x.log.20041025040052 10/25/2004 05:44a 1,303,683 x.log.20041025104510 10/25/2004 01:37p 1,711,062 x.log.20041025183751 10/25/2004 08:25p 1,403,988 x.log.20041026012528 10/26/2004 03:19a 1,100,582 x.log.20041026082022 10/26/2004 11:17a 2,158,910 x.log.20041026161756 10/26/2004 07:11p 1,999,926 x.log.20041027001129 10/27/2004 01:53a 1,619,614 x.log.20041027065310 10/27/2004 09:52a 1,689,744 x.log.20041027145244 10/27/2004 04:41p 1,591,043 x.log.20041027214159 10/28/2004 01:11a 1,598,140 x.log.20041028061150 10/28/2004 07:22a 1,137,471 x.log.20041028122216 10/28/2004 02:27p 1,518,661 x.log.20041028192727 10/31/2004 09:09p 16,790,875 x.log Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Reporting
Hi Pete: I think XML is the way to go. The lack of feedback may not be due to your choice of format - but rather that there really isn't too much to discuss about the obviousyfields that your sample offered. I did provide some feedback - but overall I felt you were on the right track and people probably don't just want to seem like they are talking JUST to hear themselves talk. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, June 24, 2004 02:00 PM To: Aaron Caviglia Subject: [sniffer] Reporting - was: spam leakage up We are working on specs for real-time reporting out of Sniffer and haven't had a lot of feedback on the XML based format. We were looking at this format because, in theory anyway, it's easy to port into a database or even directly into a web page or other format. Am I guessing right that the reason we didn't get a lot of feedback is because not many folks can really use XML data in practice? Should we adopt a different format for a real-time scoreboard output file? Tab delimited? CSV? --- perhaps directly to HTML? (if HTML then I will continue with the XML concept and use DOM to read the XML as a data island and format the output - anybody have experience with this - it seems harder in practice than the examples let on.) Any thoughts would be appreciated. Thanks, _M (The idea of a scoreboard was to create some useful indicators that could be read in near real-time - without a lot of heavy lifting. At the time it seemed there was a pressing need for this kind of functionality. I'm beginning to wonder - I don't want to spend effort on something that nobody really cares about. There are plenty of other features planned that we could focus on. I need some feedback. Thanks!) On Thursday, June 24, 2004, 12:02:06 PM, Aaron wrote: AC Thanks Herb but we don't have Coldfusion. AC Looks great tho! AC Aaron AC www.vantech.net AC On Jun 24, 2004, at 8:55 AM, Herb Guenther wrote: I wrote a coldfusion page that parses the logs into a sql database every night, and then the display page you saw. If you have a coldfusion server I would be happy to give you the code. Herb Aaron J.Caviglia wrote: Herb, How did you generate that SPAM report? Thanks, Aaron Caviglia www.vantech.net On Jun 24, 2004, at 8:46 AM, Herb Guenther wrote: wow, that is even worse than we are seeing, we are at about 80%, but should really be at about 85% if all were tagged. Here is our last weeks stats, we did not see an increase in volume, so much as the amount gettig thru in the last couple days and continuing today. Herb SPAM Report Statistics are based on the last 6,150,612 email messages received. You are viewing Server 1 Stats View Server 2 stats Statistic 06/17 06/18 06/19 06/20 06/21 06/22 06/23 Weekly Total Daily Avg. image.tiffDelivered Messages 34,291 30,762 22,331 22,484 31,245 33,588 33,582 208,283 25,311 image.tiffGood Messages 6,493 5,101 1,595 1,721 6,209 6,772 6,170 34,061 5,221 image.tiffSpam Messages 27,798 25,661 20,736 20,763 25,036 26,816 27,412 174,222 20,090 image.tiffSpam Percent 81% 83% 92% 92% 80% 79% 81% 84% 79% image.tiffMal Formed Headers 3,845 4,277 3,193 3,555 4,094 4,286 4,459 27,709 4,949 image.tiffSpam Headers 4,544 4,081 3,665 3,367 4,800 5,712 6,129 32,298 3,308 image.tiffSpam Routing 6,351 5,697 5,200 5,613 5,718 6,072 5,616 40,267 3,375 image.tiffNo Reverse DNS 6,864 7,787 6,529 6,729 7,742 6,783 5,023 47,457 2,446 image.tiffWhite Listed 1,157 968 116 162 1,237 1,245 1,229 6,114 785 image.tiffGeneral Spam 1,021 958 736 851 1,012 1,045 1,122 6,745 1,490 image.tiffExperimental 1,543 1,190 951 970 1,284 1,342 1,472 8,752 900 image.tiffObfuscation 240 183 158 189 196 336 151 1,453 352 image.tiffGrey Hosts 355 196 29 33 213 343 315 1,484 166 image.tiffGambling 272 202 263 261 215 303 161 1,677 124 image.tiffRefinancing/Loans 2,293 2,216 1,809 1,659 2,167 2,013 1,975 14,132 1,765 image.tiffBusiness opportunities 1,989 1,991 1,546 1,547 1,990 2,089 2,163 13,315 1,464 image.tiffInk and toner cartridges 159 124 41 91 100 89 63 667 121 image.tiffPornography 2,296 1,874 2,189 1,798 2,120 2,224 2,333 14,834 1,731 image.tiffSend money scams 57 63 66 57 85 84 82 494 65 image.tiffOnline pharmacies 6,792 6,098 5,419 4,907 5,766 5,526
