[sniffer] Re: Server didnt restart
Serge, If you wanted to feed those back logged messages into the proc folder on a scheduled interval you may want to use one of our utilities (MoveFiles). It's free. The benefit is that new mail coming in will not be delayed and you can feed those messages back into the proc folder as your server can process them and keep up with new mail. Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Paul Rogers wrote: They will get processed it's just a matter of how long it will take. I think the answer will depend on how many messages per hour your server normally processes. You didn't specify how long your server was offline so we can only guess how long it took to accumulate 40k messages (and thus a per hour inbound rate). At max capacity I see my main server process (through sniffer/latest beta) about 800-1000 messages per minute (60k/hour)...that would be on a quad xeon (on SATA drives). So at that rate (assuming no other incoming email which can slow the overall process down) maybe an hour. But since the server also has normal incoming emails to deal with as well, it may take 90-120 mins to completely clear a queue that size. Keep an eye on your proc folder q file count... dir q*.* /w Paul --- -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Tuesday, November 20, 2007 8:02 AM To: Message Sniffer Community Subject: [sniffer] Server didnt restart Hello My server rebooted last night. Sniffer server did not restart correctly. I fixed that, but i have 40K+ message in the imail/spool/proc, most inbound and not yet localy delivered. Will they be reprocessed automaticaly ? or is there something else i need to do ? How long will it take ? (dual xeon 1.266 GHz) TIA # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> --- [This E-mail scanned for viruses by Declude EVA] # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
You nailed it Pete, Thanks! Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Pete McNeil wrote: Hello Darrell, Tuesday, October 16, 2007, 9:26:47 PM, you wrote: Pete, Can you cover how the communication for the GBUdb system works? Sure. (And documentation is coming along with a web site redesign, so there will be plenty of additional detail on all things new SNF arriving over the next few weeks). Who does it exchange information with and how? Does it need special ports open? I'm going to assume this question is at least in part about security issues so I will frame my response from that perspective: Every minute or so (adjusted dynamically by the system) each new SNF node contacts one of our SYNC servers. The connection is made to port 25 by default. Since most MTAs will regularly make these kinds of connections no special ports will need to be open. If your MTAs are not allowed make outbound connections to port 25 for some reason then you have the option to make the connection to port 80. Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. The authentication protocol used to identify properly licensed SNF nodes is described in the file AuthenticationProtocol.swf. This file is included in the beta distributions and is also visible in the page linked below. At present there is no mechanism for connections to be made into SNF nodes -- only from SNF nodes to the SYNC servers. Also, there is no mechanism that allows the SYNC server (or any of our systems) to manipulate the SNF nodes except by the protocols described in the GBUdb documentation and by reporting update availability, tuning data, etc. This link helps explain how these interactions work: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.GBUdb The SYNC system is separate from the rulebase delivery system. All of the data transmitted and received by the SNF nodes is in plain text or base64 encoded. The format of the data is XML. With the exception of GBUdb traffic, the telemetry transmitted to us is available to you directly in the .status. reports made by the SNF engine. Status reports can be found in the same directory as your SNF log files. You can use these XML based posts to create your own real-time monitoring systems. In addition to the GBUdb functions, the telemetry eliminates the need to send in log files by providing near real-time pattern matching statistics; supports virtual spamtraps and other collaborative learning systems; and provides performance analysis, error detection / correction, and system tuning metrics. One other security note -- the virtual spamtrap system can be turned off easily if you wish. Normally the virtual spamtrap system will send us a random sampling of messages that come from the worst known IPs when those messages do not match known pattern rules. In most systems, these are messages that would normally be discarded. Samples are infrequent by design so they should not account for any appreciable bandwidth. Similarly, the GBUdb protocol is designed to share information sparsely so that no appreciable bandwidth or CPU capacity is required. Please let me know if I missed the mark on your questions. Hope this helps, _M -- # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Pete, Can you cover how the communication for the GBUdb system works? Who does it exchange information with and how? Does it need special ports open? Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Pete McNeil wrote: Hello Keith, First off-- there is a lot of misunderstanding in this message. I'm sorry for any confusion. For those watching - please read my responses carefully and hopefully they will clear things up quite a bit. Tuesday, October 16, 2007, 3:36:23 PM, you wrote: Pete, I am attempting to get caught on the latest beta and just have a few questions. I noticed Sniffer is now called a different way in the Declude config files, is that correct? Yes, but not very differently. The best way to adjust your Declude (or similar) configuration files for calling the new SNF is to REM out your existing settings, make a copy, and in your new copy change the name & path of the SNF executable so that it points to the new SNFClient.exe program. You do not need to rename SNFClient.exe. It will accept the same command line parameters that the earlier version of SNF expects - so the only change you really have to make is the name/path to the SNF executable you call to scan your messages. On the last release (running persistent), we have numerous entries in the declude.cfg file labeled: SNIFFER-TRAVEL external047 "C:\IMail\Declude\Sniffer\WeightGate.exe -12 %WEIGHT% 19 C:\IMail\Declude\Sniffer\snifferlic.exe codehere" 20 However, it appears the categories are going away (posted in some previous messages) and there is a since of urgency needed in upgrading as these won't be populated any longer soon. THIS IS NOT TRUE. The rule categories are staying just like they are. Perhaps the confusion is that one rule group, the IP rules, has been deprecated. It's functionality is being replaced by the GBUdb system which will return the same result code (63) for IPs in the "Black" range. The GBUdb will also return some additional values for special cases. By default: If the IP is in the White range, return 0. If the IP is in the Caution range, return 40. If the IP is in the Truncate range, return 20. What you will want to do is: * Make the changes to your configuration so that you are calling the SNFClient instead of . * Add two additional "tests" for the 40 result code and the 20 result code. I suggest making the 40 result code a slightly lower weight than you usually give to SNF - probably something similar to what you give a fairly accurate RBL. I suggest giving the 20 result code the same weight as SNF or possibly a higher weight. The "meaning" of the 40 result code is - "We don't trust this IP. We don't know a lot about it, but what we've seen so far looks like spam." The "meaning" of the 20 result code is - "We've watched this IP for a while now and this IP sends spam so consistently that we don't even look at the content any more - we just skip the message as soon as we see the IP." I take it we run the persistent mode the same way, but have a different hook into Declude? With the new SNF instead of running persistent, you run \SNFServer.exe \snf_engine.xml. By the way - if you have a persistent instance running, you DO NOT need to stop it to run the new SNFServer.exe. You can run both together and they will leave each other alone. This way you can switch back and forth easily just by calling the correct client --- either the original SNF installation you have or the new SNFClient. Whichever one you are NOT calling will more-or-less sleep while the other works. Once you are satisfied with the results and your installation you can then tear down the old one (if you wish). Hope this helps, _M -- # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Error Messages since WeightGate
After looking into it I am on board with what Pete said about the "heap" issue. It makes sense to me that its the heap issue since were launching weight gate -> SNF. Effectively doubling the amount of processes being launched. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Keith Johnson wrote: Darrell, You are right, a reboot will take care of it for a season, then it comes back out of the blue. Very strange indeed. Keith _ From: Message Sniffer Community on behalf of Darrell ([EMAIL PROTECTED]) Sent: Sat 6/9/2007 9:36 PM To: Message Sniffer Community Subject: [sniffer] Re: Error Messages since WeightGate Keith, I was having the same problems last week. Just came out of the blue and was across several of our servers as well. Same error verbatim. FWIW - I also use weightgate. I rebooted the servers I was seeing this issue on and the problem has not returned. Very odd you mentioned that as I thought this was isolated to just me. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Keith Johnson wrote: It appears since installing WeightGate we have been receiving a lot of the below Application PopUps indicating an error: The application failed to initialize properly 0xc142. Click on OK to terminate the application The application entry is our Sniffer .exe. Today alone I saw over 300. I thought it was an isolated issue. However, it is happening across all our servers. We are running the latest Sniffer in Persistent mode. We never saw these prior to WeightGate. Has anyone seen this before? Below is the actual entry in Event Log. -Keith Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 6/9/2007 Time: 12:12:35 AM User: N/A Computer: NAIMAIL2 Description: Application popup: rrctp2ez.exe - Application Error : The application failed to initialize properly (0xc142). Click on OK to terminate the application. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Error Messages since WeightGate
Keith, I was having the same problems last week. Just came out of the blue and was across several of our servers as well. Same error verbatim. FWIW - I also use weightgate. I rebooted the servers I was seeing this issue on and the problem has not returned. Very odd you mentioned that as I thought this was isolated to just me. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Keith Johnson wrote: It appears since installing WeightGate we have been receiving a lot of the below Application PopUps indicating an error: The application failed to initialize properly 0xc142. Click on OK to terminate the application The application entry is our Sniffer .exe. Today alone I saw over 300. I thought it was an isolated issue. However, it is happening across all our servers. We are running the latest Sniffer in Persistent mode. We never saw these prior to WeightGate. Has anyone seen this before? Below is the actual entry in Event Log. -Keith Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 6/9/2007 Time: 12:12:35 AM User: N/A Computer: NAIMAIL2 Description: Application popup: rrctp2ez.exe - Application Error : The application failed to initialize properly (0xc142). Click on OK to terminate the application. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Best renewal price and service on Sniffer?
You can renew via Declude using the online store. I have never had a problem renewing through the store. They will ask for your license ID and everything from there took care of itself. Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Steve Guluk To: Message Sniffer Community Sent: Friday, May 18, 2007 10:26 AM Subject: [sniffer] Best renewal price and service on Sniffer? Hello, I was informed some time back that I needed to renew my subscription to Sniffer soon. I sent an email to [EMAIL PROTECTED] on May 3rd and never got a response back. Today is the last day on my subscription. Does anyone have any suggestions on where to renew, at the best price? Regards, Steve Guluk SGDesign (949) 661-9333 ICQ: 7230769
[sniffer] Re: Configuring Sniffer in declude....
Chuck, Declude will only call Sniffer one time as long as the path and executable are identical which they are. Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: "Chuck Schick" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, November 29, 2006 2:16 PM Subject: [sniffer] Configuring Sniffer in declude Several years ago when we first started using message sniffer I set it up for in the following manner in my global.cfg file. SNIFFER-GENERALexternal063 "F:\IMail\Declude\sniffer2r32\licensecode.exe activationcode" 70 SNIFFER-EXPERIMENTALexternal062 "F:\IMail\Declude\sniffer2r32\licensecode.exe activationcode" 120 SNIFFER-OBFUSCATIONexternal061 "F:\IMail\Declude\sniffer2r32\licensecode.exe activationcode"110 So one and so forth. With the increase in spam and CPU load is there any advantage load wise to just call sniffer once using nonzero instead of the return code. It seems like someone told me that sniffer was only called once and not seperately for each return code. Could someone confirm that. Chuck Schick Warp 8, Inc. (303)-421-5140 www.warp8.com # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: New SPAM pain
(*) Please keep in mind this is for one of the systems I maintain - who has a very wide diverse set of mail. Your mileage may vary. Here are some stats gathered with DLAnalyzer on Zerohour. ***This is only a one day analysis. * Triggered on 42,013 messages out of 99,842 total messages * 40K of the 42K hits were on messages already considered spam and held. * Out of the 42K Zerohour detections 39K of those were also detected by Sniffer. * DLAnalyzer's test quality rates Zerohour as .95. (SEE EXPLANATION BELOW ON THIS) * Zerohour triggered on 1,020 hams. In my visual those hams a good portion were false positives on bulk solicited mail (Home Depot, Marta Stewart, USDA, GOP Senators, Democratic National Committee, etc). I can go into more detail on this if anyone wants more info offline. For those that do not use DLAnalyzer it has a built in test quality report. The test quality score is based on a -1 to 1 scale where -1 indicates HAM and 1 indicates spam. The closer to 1 the more likely the test is at detecting SPAM and the closer to -1 indicates HAM. Other Test's Test Quality Scores Message Sniffer - .99 invURIBL - .99 Zerohour - .95 Spamcop - .94 MxRate Black - .93 Fiveten - .92 Sorbs Spam - .71 At this point I have not evaluated CommTouch's false positive reporting. That portion of my testing will come very soon. Are any of my results scientific - no. Will I be dropping Message Sniffer - Absolutly not. Will I continue using CommTouch - yes - as I think it has a place on my system. Will your results and conclusions vary - absolutly. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Pete McNeil writes: Hello Darrell, That's fine. _M Wednesday, July 26, 2006, 2:43:27 PM, you wrote: If Pete doesn't mind I will post my observations in regards to the product. I run both products (CommTouch and Sniffer). Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. John Shacklett writes: I'm dying to start a thread and talk about Sniffer's stance on CommTouch, but I can resist. Instead, I would like to point out that eight clearly spam messages have made it through to my Inbox [or Outlook Junk Folder] so far this week that appear to have skinned clear through Sniffer. First ones I've seen in > >Are we undergoing a new phase or campaign that I can make adjustments for? -- John # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: New SPAM pain
The more I think about it I am sorry about this post below - it kinda put's Pete on the spot - and I am sorry about that. Def. not my intention.. Darrell Darrell ([EMAIL PROTECTED]) writes: If Pete doesn't mind I will post my observations in regards to the product. I run both products (CommTouch and Sniffer). Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. John Shacklett writes: I'm dying to start a thread and talk about Sniffer's stance on CommTouch, but I can resist. Instead, I would like to point out that eight clearly spam messages have made it through to my Inbox [or Outlook Junk Folder] so far this week that appear to have skinned clear through Sniffer. First ones I've seen in > >Are we undergoing a new phase or campaign that I can make adjustments for? -- John # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: New SPAM pain
If Pete doesn't mind I will post my observations in regards to the product. I run both products (CommTouch and Sniffer). Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. John Shacklett writes: I'm dying to start a thread and talk about Sniffer's stance on CommTouch, but I can resist. Instead, I would like to point out that eight clearly spam messages have made it through to my Inbox [or Outlook Junk Folder] so far this week that appear to have skinned clear through Sniffer. First ones I've seen in > >Are we undergoing a new phase or campaign that I can make adjustments for? -- John # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: ANN: Availability of 5xxSink 0.5.00, IIS SMTP event sink for text-file recipient validation
Sandy actually released an updated version that allows for that. http://www.mail-archive.com/declude.junkmail@declude.com/msg27158.html Darrell fpReview - Review held mail the easy way. http://www.invariantsystems.com - Original Message - From: "Paul Fuhrmeister" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, June 14, 2006 9:17 PM Subject: [sniffer] Re: ANN: Availability of 5xxSink 0.5.00, IIS SMTP event sink for text-file recipient validation Does anyone know of a similar solution that allows wild cards (allow anything at domain name). We still have some customers using catch-all accounts. Paul Fuhrmeister [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Saturday, December 03, 2005 6:29 AM To: Declude.JunkMail@declude.com; IMail_Forum@list.ipswitch.com; Declude.Virus@declude.com; sniffer@SortMonster.com Subject: [sniffer] ANN: Availability of 5xxSink 0.5.00, IIS SMTP event sink for text-file recipient validation All, I've posted 5XXSINK, an IIS SMTP event sink (freeware) that allows you to block unknown recipients at your IIS 5.0 or 6.0 MX by populating a barebones textfile. Those who use the powerful IIS SMTP engine as an MX have no built-in method of preventing brute-force spam runs from overwhelming their internal content scanning and mailbox servers with wasted message processing and double-bounce generation. Several commercial anti-abuse products can add this functionality, but they can add undue cost to a large server farm, and seem like overkill when a well-tuned content scanning engine (IMail's, Declude's, etc.) already exists internally, save for the fact that it sees messages that should never get that far. While it is debatable whether having envelope recipient validation at your MXs will reduce the number of spammers making initial connections to you, it cannot be denied that having such validation will save your hardware and bandwidth resources beyond the first part of the SMTP conversation. Recipient validation at the MX can make the difference between a workable anti-spam content scanner and one that fails because it's overwhelmed by messages it should never see. 5XXSINK is designed to do one thing, do it well, and do it for free: to look up full e-mail addresses in a locally stored text file and reject all RCPT TO commands that do match a line in the file. That's it. 5XXSINK is NOT designed to do any of the following: connection throttling, tarpitting, greylisting, sender validation, HELO interpretation, or DNSBL lookups. It expects that a robust content scanning solution exists behind, or perhaps on, the IIS SMTP server (although commercial IIS SMTP integrations solutions usually duplicate 5XXSINK's recipient validation functionality -- and then some). Again, the sole function is to keep messages that absolutely, positively do not need to be scanned out of the scanning path. There are no false positives with recipient validation, so it's an obvious first step in an anti-abuse chain. 5XXSINK is multithreaded and likely performs its very particular function as fast as practically possible. * * * Download: http://www.imprimia.com/products/software/freeutils/5xxsink/download/release Be sure to go over the README in-depth. That's where it's at. Support: Through the IMail and Declude support lists, as the communities primarily served by the product. Please post support questions as [OT] to create a public archive and to encourage knowledge sharing. --Sandy 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 is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
Re: [sniffer] Watch out... SURBL & SORBS full of large ISPs and Antispamprovidres.
Pete, I just checked real quick hitting several DNS servers (mine and others) and I am not seeing this - are you still seeing this now? C:\>nslookup 2.0.0.127.multi.surbl.org Server: nscache5.bflony.adelphia.net Address: 68.168.224.180 Non-authoritative answer: Name:2.0.0.127.multi.surbl.org Address: 127.0.0.126 C:\>nslookup declude.com.multi.surbl.org Server: nscache5.bflony.adelphia.net Address: 68.168.224.180 *** nscache5.bflony.adelphia.net can't find declude.com.multi.surbl.org: Non-exi stent domain C:\>nslookup w3.org.multi.surbl.org Server: nscache5.bflony.adelphia.net Address: 68.168.224.180 *** nscache5.bflony.adelphia.net can't find w3.org.multi.surbl.org: Non-existent domain Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: "Matt" <[EMAIL PROTECTED]> To: Sent: Tuesday, January 17, 2006 7:21 AM Subject: Re: [sniffer] Watch out... SURBL & SORBS full of large ISPs and Antispamprovidres. Pete, w3.org would be a huge problem because Outlook will insert this in the XML headers of any HTML generated E-mail. If you could give us an idea of when this started and possibly ended, that would help in the process of review. Thanks, Matt Pete McNeil wrote: Hello Sniffer Folks, Watch out for false positives. This morning along with the current spam storm we discovered that SURBL and SORBs are listing a large number of ISP domains and anti-spam service/software providers. As a result, many of these were tagged by our bots due to spam arriving at our system with those domains and IPs. Most IPs and domains for these services are coded with "nokens" in our system to prevent this kind of thing, but a few slipped through. We are aggressively hunting any more that might have arrived. You may want to temporarily reduce the weight of the experimental IP and experimental ad-hoc rule groups until we have identified and removed the bad rules we don't know about yet. Please also do your best to report any false positives that you do identify so that we can remove any bad rules. I don't expect that there will be too many, but I do want to clear them out quickly if they are there. Please also, if you haven't already, review the false positive procedures: http://www.sortmonster.com/MessageSniffer/Help/FalsePositivesHelp.html Pay special attention to the rule-panic procedure and feature in case you are one of the services hit by these bad entries. An example of some that we've found in SURBL for example are declude.com, usinternet.com, and w3.org It's not clear yet how large the problem is, but I'm sure it will be resolved soon. Hope this helps, Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) Chief Scientist (www.armresearch.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 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] Rash of false positives
It is used in both versions for different things. Darrell ---Check out http://www.invariantsystems.com for utilities for Declude, mxGuard, and Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Serge To: sniffer@SortMonster.com Sent: Wednesday, November 09, 2005 9:27 PM Subject: Re: [sniffer] Rash of false positives i thought declude.cfg is for V 3.x Am I wrong ? is declude.cfg used with V 2.x ? - Original Message - From: John Moore To: sniffer@SortMonster.com Sent: Wednesday, November 09, 2005 11:12 PM Subject: RE: [sniffer] Rash of false positives Matt, Thank you for your help and thorough explanation. I added the declude.cfg with the PROCESSES 20 We are running declude 2.06 and have the JM pro and AV standard. We will look into getting the persistent mode setup and see if that helps as well. Thanks, again. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Wednesday, November 09, 2005 4:49 PMTo: sniffer@SortMonster.comSubject: Re: [sniffer] Rash of false positives John,The mystery heap issue is a memory issue with Windows where it only reserves so much memory for running things like Declude, Sniffer, other external tests and your virus scanners. If you have something that is hanging, running slowly, or taking too long, it can gobble up all of the memory available to these launched processes and then result in errors. Generally speaking, you can only get about 40 or so processes of these types to run at one time before you could start seeing these errors. Declude counts as one process, and often there is one other process that Declude launches that goes to this count (external tests and virus scanners are all run in serial so only one can be launched at a time by a single Declude process). If you have something like a virus scanner that crashes and then pops up a window on your next login, this can count towards the number of open processes.You can specify in Declude how many processes to run before Declude starts dumping things into an overflow, either the overflow folder in 2.x and before, or something under proc in 3.x. If you create a file called Declude.cfg and place in it "PROCESSES 20" that should protect you from hitting the mystery heap's limitations unless something is crashing and hanging. You might want to check Task Manager for processes to verify if things are hanging since not everything will pop up a window.I believe that running Sniffer in persistent mode will help to alleviate this condition, but it's only one part and if the mystery heap is the cause, it might just cause the errors to be triggered on other IMail launched processes including Declude.exe and your virus scanners.MattJohn Moore wrote: We have not run snf2check on the updates. And it may be a coincidence or bad timing that sniffer appears to be the culprit. But we have stopped sniffer (commented out in the declude global.cfg) for an observed period of time and the mail never stops (and had never stopped before sniffer) and conversely, it only stops when sniffer is running. We have not gone the extra steps of putting sniffer in persistent mode. We are looking at moving the imail/declude/sniffer setup to a newer box with more resources. Currently on a dell 2450 dual 833 and 1 gig of ram and raid 5. Volume of email is less than 10,000 emails per day. J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darin CoxSent: Wednesday, November 09, 2005 1:47 PMTo: sniffer@SortMonster.comSubject: Re: Re[4]: [sniffer] Rash of false positives Are corrupted rulebase files the culprit? How do you update... and do you run snf2check on the updates? Just wondering if the rulebase file is the problem, if the problem occurs during the update, or if you are running into obscure errors with the EXE itself Darin. - Original Message - From: John Moore To: sniffer@SortMonster.com Sent: Wednesday, November 09, 2005 12:42 PM Subject: RE: Re[4]: [sniffer] Rash of false positives We had this same thing happen. It has been happening more frequently recently and we are looking into disabling sniffer as it seems to be the culprit each time. John Moore305 Sp
Re: [sniffer] Rash of false positives
I too have had to submit a lot more false positives lately. I also second that false positive processing seems to be a lot slower than previously. Darrell Check out http://www.invariantsystems.com for utilities for Declude, mxGuard, And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Scott Fisher writes: I don't know if I would call it a rash, but over the last week, I've submitted about 30 false positives. That's far more than average. I've developed a feeling that Message Sniffer has become "too tight". - Original Message - From: Darin Cox To: sniffer@SortMonster.com Sent: Tuesday, November 08, 2005 8:54 AM Subject: Re: [sniffer] Rash of false positives We're seeing a continual stream of false positives. It's taking all of our time just to keep up with it at the moment. If something isn't done soon, we're going to have to disable sniffer. Darin. - Original Message - From: Computer House Support To: sniffer@SortMonster.com Sent: Tuesday, November 08, 2005 9:34 AM Subject: Re: [sniffer] Rash of false positives Dear Darin, Thanks for the heads up. It's going to take me about 45 minutes to check the 9000 messages that were blocked by Sniffer last night, but I'll let you know if we experienced the same thing. Michael Stein Computer House www.computerhouse.com - Original Message - From: Darin Cox To: sniffer@SortMonster.com Sent: Tuesday, November 08, 2005 8:45 AM Subject: [sniffer] Rash of false positives Hi Pete, What's going on over there? We had somewhere between 5 and 10 times the usual number of Sniffer false positives this morning. They are across the board, so it's not just one rule that's catching them, or a particular set of senders or receivers. Hopefully you can get it under control soon. It would also be extremely helpful if you could speed up the false positive processing. Lately it seems to take 2-4 days for the rules to be adjusted, which usually means more of the same are caught and submitted over that time. I believe speeding up that process would result in fewer to process all around. Thanks, Darin. 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] Sniffer Resources
How does AVAFTERJM help? Unless you had JunkMail delete the message it would seem that it has to be scanned for viruses either way. This is more appropriate on the Declude list - but with that said you are correct in order for it to make a major impact you need to have actions that either hold, delete, or bounce for this to make a huge difference. I don't know which uses more processor time... Virus or SPAM scanning. If you use a bunch of tests it probably takes more horsepower to scan for SPAM than viruses. If that's the case then it would see like you would want to virus scan FIRST. Any message deleted by the virus scanner don't need to be scanned for SPAM. Couple of things to keep in mind. One such thing is virus scanner - if you use Mcafee it is VERY resource intensive so this helps alot. The other thing which complements the first point is that most normal servers have approx 95%+ spam volume and if you don't have to virus scan 95% of mail than it saves a lot of resources. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, 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
Re: [sniffer] Sniffer taking a long time?
What kind of box are you running Sniffer on and what is your CPU. I have found that most of the messages that get scanned on my system by Sniffer are done in under a second. Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Dan Horne writes: More info: When I stop the Sniffer service, processing time goes to milliseconds. Start the service back and it is back up to a minute. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Monday, August 01, 2005 11:58 AM To: sniffer@SortMonster.com Subject: RE: [sniffer] Sniffer taking a long time? Here are the sniffer log entries for each of the messages, if that helps any: > 08/01/2005 11:32:51.747 Q40a201cc1a59 SNIFFER: External program > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe > mysnifferauthcode S:\imail\spool\D40a201cc1a59.SMD > 08/01/2005 11:33:46.751 Q40a201cc1a59 SNIFFER: External program > reports exit code of 61 20050801153252 D40a201cc1a59.SMD 70 20 Match 266707 61 343 358 50 20050801153252 D40a201cc1a59.SMD 70 20 Match 426427 61 1915192950 20050801153252 D40a201cc1a59.SMD 70 20 Final 266707 61 0 502050 > 08/01/2005 11:30:53.757 Q402b01b61a28 SNIFFER: External program > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe > mysnifferauthcode S:\imail\spool\D402b01b61a28.SMD > 08/01/2005 11:31:48.210 Q402b01b61a28 SNIFFER: External program > reports exit code of 52 20050801153054 D402b01b61a28.SMD 80 10 Match 372669 52 2745286060 20050801153054 D402b01b61a28.SMD 80 10 Match 423177 61 2695303660 20050801153054 D402b01b61a28.SMD 80 10 Match 372652 61 2695313860 20050801153054 D402b01b61a28.SMD 80 10 Final 372669 52 0 495260 > 08/01/2005 11:30:56.561 Q402a01cc1a27 SNIFFER: External program > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe > mysnifferauthcode S:\imail\spool\D402a01cc1a27.SMD > 08/01/2005 11:31:51.074 Q402a01cc1a27 SNIFFER: External program > reports exit code of 0 20050801153056 D402a01cc1a27.SMD 190 40 White 137999 0 2256228544 20050801153056 D402a01cc1a27.SMD 190 40 Final 137999 0 0 24419 44 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] Spam blocks loading me up with spam
Scott, Not to many incoming for me - about 200 out of about 125K messages. One thing to note is the ones I am getting are around that block but even lower like 200.49.44.x. Darrell ---Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Scott Fisher To: sniffer@SortMonster.com Sent: Thursday, June 16, 2005 6:04 PM Subject: [sniffer] Spam blocks loading me up with spam Am I the only one getting blasted by these spam from these IP blocks? Sniffer seems a little behind on catching these. 200.49.48.0/24 200.49.48.0/24 200.49.49.0/24 200.49.49.0/24 mowz2.com 200.49.50.0/24 200.49.50.0/24 qckcstmr.com 200.49.51.0/24 200.49.51.0/24 srvdupfrsh.com 200.49.52.0/24 200.49.52.0/24 aahtv.com 200.49.53.0/24 200.49.53.0/24 aakai.com 200.49.54.0/24 200.49.54.0/24 aakib.com 200.49.55.0/24 200.49.55.0/24 aakli.com 200.49.56.0/24 200.49.56.0/24 aafix.com 200.49.57.0/24 200.49.57.0/24 e.com 200.49.58.0/24 200.49.58.0/24 200.49.59.0/24 200.49.59.0/24 Domain names and links seem to be five chars beginning with aa. They also seem to be progressing through the IP blocks. i think they started in on the June 15th and have been spamming pretty consistantly.
Re: [sniffer] Spam blocks loading me up with spam
Scott, Not to many incoming for me - about 200 out of about 125K messages. One thing to note is the ones I am getting are around that block but even lower like 200.49.44.x. Darrell ---Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Scott Fisher To: sniffer@SortMonster.com Sent: Thursday, June 16, 2005 6:04 PM Subject: [sniffer] Spam blocks loading me up with spam Am I the only one getting blasted by these spam from these IP blocks? Sniffer seems a little behind on catching these. 200.49.48.0/24 200.49.48.0/24 200.49.49.0/24 200.49.49.0/24 mowz2.com 200.49.50.0/24 200.49.50.0/24 qckcstmr.com 200.49.51.0/24 200.49.51.0/24 srvdupfrsh.com 200.49.52.0/24 200.49.52.0/24 aahtv.com 200.49.53.0/24 200.49.53.0/24 aakai.com 200.49.54.0/24 200.49.54.0/24 aakib.com 200.49.55.0/24 200.49.55.0/24 aakli.com 200.49.56.0/24 200.49.56.0/24 aafix.com 200.49.57.0/24 200.49.57.0/24 e.com 200.49.58.0/24 200.49.58.0/24 200.49.59.0/24 200.49.59.0/24 Domain names and links seem to be five chars beginning with aa. They also seem to be progressing through the IP blocks. i think they started in on the June 15th and have been spamming pretty consistantly.
Re: [sniffer] MDLP Tests
>>Also, perhaps I am misunderstanding the data, but SNIFFER has a SQ of >>.802 - isn't that relatively "bad" ? Most people do not have single tests that mark the message as spam. Sniffer has the tendancy to hit on messages where others tests do not. So for example on my system Sniffer may hit and mark the messgae with a weight of 8 and we tag at 10. So in this case the message is marked per MDLP standards as "ham" when in deed the message was "spam". Sniffer is very effective... Darrell --- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, 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
Re: [sniffer] mini-obfuscation
Pete,
Doesnt Sniffer have a certain level of support for regex's? I know we have
had good luck with regex's like this which catch obfuscation techniques with
viagra with Declude. We found it easier to use regex's than to list all of
the different variations.
(?:\b|\s)[_\W]{0,3}(?:\\\/|V)[_\W]{0,3}[ij1!|l\xEC\xED\xEE\xEF][_\W]{0,3}[a4
[EMAIL PROTECTED],3}[xyz]?[gj][_\W]{0,3}r[_\W]{0,[EMAIL PROTECTED],
3}x?[_\W]{0,3}(?:\b|\s)
Darrell
Check out http://www.invariantsystems.com for utilities for Declude And
Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG
Integration, and Log Parsers.
Pete McNeil writes:
On Tuesday, March 22, 2005, 8:31:07 PM, Andrew wrote:
CA> How many times have we all been frustrated that a piece of spam ending
CA> up in *OUR* mailbox that was s close in content to spam we whacked
CA> yesterday?
CA> I thought the top "n" obfuscations might be interesting to look at, and
CA> perhaps a shortcut (temporary, albeit) for spam catching. I thought we
CA> might see whether, for example, broken URLs, fake comments, or high-bit
CA> ASCII character substitutions were the obfuscation technique du jour.
Here you hit it IMHO. The reality appears to be, from my experience,
that small domains of obfuscation patterns rise and fall like swells
on the ocean. That is, stability tends to arise in one domain of
message characteristics and then fall to rise in another domain.
Sometimes the domain is well understood and sometimes it is entirely
new and forces us to think differently about what a "feature" really
is.
By domain I mean things like message structure, word obfuscation
techniques, phrase based swapping, html exploitation, etc...
The "du jour" part of your statement is a key element to the problem.
Defining and re-defining the conceptual framework that describes
feature domains in the spam is the other key element.
Put more simply - knowing what to look for is a basic element, but it
gets you nowhere on it's own. Knowing (recognizing) when to look for
the "what" is the key that makes the problem workable.
CA> I while back curiousity got the better of me (it was raining, and
CA> I had a few days off) and I did a few grep sweeps on a warm spam
CA> corpus.
CA> I was disappointed in my success rate for:
CA> v.?i.?a.?g.?r.?a.?
CA> and similar queries with deliberately substitutions (e.g. using a "1"
CA> for "i"). I started writing a grep-generating-permutation engine and
CA> decided my time was better spent on scritching my cat under his chin.
That is a nifty direction that I wish I had more time for. Perhaps I
will some day soon when Sniffer get's slashdotted and sales go through
the roof!
--- meantime, back on this planet, I suggested a very similar thing to
Paul Graham at the first spam conference at MIT. As I recall he said
it was "ambitious" - a description that I have learned has a special
meaning in scientific circles. Something having to do with avian swine
and snowballs that have successful careers as tour guides in hell.
One of these days I think I might do it anyway, just to prove the
point, but in the mean time I too prefer to spend more time with my
cat. ;-)
Don't get me wrong - I strongly believe it can be done this way, but
it requires much more than good technology. It runs right into one of
the biggest problems with AI and, perhaps more importantly, people's
expectations of AI. No matter how good the pattern learning system
might be it will always lack the human experience. Computers don't
date or gain weight - so they have a hard time understanding what much
of the spam is "about" simply by looking at the patterns. That's why
the Message Sniffer process is designed with people tightly integrated
into the system.
_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] OT - Microsoft Patch Day - Exchange and SMTP updates
The MS04-35 reissue some how slipped under the radar yesterday of the other patches.. So far no public exploits for that. However, SANS is indicating POC code has been released for MS05-05/09. So far for the cycle I patched one LOW volume production mail server and one standby server. Both of those are showing no issues. Anyone else apply these yet? Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, MRTG Integration, and Log Parsers. Colbeck, Andrew writes: Hello, all. Aside from the usual Internet Explorer and Office patches, this patch cycle also includes an update to the October update MS04-035 which affects a DNS query vulnerability in the SMTP handling in Windows 2000/2003 as well as Exchange 2003. http://www.microsoft.com/technet/security/bulletin/ms04-035.mspx 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] invURIBL (SURBL URI Query) Important Notice On Beta 4
After working with Andy we found that a DLL was missing out of our beta 4 package. If you downloaded invURIBL for the first time as Beta 4 you may be missing a DLL that was not included in that specific package. This DLL is used for additional mime decoding. I would recommend that everyone who downloaded Beta 4 please do so again as the package has been corrected to include the DLL. - http://www.invariantsystems.com/invuribl/default.htm We also recommend if you are using invURIBL that you please join the list serve for the application to stay informed on its status ([EMAIL PROTECTED]). Again, I am sorry for the inconvenience. Darrell Andy Schmidt writes: Hi Phil: A) I just corrected a bug in the setup of invURIBL (which is used to test again SURBL). I don't know yet what the impact is - but I BELIEVE that bug had caused more messages to be tagged than should have. Thus, the results were skewed, but I won't know until tomorrow by what degree. 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
