[sniffer] AOL tightens DMARC policy - Imail needs to use Remailing/Sender-Rewriting

2014-05-19 Thread Andy Schmidt
If your users forward their Imail to AOL (or other DMARC enabled providers) - 
it will now fail if the SENDER is AOL:

http://postmaster-blog.aol.com/ 

 

Ideally add your me too to the Imail Forum to get this long-known issue 
resolved:

http://forums.ipswitch.com/Topic76009-10-1.aspx 



[sniffer] Re: What is your oldest production CPU?

2013-12-30 Thread Andy Schmidt
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?

2013-12-27 Thread Andy Schmidt
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)

2013-04-18 Thread Andy Schmidt
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?

2013-04-18 Thread Andy Schmidt
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

2010-05-29 Thread Andy Schmidt
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

2010-05-29 Thread Andy Schmidt
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

2010-04-30 Thread Andy Schmidt
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

2010-01-04 Thread Andy Schmidt
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

2009-09-08 Thread Andy Schmidt
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

2009-03-10 Thread Andy Schmidt
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

2009-03-10 Thread Andy Schmidt
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.

2009-03-09 Thread Andy Schmidt
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.

2009-03-09 Thread Andy Schmidt
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

2009-02-13 Thread Andy Schmidt
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

2009-02-08 Thread Andy Schmidt
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

2009-02-08 Thread Andy Schmidt
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

2009-02-05 Thread Andy Schmidt
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

2009-02-05 Thread Andy Schmidt
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

2009-02-04 Thread Andy Schmidt
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

2009-02-03 Thread Andy Schmidt
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.

2009-02-03 Thread Andy Schmidt
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.

2009-02-02 Thread Andy Schmidt
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)

2009-02-02 Thread Andy Schmidt
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: eWall

2009-02-02 Thread Andy Schmidt
Wo - how did I miss eWall all these years? I thought ASSP was the only
game in Windows town, but I didn't like the Sniffer integration and was
worried about running on Perl.

Sadly, the eWall web site is terrible - I don't see any manual or
installation guide or anything that allows me to evaluate the software's
suitability on paper. But from the little bit that the video-walk-through
reveals when you stop the video at just the right moments to be able to
catch the screens - THIS looks like an awesome application addressing many
issues I've always wanted to address.

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: Announcing ClamAID - Clam AV installer for windows.

2009-02-02 Thread Andy Schmidt
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

2008-10-17 Thread Andy Schmidt
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!

2008-10-09 Thread Andy Schmidt
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

2008-10-09 Thread Andy Schmidt
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

2008-10-09 Thread Andy Schmidt
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

2008-10-08 Thread Andy Schmidt
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?

2008-10-08 Thread Andy Schmidt
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

2008-10-08 Thread Andy Schmidt
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

2008-10-07 Thread Andy Schmidt
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

2008-10-07 Thread Andy Schmidt
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

2008-10-07 Thread Andy Schmidt
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

2008-10-07 Thread Andy Schmidt
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

2008-10-07 Thread Andy Schmidt
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

2008-10-06 Thread Andy Schmidt
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

2008-10-05 Thread Andy Schmidt
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

2008-10-04 Thread Andy Schmidt
 

 

: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

2008-10-04 Thread Andy Schmidt
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

2008-10-04 Thread Andy Schmidt
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

2008-10-04 Thread Andy Schmidt
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

2007-08-03 Thread Andy Schmidt
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

2007-05-29 Thread Andy Schmidt
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?

2007-04-03 Thread Andy Schmidt
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?

2007-04-03 Thread Andy Schmidt
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?

2007-04-03 Thread Andy Schmidt
Hi Jonathan:

That's exactly the problem. These particular rules were blocking Google mail
servers - NOT specific content.

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.

I understand that occasionally some innocent IP can be added accidentally
and there is little to avoid that -- but for the top 50 email domains, extra
security/intelligence should be in place so that we don't suddenly reject
huge volumes of legitimate mail by blocking hotmail, aol, yahoo, google or
similar providers! These kind of errors can be caught much earlier.

