[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] 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/gbudb/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] Re: 2nd level IP scanning
This might also be effective where the spammer hits the high MX entry acting as a gateway. MxGuard could be configured to use the GBUDB I think and to look up to 5 levels deep. Sent using SmarterSync Over-The-Air sync for iPad, iPhone, BlackBerry and other SmartPhones. May use speech to text. If something seems odd please don't hesitate to ask for clarification. E.&O.E. On 2013-06-07, at 3:17 PM, "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. > > > Thanks, > > --Paul
[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] 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
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
On 2013-06-07 19:18, Peer-to-Peer (Spam-Filter.com) wrote: 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). I think you have misunderstood what drilldown does. If you teach drilldown to recognize the versizon and comcast servers then it will learn to ignore them and pinpoint this specific IP. It will also learn to find any other IPs that are doing the same kind of thing. _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