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 <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 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 <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>
 

Reply via email to