Example - if a IP rules qualifier script would do a simple DNS lookup to
validate the IP address through SPF and if the RevDNS indicates one of those
top 50 email domains, then we can be virtually certain that this IP address
should not be blocked. Instead other (= content) rules must be used to block
the specific Spam.

If the script would also print a column of WHOIS and RevDNS information and
sorts it by domain, then it will be very easy for a human to review that
list and zero in on a few worrysome IP rules to qualify if they should
remain in place or need to be yanked in a hurry!

Best Regards,
Andy

-Original Message-
From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf
Of Jonathan Hickman
Sent: Tuesday, April 03, 2007 5:00 PM
To: Message Sniffer Community
Subject: [sniffer] Re: How to incorporate a white list?

This has been suggested in this past; however, I forgot the reason for not
doing so.  Personally, if someone is spamming, I do not care about the
source.  I would want it to stop.  IP blocking is dangerous, and content
often seems the most effective method of blocking spam.  If the blocks are
based on content rather than IP, it does not matter who is sending it
because it should be blocked because it appears to be spam.  If it is
blocked based on IP, the potential for false positives increases greatly as
soon as people become overzealous.

Jonathan Hickman

- Original Message - 
From: Andy Schmidt [EMAIL PROTECTED]
To: Message Sniffer Community sniffer@sortmonster.com
Sent: Tuesday, April 03, 2007 12:40 PM
Subject: [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?

2007-04-03 Thread Andy Schmidt
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

2007-01-16 Thread Andy Schmidt
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

2006-12-28 Thread Andy Schmidt
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

2006-12-28 Thread Andy Schmidt
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: Rules for Large International ISPs

2006-12-28 Thread Andy Schmidt
Hi,

 The few that I sent to their FALSE address have always been challenged as
legitimate.   

Well, I can say that so far I have no complaints with their handling of any
of my false-positive reports.

 I completely disabled SNF lookups to avoid complaints from our users 

I always used Sniffer as part of a weighting scheme to compensate for false
positives. Or, you could decide not to act on the Sniffer IP return code.

 need to ensure SNF causes no False Positives 

I agree here. While I can excuse the occasional accidental FP - there
should NOT be the mindset that customers just have to live with the fact
that the IP rules WILL always catch a certain amount of good emails, because
no effort has been made to exempt known good IP/RevDNS ranges.

I also think that the low false positive argument is built on unproven
assumptions.  To me, researching and reporting a single false positives
takes a very significant amount of time.  Bigger users may simply have no
practical way to reporting their false positives and instead just cope
with it by using weight-based systems to compensate.

The process of finding clues in the header, then finding the correct log
file and then matching log file lines in Sniffer, then creating an evidence
email, is just far too cumbersome.  I should be able to forward any falsely
identified emails (with SMTP headers) as easily as I can submit real spam
for analysis.  If that requires that Sniffer has to insert header
information with the rule number - so be it. My inclination is, if it's
currently 10 times harder to report false positives than it is to report
missed spam, then I suspect that the false positive rates could be 10 times
higher than what's actually being reported.

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 Dave Koontz
Sent: Thursday, December 28, 2006 02:46 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Rules for Large International ISPs

Well, I guess I will ruffle someones feathers again with my response here,
but like your oringial message, I think we need to be honest here.  This is
not a message sniffer 'popularity' contest after all, we are paying
customers and need to ensure SNF causes no False Postives.

Over the last few months, I've seen more an more false postives from Message
Sniffer.  The few that I sent to their FALSE address have always been
challenged as legitimate.  It's difficult at best for me to believe that our
Local Newspaper and other legitimate sites that are classified by the SNF
EXPERIMENTAL-IP rule are solid.  As a result, I've constructed SA rules to
counteract SNF False Postives.

It got so bad within the last two weeks or so that I completely disabled SNF
lookups to avoid complaints from our users.

To add insult to injury, last year they drastically up the service price.
Now my subscritpion is up for renewal.  I am honestly thinking of NOT
renewing it.  IMO, seems that things have gone down hill since ARM bought
the little company that could  Couple that with two years worth of
promises to update the MDaemon Plugin code, and all the various improvement
that Spam Assassin and SARE rulesets have made...  well I question if it's
worth the inflated cost anymore.

Shoot away Sniffer Cheer-leaders...  at least I am being honest.
 



#
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

2006-10-25 Thread Andy Schmidt
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

2006-10-25 Thread Andy Schmidt



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

2006-08-23 Thread Andy Schmidt
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

2006-02-24 Thread Andy Schmidt
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?

2006-02-21 Thread Andy Schmidt
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?

2006-02-21 Thread Andy Schmidt
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?

2006-02-21 Thread Andy Schmidt
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


[sniffer] problems!!!!

2006-02-08 Thread Andy Schmidt
Pete,

The only idea I came up with, would be to have ALL new rules go into a 6
hour proving category (=return code) before they are moved into their
final category.

By using Sniffer return codes, folks could decide to trust the established
rules and decide to cross-check any new rules by weighing them against
other sources/methods.

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: [sniffer] [Declude.JunkMail] 3.05.5 issues

2005-10-06 Thread Andy Schmidt
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

2005-10-05 Thread Andy Schmidt
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

2005-10-05 Thread Andy Schmidt
 
-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:

2005-09-05 Thread Andy Schmidt



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:

2005-09-05 Thread Andy Schmidt
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

2005-05-17 Thread Andy Schmidt




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

2005-04-18 Thread Andy Schmidt
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

2005-03-16 Thread Andy Schmidt
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

2005-03-16 Thread Andy Schmidt
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

2005-02-18 Thread Andy Schmidt
  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

2005-02-18 Thread Andy Schmidt
Hi,

You know of this one:
http://www.mailmage.com/products/software/freeutils/MilterSink/webhelp/milte
rsink_help.htm ?

Exchange server is NOT required to test SMTP sinks - just standard Windows
with IIS SMTP (you can probably even test it on XP Pro - although I have not
tried).

Yes, there ARE _EOD sinks in the field. ORF from VamSoft uses them to
support RegEx checks against the MIME content. In fact, ORF would be a great
partner for Sniffer (if only they could be convinced).

I'm in the process of deploying IIS/SMTP with ORF and a custom sink as a
gateway for Imail - and would LOVE to get Sniffer in there as well. 

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:41 PM
To: Andy Schmidt
Subject: Re: [sniffer] IIS SMTP Integration


On Friday, February 18, 2005, 1:15:36 PM, Andy wrote:

AS Hi,
AS I read this and this  sounds like it could an _EOD InboundCommand 
AS sink that hopefully would allow us  to simulate a protocol error and 
AS drop connection? If so, I can save  myself the money of having it 
AS custom-developed for me. Is this truly in the  works:
AS http://www.sortmonster.com/MessageSniffer/Help/FAQ.html#Exchange

Yes and no. I've had reports from a number of developers that they have code
that works... but when pressed, nobody will show me code.

We do not have an Exchange server here to test, nor the extended environment
that would also be required to do a good job - so we're not likely to tackle
this one in house any time soon.

At the time that was written I had hired a developer to work on it and they
assured me that it would be as easy as you have just suggested - which is
what I suggested to them. Unfortunately that project went badly and took a
lot of time and resources with it.

It seems that most folks who ask about this either disappear quickly, or
resolve to put a server in front of their Exchange box for a number of
reasons - including to run SNF and virus scanners etc...

The project to create a native SNF hook into Exchange is currently parked as
a result.

I will modify that QA until things changes.

At some point we may create a connector for Exchange, and we would be happy
(as always) to provide technical support for anyone wishing to do this.

If anyone knows of such a beast (I almost can't believe it doesn't exist
somewhere) then please let us know how we can get our hands on it.

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

2005-02-18 Thread Andy Schmidt
  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

2005-02-18 Thread Andy Schmidt
 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

2005-02-18 Thread Andy Schmidt
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.

2005-02-14 Thread Andy Schmidt
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

2005-01-10 Thread Andy Schmidt
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?

2005-01-04 Thread Andy Schmidt
 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...

2004-12-28 Thread Andy Schmidt
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

2004-12-27 Thread Andy Schmidt
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...

2004-12-27 Thread Andy Schmidt
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


[sniffer] How-To: Conditional Updates with GZIP, Log Uploads and Expiration

2004-12-27 Thread Andy Schmidt
Hi Jim,

not terribly complicated. Chances are, you have most of it in place.  Here
I'll dissect the script  that I use.  It incorporates conditional and
compressed downloads, detection of corrupted/incomplete rule-base downloads,
regular uploading of log files to Sniffer server and weekly deleting of log
files.


A) if you're using CURL to download, make sure you use the -R -z -H options.
Here the sample (must be all in one line):

