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:firstname.lastname@example.org] 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 [22.214.171.124] by my0wn1.bestfilterever.net (126.96.36.199 / 188.8.131.52) so forth and so on; Received: from inside34.mixed-source.net [184.108.40.206] by outside56.mixed-source.net (and so forth) and so on; Received: from border124.mixed-source.net [220.127.116.11] by inside34.mixed-source.net (and so forth) and so on; Received: from ugly-spambot-customer.dyn-dsl123.eviltown.cpe9.example.com [18.104.22.168] by border124.mixed-source.net (and so forth) and so on; Then your <drilldown> section might look like this: <drilldown> <received ordinal='0' find='.mixed-source.net [' /> <received ordinal='1' find='.mixed-source.net [210.' /> <received ordinal='2' find='.mixed-source.net [210.' /> </drilldown> The top received header (ordinal 0) created by your system would match the first drilldown header directive and so 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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 <email@example.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>