[sniffer] Re: Short Match FPs.
Thank you Pete for your dedication !! -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, December 01, 2015 10:22 PM To: Message Sniffer Community Subject: [sniffer] Re: Short Match FPs. Hi folks, Good News! After much research and experimentation we have determined that some time on Nov 28 a corrupted rule entered the rulebase and caused the intermittend short-match problem. We have removed a group of rules surrounding that timeframe and have observed a 3 sigma drop in the rate of short-match events. This indicates that the problem is solved and not likely to return. Now that we know this kind of event is possible (it's not supposed to be mathematically) we will be building a detection and mitigation strategy into the engine... just in case it does happen again. Once in two decades makes that seem unlikely. We will also be continuing our research on the sequestered rules to identify the one(s) that caused the problem and identify a way to prevent that recurring. In the mean time the detection mechanisms we used to monitor our experiments will remain in place so that if we do see any future events we will be able to identify them much more quickly. Sorry for the trouble, Thanks for your patience and continued support! _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: What is your oldest production CPU?
Intel Xeon dual core -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Friday, December 27, 2013 9:44 AM To: Message Sniffer Community Subject: [sniffer] What is your oldest production CPU? Hello Sniffer Folks, We would like to know what your oldest production CPU is. When building new binaries of SNF or it's utilities we would like to select the newest CPU we can without leaving anybody behind. We're also evaluating whether we should split binaries into a "compatible" version base on Intel i686 (or equivalent AMD), and a "current" version based on Intel Core2 (or equivalent AMD). Please respond here. Thanks for your time!! _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Checking in - Uptick
Anyone else seeing a dramatic uptick in spam passing thru the filters this week? We're getting pummeled. Seems to have started Monday, but getting better. Happy Spam-0-ween! --Paul
[sniffer] Re: snf plugin question
Way cool. So just to be sure I've got this right, if I wanted to experiment with getting more aggressive, I could try the following: DEFAULT: NEW CHANGES: Is that the right direction? --Paul From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, September 10, 2013 11:32 AM To: Message Sniffer Community Subject: [sniffer] Re: snf plugin question On 2013-09-10 11:15, Peer-to-Peer (Spam-Filter.com) wrote: Regarding the section in the SNF Plugin, we're currently using the defaults (see below). Could you give us a refresher: Why are there 2 entry's for each (white / caution / black)? For example: They define corner points on a parallelogram that maps the region in the x,y space: http://www.armresearch.com/support/articles/software/snfServer/config/node/g budb/regions/ The points you listed above define the white region with two points. These points essentially define a line in the graph. Everything to the left of that line (in the white region) is considered to be "inside" the region. Please let us know if there is more we can do. Best, _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] snf plugin question
Hey Pete, Regarding the section in the SNF Plugin, we're currently using the defaults (see below). Could you give us a refresher: Why are there 2 entry's for each (white / caution / black)? For example: __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ Thanks, --Paul
[sniffer] Re: 2nd level IP scanning
It good to reiterate features so your time wasn't wasted there, however, there is some mis-commnucation. I'm seeing one spammer who's IP address is (x.x.x.x). Or at least that's the originating IP in the headers. I'm seeing thousands of messages originating from this IP, however they are passing thru hundreds of different Verizon and Comcast servers. Literally. I can't block (or I don't want to block) the Verizon or Comcast IP's, but I need to block the originating IP (x.x.x.x). This guys is a sitting duck, but oddly I'm discovering that I can't stop him with my conventional tools. One thought: MDaemon's RBL portal can be configured to drill down into the headers. So if I setup GBUdb 'Truncate', then all I would need to do is convince you to add this IP to truncate J. (Yes, not a great solution since it's too manual, and at the moment it's not warranted to go down that road). Anyways, thanks for your help if you can offer any suggestions. --Paul From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Friday, June 07, 2013 6:56 PM To: Message Sniffer Community Subject: [sniffer] Re: 2nd level IP scanning GBUdbIgnoreList.txt file On 2013-06-07 18:36, Peer-to-Peer (Spam-Filter.com) wrote: Pete: I'm not sure that GBUdbIgnoreList.txt file would work for my situation as it seems I would need to trust all IP's from Comcast and Verizon to catch this one IP below- Correct? Or am I misunderstanding. Perhaps I misunderstand -- but: * I didn't intend to recommend GBUdbIgnoreList. * I DID intend to recommend using drillown directives. * I interpreted your message to indicate there are intermediate Verizon and Comcast servers you want to ignore when looking for the source IP. If I'm right about the intermediate servers then I presume they would always be intermediate. So, what we want to do is tell GBUdb to recognize those servers and ignore them. Then it will find the next received header behind those and treat it like the source. The process is loosely described here (copied from the page I recommended): Suppose some large ISP uses the domain mixed-source.net, then you might see received headers similar to: Received: from out56.mixed-source.net [12.34.56.78] by my0wn1.bestfilterever.net (1.2.3.4 / 5.6.7.8) so forth and so on; Received: from inside34.mixed-source.net [210.1.2.34] by outside56.mixed-source.net (and so forth) and so on; Received: from border124.mixed-source.net [210.1.2.124] by inside34.mixed-source.net (and so forth) and so on; Received: from ugly-spambot-customer.dyn-dsl123.eviltown.cpe9.example.com [99.88.77.66] by border124.mixed-source.net (and so forth) and so on; Then your section might look like this: The top received header (ordinal 0) created by your system would match the first drilldown header directive and so 12.34.57.78 would be added to GBUdb with the Ignore flag set. SNF would keep looking. The next received header (ordinal 1) created by mixed-source would match the second drilldown header directive and so 210.1.2.34 would be added to GBUdb with the Ignore flag set. SNF would keep looking. The next received header (ordinal 2) created by mixed-source would match the third drilldown header directive and so 210.1.2.124 would be added to GBUdb with the Ignore flag set. SNF would keep looking. Finally, the next received header would not match any header directives. The previous received headers have all been made ineligible as message sources. As a result the IP 99.88.77.66 will be treated as the source IP for this message. Ultimately that results in intermediate servers being ignored always and specifically (by IP) presuming that the actual source of the message will always be something behind them. This doesn't trust whitelist those servers -- it simply says we can't treat them as the message source. Let me know if I missed something. _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: 2nd level IP scanning GBUdbIgnoreList.txt file
Pete: I'm not sure that GBUdbIgnoreList.txt file would work for my situation as it seems I would need to trust all IP's from Comcast and Verizon to catch this one IP below- Correct? Or am I misunderstanding. Thanks, --Paul From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Friday, June 07, 2013 6:24 PM To: Message Sniffer Community Subject: [sniffer] Re: 2nd level IP scanning On 2013-06-07 18:16, Peer-to-Peer (Spam-Filter.com) wrote: Hey Pete and all, Is there an option to have SNF scan second or third deep header IP's? I'm trying to block an originating IP (66.83.88.42), however they are hopping thru Comcast and Verizon. Yes! You can use drilldown directives to teach SNF to "trust" intermediate servers and find the originator: http://www.armresearch.com/support/articles/software/snfServer/config/node/g budb/training/drilldown.jsp _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] 2nd level IP scanning
Hey Pete and all, Is there an option to have SNF scan second or third deep header IP's? I'm trying to block an originating IP (66.83.88.42), however they are hopping thru Comcast and Verizon. Thanks, --Paul
[sniffer] Volume
Just touching base with the list here. We're seeing a significant spike in traffic which started a few days ago. Today's volume is double / triple the norm. Anyone else seeing the same? --Paul
[sniffer] Re: IPScan results
Thanks Pete - it's working now! Turns out that MDaemon Security Plus license expired on those 2 machines. Apparently if the Outbreak Protection engine is not started, then SNF IPScan is affected. For confirmation, I removed references to Outbreak Protection in the plugins.dat file, but SNF IPScan still did not work. Once I installed a new Security Plus license, Outbreak Protection engine started and so did SNF IPScan. Regards, --Paul -Original Message- From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Tuesday, April 16, 2013 5:28 PM To: Message Sniffer Community Subject: [sniffer] Re: IPScan results On 2013-04-16 17:02, Peer-to-Peer (Spam-Filter.com) wrote: > Hey all, I noticed a couple of my MDaemon mailservers are not > performing the "SNF IPScan". Check that your MDaemon versions are the same -- some versions implement the plugin API differently. Then make sure that your Plugins.Dat file configures the SNF plugin correctly. If you've got one server working correctly and other's not, then that gives you a good way to compare. Hope this helps, _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: MDaemon AV 4.1.5 / SNF plugins Update Warning
After a second look, I was not 100% accurate on that statement ("This only occurred on servers where I used SNF_CS_Installer") One server, where I used the SNF_Installer, did not fail. SNF Code stayed in place after the AV Update. Pete: I'll send you my plugin.dat file(s) offline momentarily. There are some clues which may help. Regards, --Paul From: Message Sniffer Community [mailto:sniffer@sortmonster.com] On Behalf Of Pete McNeil Sent: Wednesday, December 05, 2012 9:18 AM To: Message Sniffer Community Subject: [sniffer] Re: MDaemon AV 4.1.5 / SNF plugins Update Warning On 2012-12-05 08:35, Peer-to-Peer (Spam-Filter.com) wrote: One thing to note: This only occurred on servers where I used SNF_CS_Installer when originally setting up SNF. The Servers where I manually added SNF were not affected. That seems very weird -- how would it know the difference? Any ideas? _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . 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: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] MDaemon AV 4.1.5 / SNF plugins Update Warning
Hey everyone, Just want to share an issue I discovered when upgrading MDaemon AntiVirus (Security Plus), from Ver 4.1.3 TO 4.1.5 On several of our servers, the Security Plus update overwrote our MDaemon 'plugins.dat' file and deleted the SNF code. The MD plugins.dat file is located in MDaemon\App folder. One thing to note: This only occurred on servers where I used SNF_CS_Installer when originally setting up SNF. The Servers where I manually added SNF were not affected. If anyone using MDaemon is not aware of the MD Emergency AV update see this link. Mail will stop flowing today (12/05/12). http://www.altn.com/Support/SecurityUpdate/SecurityPlus-Security-Update/ --Paul