curl http://www.sortmonster.net/Sniffer/Updates/[MyLicenseCode].snf 
   -o [MyLicenseCode].snf.gz 
   -s -S 
   -R -z [MyLicenseCode].snf 
   -H Accept-Encoding:gzip 
   -u sniffer:ki11sp8m

B) if you're using WGET to download, make sure you use the -N and -header
options.  Here the sample (must be all in one line):

wget -N http://www.sortmonster.net/Sniffer/Updates/[MyLicenseCode].snf 
   -O [MyLicenseCode].snf.gz 
   -q
   --header=Accept-Encoding:gzip 
   --http-user=sniffer --http-passwd=ki11sp8m 


C) Use conditional statements to see if any new updates were downloaded,
then use GZIP to uncompress the file and then validate the file:

if exist [MyLicenseCode].snf.gz goto :Check
goto :EOF
:Check
REM Unpack and validate new Sniffer rulebase
move /Y C:\[MySnifferFolder]\Win32\[MyLicenseCode].snf.gz
C:\[MySnifferFolder]
gzip.exe -d -f -N C:\[MySnifferFolder]\[MyLicenseCode].snf.gz
snf2check.exe C:\[MySnifferFolder]\[MyLicenseCode].snf [MyLicensePassword]
if errorlevel 1 goto :EOF

