[sniffer] Re: Bad Matrix errors
Yes, the errors have now stopped with the new update. The issue ran across all servers so I must have corrupted the last update at some point. Thanks for the speedy response! --Paul -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com]On Behalf Of Pete McNeil Sent: Monday, August 22, 2011 4:32 PM To: Message Sniffer Community Subject: [sniffer] Re: Bad Matrix errors On 8/22/2011 4:04 PM, Peer-to-Peer (Support) wrote: Hello SNF, I think something broke. I'm seeing a lot of Bad Matrix! warnings in my logs. Likely started about an hour ago. Running MDaemon mailserver. I note in your telemetry that you have a new rulebase since then. Have the errors stopped? _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 # 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] IPv6
Hi everyone, I've been thinking about the potential risk of IPv6 will have on filtering spam. I suspect RBL's (real time blacklists) may become obsolete once IPv6 arrives.?. From what I've learned, IPv6 has 340 undecillion (1 followed by 36 zeros) IP addresses. And devices can refresh every 24 hours. IPv4 only has 4.3 billion IP addresses. Pete: Grab a cup of coffee. The botNet's are coming... --Paul # 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] Volume spike Mon 9AM EST
Just checking to see if anyone else is seeing a massive spike in volume. Something started occurring around 9AM EST. Not yet sure what's happening. Wondering if this is global attack or simply local on our system? Anyone seeing unusual activity - high volume? --Paul R. # 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: Rulebase updates increased by 25%!!!
Thanks Pete, That would explain it. Maybe just my eyes playing tricks, but I swear my clock jumped ahead 1 hour as I was looking at the screen. Win2000 server. I re-installed some SNF files, using the current time-stamps. I'll report back if the issue persists. And/or at least we have something solid to work with if it continues. Thanks for your fast assistance. Regards, --Paul -Original Message- From: Message Sniffer Community [mailto:snif...@sortmonster.com]on Behalf Of Pete McNeil Sent: Monday, March 22, 2010 6:29 PM To: Message Sniffer Community Subject: [sniffer] Re: Rulebase updates increased by 25%!!! On 3/22/2010 4:59 PM, Peer-to-Peer (Support) wrote: Pete, We're only seeing an about 1 update every hour (or so) as well. I did some checking and sent you an email off list. It looks like the UTC clock on your server is about an hour in the future (compared to worldtimeserver.com) -- That's a guess, but based on the telemetry I see in your rulebase file timestamps it seems about right. If your update script isn't preserving the file timestamp from the delivery server and is pushing it into the future by an hour then your SNF node will not see the file on our server as newer until that hour has expired (at least). Two things... * The update script _should_ preserve the timestamp provided by the delivery server. * Even if that's not the case, if your UTC clock is correct then the timestamp of the new rulebase file would not be in the future. Please let us know the resolution on this. Please let us know if there is more we can do. Thanks! _M # 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] Updates down?
Our updates stopped around 4:45AM EST this morning (Sun 01-17-10) We see an error 'unable to connect' (using Curl). Continuing to investigate. Anyone else experiencing the same? --Paul # 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] Bad Matrix!
We saw the following error for about one hour this morning (6:30AM - 7:20AM EST). Assume it was a bad update, and once a new update arrived all corrected itself. Could this be a local issue, something that we may have been able to prevent, or something beyond our control. Sat 2009-07-18 07:10:19: SNF MessageScan: c:\mdaemon\queues\local\md50144568162.msg, Bad Matrix! Sat 2009-07-18 07:10:19: SNF Debug: EvaluationMatrix::OutOfRange Sat 2009-07-18 07:10:19: SNF MessageScan: c:\mdaemon\queues\local\md50144568163.msg, Bad Matrix! Sat 2009-07-18 07:10:19: SNF Debug: EvaluationMatrix::OutOfRange Sat 2009-07-18 07:10:19: SNF MessageScan: c:\mdaemon\queues\local\md50144568164.msg, Bad Matrix! Sat 2009-07-18 07:10:19: SNF Debug: EvaluationMatrix::OutOfRange Sat 2009-07-18 07:10:20: SNF MessageScan: c:\mdaemon\queues\local\md50144568165.msg, Bad Matrix! Sat 2009-07-18 07:10:20: SNF Debug: EvaluationMatrix::OutOfRange Sat 2009-07-18 07:10:20: SNF MessageScan: c:\mdaemon\queues\local\md50144568166.msg, Bad Matrix! Sat 2009-07-18 07:10:20: SNF Debug: EvaluationMatrix::OutOfRange Thanks! --PR # 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: Stampede - amazing!
Not the same as you're describing below, but I can confirm we were slammed with NDR's last night. Classic joe-job (i.e. millions of messages sent out to unknown users using your return address). --Paul -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Thursday, August 28, 2008 5:13 AM To: Message Sniffer Community Subject: [sniffer] Stampede - amazing! Hello Sniffer Folks, I had been wondering why the blackhats had been pushing so hard for new bots these last few weeks. Then the other day I saw something very strange in the SNF telemetry. A storm came in that seemed to stop all other traffic. For more than an hour I really thought something was broken -- but I wasn't sure I'd really seen it. Just a short time ago our SortMonster on duty (Mitchell Skull) called all-hands for a new spam storm. This was another of the new penis spams. We coded the rules quickly and as they went out I saw it again: T rates fell to zero on many systems and close to that on all of the others. This means that virtually all of the IPs were brand-new. At the same time traffic spiked on all systems and capture rates went off-scale high as the new rules tagged virtually every message. This is not an entirely new tactic by the blackhats-- I've talked about it before. It is essentially a high-amplitude burst - where a new campaign is pre-tested against all known filters and then launched on a large number of new bots that are unknown to IP reputation systems. What is new is the purity of these recent events. When we've seen them before they were mixed in with a lot of other traffic from other bot nets and even other campaigns from the same bot net. While there was still a trickle of this activity, the purity of this burst was astounding. This was a stampede where essentially all visible bots started running in a single new direction. T rates have recovered now by and large -- so the new bots are already largely recognized by GBUdb, but the wild swing in telemetry across the network was amazing to watch -- as is the new telemetry showing dramatically increased traffic and capture rates indicating a nearly pure stream of spam from this new herd. Theories, comments, and observations welcome. 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: FW: Memory Usage of MessageSniffer 3
Just following-up: We've been running the upper limit at 100mb for 3 weeks now and have not seen any further St9bad_alloc errors. At 150mb we were seeing the St9bad_alloc error daily. Regards, --Paul -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Friday, August 01, 2008 12:40 PM To: Message Sniffer Community Subject: [sniffer] Re: FW: Memory Usage of MessageSniffer 3 Hello Peer-to-Peer, Friday, August 1, 2008, 10:49:52 AM, you wrote: snip/ I also have a scheduled reboot every night since we did confirm w/ Arvel at MDaemon there is a memory leak in MDaemon.exe (if heavily utilizing their Gateway feature). Have yet to hear anything from AltN regarding a fix on the MDaemon.exe leak. In any case, do you think lowering the upper limit will help the St9bad_alloc error, or am I fishing in the wrong area. That will help your memory leak issue because it will leave more room for the leak to expand before causing allocation failures. You shouldn't see a significant drop-off in GBUdb performance after you reduce your upper RAM limit because your message rates are low enough that GBUdb should be able to function quite well with fewer entries-- Also there is a shared memory effect that emerges from the interaction of GBUdb nodes and the cloud... When records are condensed they are more likely to be bounced off the cloud and get new data so what you might loose in fewer records you will gain in more frequent reflections. 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: FW: Memory Usage of MessageSniffer 3
H sorry, just before posting my question last night I lowered the upper limit to 100MB which is why you're now seeing more normal numbers on your end. Six servers were at 150MB last night and today the numbers are 1/2 of the size. Here's an example from server#1 (LAST NIGHT) gbudb size bytes=159383552/ records count=781184/ utilization percent=97.3916/ /gbudb Here's an example from server#1 (TODAY) gbudb size bytes=75497472/ records count=300560/ utilization percent=91.2028/ /gbudb I lowered the upper limit because since installing 3.0, I'm now seeing a dramatic increase of the St9bad_alloc (out of memory error) on a daily basis again. As you know when that error occurs, all mail is allowed to pass none filtered, so my server reboots automatically when the St9bad_alloc error occurs. I also have a scheduled reboot every night since we did confirm w/ Arvel at MDaemon there is a memory leak in MDaemon.exe (if heavily utilizing their Gateway feature). Have yet to hear anything from AltN regarding a fix on the MDaemon.exe leak. In any case, do you think lowering the upper limit will help the St9bad_alloc error, or am I fishing in the wrong area. Thanks, --Paul -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Friday, August 01, 2008 10:04 AM To: Message Sniffer Community Subject: [sniffer] Re: FW: Memory Usage of MessageSniffer 3 Hello Peer-to-Peer, Thursday, July 31, 2008, 10:05:15 PM, you wrote: Would it be correct to say the higher we can increase the size-trigger 'megabytes' value, the better filtering results (accuracy) we will achieve? In other words, would it be beneficial for us to purchase more memory on our server (say an additional 2GB), then increase the 'megabytes' value to 400 or 800? Several of our servers are hitting the upper limit (159,383,552) 150 MB I don't think so. A quick look at your telemetry indicates that your systems are typically rebooted once per day. This is actually preempting your daily condensation. One result of this is that many of your GBUdb nodes only condense when they reach their size limit. From what I can see, when this happens a significant portion of your GBUdb data is dropped. For example, several of the systems I looked at have not condensed in months. Here is some data from one of them: timers run started=20080801081753 elapsed=19637/ sync latest=20080801134415 elapsed=55/ save latest=20080801131823 elapsed=1607/ condense latest=20080406160144 elapsed=10100606/ /timers gbudb size bytes=50331648/ records count=214313/ utilization percent=91.1357/ /gbudb This one has not condensed since 200804 most likely due to restarts that prevented the daily condensation timer from expiring. If this is the case with your other systems as well, it is likely that they are occasionally condensing when they reach their size threshold, but if they were allowed to condense daily they would never reach that limit. In that case, adding additional memory for GBUdb would probably not improve performance significantly. The default settings are conservative even for very large message loads. for example our spamtrap processing systems typically handle 3000-4000 msg/minute continuously and typically have timer GBUdb telemetry like this: timers run started=20080717205939 elapsed=1270156/ sync latest=20080801134844 elapsed=11/ save latest=20080801134721 elapsed=94/ condense latest=20080801132958 elapsed=1137/ /timers gbudb size bytes=117440512/ records count=568867/ utilization percent=99.6626/ /gbudb Note that this SNF node has not been restarted since 20080717 and that it's last condensation was in the early hours today-- most likely due to it's daily timer. Note also that it's GBUdb size is only 117 MBytes. It is unlikely that this system will reach 150Mbytes before the day is finished. Since most systems we see are handling traffic rates significantly smaller than 4.75M/day it is safe to assume that most systems would also be unlikely to reach their default GBUdb size limit during any single day... So, the default of 150 MBytes is likely more than sufficient for most production systems. --- All that said, if you want to intentionally run larger GBUdb data sets on your systems there is no harm in that. Your system will be more aware of habitual bot IPs etc at the expense of memory. Since all GBUdb nodes receive reflections on IP encounters within one minute, it is likely that the benefit would be the ability to reject the first message from a bad IP more frequently... Subsequent messages from bad IPs would likely be rejected by all GBUdb nodes based on reflected data. It is likely that increasing the amount of RAM you assign to your GBUdb nodes will have diminishing returns past the defaults currently set... but it might be fun to try it and see :-) --- If you are looking for better capture rates you may be able to achieve those more readily by adjusting your GBUdb envelopes.
[sniffer] Re: FW: Memory Usage of MessageSniffer 3
Would it be correct to say the higher we can increase the size-trigger 'megabytes' value, the better filtering results (accuracy) we will achieve? In other words, would it be beneficial for us to purchase more memory on our server (say an additional 2GB), then increase the 'megabytes' value to 400 or 800? Several of our servers are hitting the upper limit (159,383,552) 150 MB Thanks, --Paul -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Wednesday, July 30, 2008 8:23 AM To: Message Sniffer Community Subject: [sniffer] Re: FW: Memory Usage of MessageSniffer 3 Hello Ian, The new (V3) SNF does use more ram than the old SNF (V2). GBUdb adds records over time as it learns new IP data. The amount of RAM that will be used by GBUdb depends on how quickly it is learning new IPs and how frequently the database is condensed. You can set an upper limit on the size of GBUdb in the configuration file: condense minimum-seconds-between='600' time-trigger on-off='on' seconds='86400'/ posts-trigger on-off='off' posts='120'/ records-trigger on-off='off' records='60'/ size-trigger on-off='on' megabytes='150'/ /condense By default GBUdb will condense once per day or when it reaches 150 MBytes. Roughly twice as much RAM is needed for the condensing process since the GBUdb data must be copied to a new location. Condensing the GBUdb data is relatively expensive, so if sufficient RAM is not released by the first pass GBUdb will condense again every 10 minutes (600 seconds above) until GBUdb is below the size limit you have set. I recommend you determine how much ram you want to make available for SNF and then set your size-trigger/ to 40% of that size. This should leave room for GBUdb to condense and for the rest of SNF to fit inside your memory limit. You can monitor your GBUdb status in your status.minute or status.second reports. Here is some sample data from one of our spamtrap processors. It has been stable for months so this should be indicative of what you would see on a busy machine that's been up for a while: gbudb size bytes=142606336/ records count=650314/ utilization percent=95.8431/ /gbudb For information on reading your status reports: http://www.armresearch.com/support/articles/software/snfServer/logFiles/stat usLogs.jsp Hope this helps, _M Tuesday, July 29, 2008, 10:31:23 PM, you wrote: This is from one of our engineers. Anybody else had this sort of issue? Ian -Original Message- Does the new sniffer stuff have a higher memory requirement than the old? Sebastian pointed out to me today that a number of our gate servers were using a ton of swap space. Restarting snfctrl frees up a few hundred megs. Our newer gate servers (all with 2 or more GB of RAM) seem to be doing alright, but we have 16 gates at IAD with 1 GB of RAM that are being affected by this. It looks like the memory usage increases progressively over the course of a couple days, so I don't know if it's a memory leak or what. Is there anything we should do or add a snfctrl restart to our nightly cron jobs and just live with it for now? # 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] -- 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] MD - Headers in body
Hello, Is there any common cause for the SNF headers to appear in the body of an email? We're running MDaemon. We have a customer using a webform to receive their sales-orders via email. When the message arrives in the customers mailbox the SNF headers appear at the top of the message body, and the webform itself shows-up as webcode in the body. I assume it's the way the webform was created or being sent. Sorry I have limited details, but any suggestions? Thanks, --Paul # 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: Upgraded Rulebase Delivery System
All appears to be working correctly here :-) --PTP -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Saturday, July 12, 2008 4:34 AM To: Message Sniffer Community Subject: [sniffer] Upgraded Rulebase Delivery System Hello Sniffer Folks, Early this morning we completed significant upgrades to our rulebase delivery system yielding a 10 fold increase in available bandwidth and a 5 fold increase in delivery transaction rates. Please let us know if you observe any negative or positive effects. From observations and theory rulebases should be delivered more quickly and more frequently. I will continue to monitor the system closely for any aberrations. 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] Slow economy - More Spam
(theory): We're predicating an up-tick in spam over the coming months due to the (Global) economy which is dramatically slowing. Small businesses are feeling the pinch and business owners are beginning to panic (as you would naturally expect). So to make up for lost revenue they will advertise, heavily (just like chasing your money at the casino). An attractive way to advertise would be email (or so they think). Batten down the hatches. --PTP # 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: Source distribution corrected re: snf2check utility
Check to be certain your .snf rulebase is in the Mdaemon\SNF folder --PTP -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of David Pearson Sent: Thursday, April 24, 2008 2:47 PM To: Message Sniffer Community Subject: [sniffer] Re: Source distribution corrected re: snf2check utility Sorry - meant this version: SNFv2-9rc5.23.6 -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of David Pearson Sent: Thursday, April 24, 2008 2:43 PM To: Message Sniffer Community Subject: [sniffer] Re: Source distribution corrected re: snf2check utility Pete, I'm using Mdaemon and my plugin is messing up today. I went ahead and installed the new v2.9rc. I made sure to put my licenseid and auth number in the identity.xml file. Nothing changed because I did a copy and paste. Now when I start MDaemon I receive an error that says: Unable to authenticate rulebase Here's what the plug-ins section tells me: Thu 2008-04-24 14:35:24: Attempting to load 'SNF' plugin Thu 2008-04-24 14:35:24: * ConfigFunc: [EMAIL PROTECTED] (Ok, ready to use) Thu 2008-04-24 14:35:24: * StartupFunc: [EMAIL PROTECTED] (Ok, ready to use) Thu 2008-04-24 14:35:24: * ShutdownFunc: [EMAIL PROTECTED] (Ok, ready to use) Thu 2008-04-24 14:35:24: * PreMessageFunc: (NULL) Thu 2008-04-24 14:35:24: * PostMessageFunc: [EMAIL PROTECTED] (Ok, ready to use) Thu 2008-04-24 14:35:24: * SMTPMessageFunc: [EMAIL PROTECTED] (Ok, ready to use) Thu 2008-04-24 14:35:24: * SMTPMessageFunc2: (NULL) Thu 2008-04-24 14:35:24: * SMTPMessageFunc3: (NULL) Thu 2008-04-24 14:35:24: * DomainPOPMessageFunc: (NULL) Thu 2008-04-24 14:35:24: * MultiPOPMessageFunc: (NULL) Thu 2008-04-24 14:35:24: * Result: success (plugin DLL loaded in slot 0) Thu 2008-04-24 14:35:24: -- Thu 2008-04-24 14:35:24: SNF plugin is starting up Thu 2008-04-24 14:35:26: -- Thu 2008-04-24 14:35:44: SNF IPScan: c:\mdaemon\temp\md506.tmp, Engine Not Ready! Thu 2008-04-24 14:35:46: SNF MessageScan: c:\mdaemon\remoteq\md50001065387.msg, Engine Not Ready! Thu 2008-04-24 14:36:04: SNF IPScan: c:\mdaemon\temp\md508.tmp, Engine Not Ready! Thu 2008-04-24 14:36:05: SNF IPScan: c:\mdaemon\temp\md509.tmp, Engine Not Ready! Not sure what I'm doing wrong. Any ideas? Thanks, David -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, April 21, 2008 6:37 PM To: Message Sniffer Community Subject: [sniffer] Source distribution corrected re: snf2check utility Hello Sniffer Folks, The source distribution of the SNF2-9 beta/rc has been corrected. The previous build of the source distribution was missing a compile script. The new build -- just uploaded -- contains a compile script and some minor modifications to the source code so that it can be built in the SNF2Check directory. NO OTHER MODIFICATIONS WERE MADE ;-) 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] # 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] ORDB.org shutting down
ORDB.org announced today (12/18/06) they will be shutting down (12/31/06). The folks at AltN.com (MDaemon) sent out announcements to all their customers and would like to pass this along to anyone who checks that RBL. The site will disappear in 13 days. You can visit ordb.org for details. --Paul # 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] MDaemon 9.5 Gateways
MDaemon 9.5 hidden warning: If anyone is using the 'Gateway' features in MDaemon and plan to upgrade to 9.5, be aware you will now be required to purchase a user license equal to the number of Gateways. 9.5 no longer offers unlimited gateways :( --Paul R. # 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: Mdaemon plugin 'sleeping'
Hi Sven, My guess is that the plug-in is actually working but just not being logged when MD is minimized (or Windows logged-off). Check the MD Log Settings and enable Always log to screen. Setup|Logging|Options - Enable Always log to screen --Paul -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Sven De Troch Sent: Thursday, September 21, 2006 6:15 PM To: Message Sniffer Community Subject: [sniffer] Mdaemon plugin 'sleeping' Dear all, Configuration: mdaemon 9.0.6 / included spamassasin (from mdaemon) / mdaemon plug-in (latest version) Trial account. We configured the plugin (scanning of emails and add 5 extra score point to Mdaemon's Spam Assasin in case of spam) and it's working fine most of the time, but: The plugin is working fine when we are logged on on the server (Windows 2003 Server). But as soon as we logoff, the plugin stops working. Apparently the plugin falls into sleep (mdaemon plugin tab indicates no activity during these periods). When we (interactively via RDP) logon to the server again, the plugin starts working again (without intervention from us) ... And the 'mdaemon plugin' tabpage is showing activity again. FYI: The mailserver is receiving thousands of mail/hour, so it's sure that there was mail coming in at those moments. Any idea how to solve this problem? (I just changed the ACL's on the files to everyone/full access and will check if this changes anything) kind regards, Sven # 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]
Re: [sniffer]A design question - how many DNS based tests?
Hi _M, Do you mean like reverse PTR records, or HELO lookups, etc..? --Paul R. -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Tuesday, June 06, 2006 9:26 AM To: Message Sniffer Community Subject: [sniffer]A design question - how many DNS based tests? Hello Sniffer Folks, I have a design question for you... How many DNS based tests do you use in your filter system? How many of them really matter? 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]
RE: Re[2]: [sniffer] Last chance to renew at the old price!
You certainlycrossed a line of ethical integrity at the very least. Pete: If you don't already have a 'non-compete' agreement in your reseller agreement its time. I would never have believed someone would actually try to sell your reseller rates to your customer base. It's simply appalling. And should be grounds for termination. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of John T (Lists)Sent: Wednesday, December 28, 2005 8:46 PMTo: sniffer@SortMonster.comSubject: RE: Re[2]: [sniffer] Last chance to renew at the old price! Absolutely not. In fact, if you read my post after this, I am questioning whether or not it can be sold for a lower price. I am not here to undermine any one, as after all where do you think the license that I sell comes from? After all, we are all here to help one another. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peer-to-Peer (Support)Sent: Wednesday, December 28, 2005 5:41 PMTo: sniffer@SortMonster.comSubject: RE: Re[2]: [sniffer] Last chance to renew at the old price! John T:Did you just solicit the ENTIRE sniffer community with pricing that will undermine Pete? Never bit the hand that feeds you my friend. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of John T (Lists)Sent: Wednesday, December 28, 2005 8:17 PMTo: sniffer@SortMonster.comSubject: RE: Re[2]: [sniffer] Last chance to renew at the old price! Although I am a registered reseller, I normally only sell hardware and software to clients as part of my services. However, if any one is interested in a price, contact me off list. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KevinSent: Wednesday, December 28, 2005 5:00 PMTo: sniffer@SortMonster.comSubject: Re: Re[2]: [sniffer] Last chance to renew at the old price! After posting this, another reseller pm me their renewal rate of $269. I didn't know Sniffer had another reseller besides Declude.Anyways, for those who are interested and want to save money, it's https://www.computerhouse.com/ccsecure.html At 01:21 PM 12/28/2005, you wrote: Can we renew at declude.com since their pricing is $292.50? I assume their prices will increase on Jan 1, 2006 too.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] About Resellers, and the best laid plans of mice men...
Sorry papa _M Sorry John T Just want to see sniffer around in the future and got a little excited. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Wednesday, December 28, 2005 9:51 PM To: sniffer@sortmonster.com Subject: [sniffer] About Resellers, and the best laid plans of mice men... Hello Sniffer Folks, Before things get too out of hand I thought I'd post a few remarks just to make sure there are no misunderstandings. First of all, the price on the ComputerHouse site was an error and it has already been corrected. (That's the mice and men part... a simple mistake, now all taken care of.) Next, while it would bad form for one of our resellers to advertise directly on our list, THAT DID NOT HAPPEN here. Someone else pointed out the discount, and that's ok. Regarding our reseller programs in general and where we stand on this. As Mike is fond of saying, We like customers All customers :-) It's perfectly ok to us for you to buy from one of our resellers or from us directly. Pick the relationship that fits you best. -- Technically, our resellers are really considered VARs, and they all have special things to offer that you may need. Purchasing from us directly also has some benefits (the additional funds help speed up RD), but ultimately, if you use and support SNF, through us or through one of our partners, you are still supporting SNF and that's a good thing! :-) Our goal is to foster a broad, vibrant community of consultants, end users, VARs, OEMs, service providers, and even plain old interested parties that use and support SNF. After all, email security is a big concern for everyone and the best thing we can do is work together. 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
RE: Re[2]: [sniffer]
_M, _M said will create a default installation that emits headers and puts a .cf file in place for SA to interpret them. Not sure if this is relevant to your thought process, but we feel that SA (SpamAssassin) does more harm than good. Under moderate loads it bogs-down MDaemon so we always have SA disabled. Sniffer is by far superior in every category, (accuracy, speed, dependability etc...) so there's no need to use SpamAssassin. My point: Keep in mind that some of us use sniffer independently (not tied to SA). We're using sniffers .cfg plug-in for MD ver 8. I assume you will, and I probably misunderstood your post, but just wanted to mention this out-loud. Thanks, Paul R -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Thursday, November 10, 2005 10:43 AM To: Daniel Bayerdorffer Subject: Re[2]: [sniffer] On Thursday, November 10, 2005, 9:40:42 AM, Daniel wrote: DB Hi Pete, DB Thanks for the info. I actually already have the current version running. DB I'm very happy with it's performance. I just did not have a clear DB understanding on those issues. DB On another note, when you have the new version install, will it overwrite my DB current settings? And will it also install scripts for updating the rule DB base, and sending logs? Because I already have that setup now. In theory the installer will know if there is a previous version and will not adjust any of the config data. It's a bit of a complicated problem because there are so many way to configure the software.. so the installation process can be complex. I'd like to know how you have your updates set up - perhaps I can use that as a model for the installer. The basic idea is that the installer will create a default installation that emits headers and puts a .cf file in place for SA to interpret them. After that, the technically minded can manually adjust the installation. If the installer finds an installation in place then it will likely update the .DLL and leave everything else alone. Comments about these concepts are welcome, of course. The goal is to make a plug-and-play installation possible while leaving the more sophisticated options open to the technically minded. 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: Re[4]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Tip for MDaemon plug-in users. Sniffers .cfg file has an option 'not' to scan files larger than 'X'. If this option is set than no sniffer headers will be placed into the message (if the message is larger than 'X'). Beware, if you use MD's Content Filter to instruct where to send messages based on sniffer's 'results' as there will be no results if the file is never scanned ;) Paul R -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Wednesday, April 20, 2005 3:30 PM To: Jim Matuska Subject: Re[4]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo On Wednesday, April 20, 2005, 2:30:25 PM, Jim wrote: JM Pete, JM Is there a difference between the normal .snf files I have been downloading JM and the one for the plugin? I have setup my script to download the .snf JM file and noticed it is a couple mb's smaller than the included demo .snf JM file. There is no significant difference. The mdaemon1 file contains some extra rules, but these are not normally needed in production. During the test we wanted to make sure we used the largest valid rulebase file we generate. After the test it will be best to use normal rulebase files. _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: Re[4]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
_M i'll try this one, Jim, you will keep all of your Content Filter rules the same 'except' you will disable (or delete) the two Sniffer entries 'Run Message Sniffer' Add Headers'. Those two functions will be generated from the plug-in. Also, if you are using the results codes (in the Content Filter) you will need to change any instance of X-SPAM-Msg-Sniffer-Result TO X-SortMonster-MessageSniffer-Result as indicated in the readme.txt file. Paul R -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Matuska Sent: Wednesday, April 20, 2005 5:01 PM To: sniffer@SortMonster.com Subject: (DUMP)Re: Re[4]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo I meant do I configure actions based on the headers that sniffer returns like in the non plug in version, or does the plugin do this automatically, the documentation for the plug in is kind of vague in comparison to the older version. 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: Wednesday, April 20, 2005 1:51 PM Subject: Re[4]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo On Wednesday, April 20, 2005, 4:19:48 PM, Jim wrote: JM Do you configure rules similar to in the previous versions, or by using this JM as a plug in is there a GUI for configuration. We configure the rulebase the same way we have in the past. Using the plugin is not different from using the command line utility except that the performance is better (faster) and the installation and operation is simpler. The service/subscription part of Message Sniffer has not changed. --- We have a GUI web app for the rulebase (we use it every day), however we have discovered through trial and error that a lot of specialized training is required to keep the rulebase working correctly and that one GUI does not suit many users... each group seems to need their own! We are working on plans for some simpler web apps in the future to handle specialized tasks, however that too seems best handled in other ways for the time being. For example, every system that provides automation to their users for false positive handling and custom black-rules seems to do it in their own special way --- so rather than build a web app that doesn't really suit anyone we have adopted the strategy of providing automation tools (such as our XML based REmost SCripted Updater [RESCU] utility) and consulting to integrate each customer's existing or planned automation efforts with their back-end rulebase configuration. These efforts are usually reserved for larger systems such as small ISPs and filtering service providers. As always we want to support any third party efforts to provide automation tools also. So far we haven't seen much in the way of GUI automation, probably for the same reasons we haven't tackled it yet. I think I may have answered more than the base question here - but I'm hoping I've addressed some of the underlying questions. _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