This will move the .gz file to a temporary folder, uncompress and validate
the .snf rule base.
If no file was downloaded or if it is not a valid rule base, it will abort
the script.


D) I like to keep a backup of my rule base, and then I replace and activate
the new rule base:

if exist [MyLicenseCode].snf.bak erase [MyLicenseCode].snf.bak
rename [MyLicenseCode].snf [MyLicenseCode].snf.bak
move /Y C:\[MySnifferFolder]\[MyLicenseCode].snf
C:\[MySnifferFolder]\Win32
[MyLicenseCode].exe reload


E) Finally - I upload my logs to the good Sniffer folks, as requested and
delete old log files after a week.

ftp -n -s:C:\[MySnifferFolder]\SnifferUpload.txt ftp.sortmonster.net
[MyLicenseCode].exe rotate
forfiles -m*.log.* -d-7 -v -ccmd /c erase @FILE


F) Add this script to a program alias, e.g.:

C:\[MySnifferFolder]\SnifferUpdate.cmd
C:\[MySnifferFolder]\SnifferUpdate.log

and register that alias with Sniffer for automatic updates.  If you don't
want to trust/rely on just one mechanism, also schedule 

  C:\[MySnifferFolder]\SnifferUpdate.cmd
C:\[MySnifferFolder]\SnifferUpdate.log

every two hours based on the staggered times listed here:

  http://www.sortmonster.com/MessageSniffer/Help/LogsHelp.html#When

Other than a quick HTTP header check to see if a new file exists every two
hours, you would not cause any loss of bandwidth for the Sniffer folks.  If
your bi-hourly update DOES download something, then their nofitications
either didn't reach you or were late.


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 Jim Matuska
Sent: Monday, December 27, 2004 01:51 PM
To: sniffer@SortMonster.com
Subject: Re: Re[2]: [sniffer] Sniffer Updates


Does anyone have any good instructions on how to modify your update scripts
to use gzip?  

Jim Matuska Jr.
Computer Tech2, CCNA
Nez Perce Tribe
Information Systems
[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


RE: [sniffer] How are folks doing with the latest version?

2004-11-19 Thread Andy Schmidt
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

2004-11-01 Thread Andy Schmidt
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] Persistent Server setup with SrvAny Resource Kit tool

2004-11-01 Thread Andy Schmidt
Hi,

Hm, well the Windows 2000 Resource Kit Tools help has the chapter Running
an Application as a Service states:

Running an Application as a Service




To specify an application to run as a service, you must use a registry
editor to add information to the Windows registry. You also have the option
of setting any required startup parameters to run the application, as well
as setting the working directory used by the application.


and then gives specific instructions...:

Click the Start button, and then click Run. 
In the Open box, type regedt32, and click OK. 
 
Add a new Parameters subkey in the following registry location: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ 
MyService\ 
In the new Parameters subkey, create an: 
Application entry with a data type of REG_SZ, 
specify the full path of the executable file for the application (including
the extension). For example: 

Application: REG_SZ: D:\Tools\Vi.exe
Setting Start Parameters
Use one of the following to set specific start parameters.

In the new Parameters subkey in the registry, create an AppParameters entry
with a data type of REG_SZ, and specify the parameters for the application.
For example: 

AppParameters: REG_SZ: C:\Tmp\EXAMPLE
- Or - 

In Services in Control Panel, click your service, and then, in the Startup
Parameters box, type the full command line required to start the
application. For example: 


D:\\Binp\\B.exe C:\\Tmp\\EXAMPLE
Note You must type two backslashes (\\) to specify a single backslash (\).

But then warns:
---

Use Services only when the service is configured to be started manually, not
when it is started by the system. If the target application is usually the
same each time you run the service, specifying it in Services is less
convenient than entering these parameters in the registry, because you must
type the parameters each time the service is started. However, if the target
application is usually different each time the service is started, using the
Services method might be more convenient.


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:26 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool



No, nothing was typed into the Services window.  The Sniffer service was
installed using the SrvAny W2K ResKit guidelines and the service starts
automatically when the server is rebooted.

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

2004-11-01 Thread Andy Schmidt
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

2004-11-01 Thread Andy Schmidt
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

2004-11-01 Thread Andy Schmidt
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


RE: [sniffer] Your Sniffer Setup

2004-11-01 Thread Andy Schmidt
Yes, I too suspect that SRVANY actually allows the specifying of the entire
command line in the Appliation string, even though both the Knowledgebase
article and the full documentation implies otherwise.  (The KB article and
the documentation are very precise in what the Application string should
be: just the path, name and extension of the executable.)

The question is whether Microsoft ever intended it to work that way or if
that possibly accidental capability may cease working at a later time.

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 Mark E. Smith
Sent: Monday, November 01, 2004 02:27 PM
To: [EMAIL PROTECTED]
Subject: RE: [sniffer] Your Sniffer Setup


Looks like both work. If you examine the difference you'll probably see why.
One (just with the Application setting specifies all of the parameters in
the SZ string.

The other specifies the .exe in the App string and the Auth Code and
persistent parameter in the parameters string. I'm also guessing that
Sniffer really doesn't care about the app path so it's probably working in
this case.

The proper way is probably the way where multiple SZ values are specified
although both will work with Sniffer.



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?

2004-10-31 Thread Andy Schmidt
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?

2004-10-31 Thread Andy Schmidt
Pete,

- okay, I ran the STOP command - it never ended
- the persistent command window never ended
- I finally stopped the SERVICE and the stop command ended
- I finally CLOSED the command window to flush the persistent task

Then I saw a whole bunch of sniffer tasks launch in the task window - so I
assume it was no longer running in persistent mode.  After watching this for
2 minutes, I restarted the server.

Now I tried against

mylicense.exe rotate

from the command line. 
- It DOES return, I see no error message.
- It creates an EMPTY mylicense.ROTATE file !?
- It does NOT rename the active log and continues to use 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: 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[2]: [sniffer] LogRotate no longer working?

2004-10-31 Thread Andy Schmidt
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?

2004-10-31 Thread Andy Schmidt
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

2004-10-31 Thread Andy Schmidt
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


RE: [sniffer] Persistent Server setup with SrvAny Resource Kit tool

2004-10-31 Thread Andy Schmidt
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

2004-06-24 Thread Andy Schmidt
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