Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
The full story: I first created (what is now called) the "ip-in-rdns-keyword-blacklist-file" filter because I wanted to block connections from virus-infected Windows machines on home broadband connections. I wrote the code to search for the IP address and a list of keywords like "dynamic" or "dhcp" or "dialup". I didn't want to block _all_ connections based on _only_ finding their IP address because many legitimate businesses host their own mail servers and have generic rDNS names that contain their IP addresses. However, blocking based on IP address and keyword didn't work for foreign language rDNS names, because I can't possibly list every keyword in every language on the planet. Because I don't often receive email from people outside the United States, I decided that filtering based on IP address and two-character TLD would be acceptable. I created the "reject-ip-in-cc-rdns" filter for this purpose. This decision worked for me based on my own email patterns and those of my users. It obviously doesn't work for everyone, especially on mail servers outside the U.S. To accommodate this, I expanded the "ip-in-rdns-keyword-blacklist-file" filter to accept domain names instead of just keywords. If you really want to block connections from ".net" or ".com" simply because the rDNS name contains the IP address, you can list those domains in your keyword file like this: .net .com You can use the same technique to selectively simulate the "reject-ip-in-cc-rdns" filter for only a few two-character TLDs. To block all connections from ".us" or ".uk" that contain an IP address while allowing connections from ".de" or ".pl" that contain an IP address, add these entries to your keyword file: .us .uk To answer your second question about the order the filters are run, they are already coded to run in order from least-expensive to most-expensive. rDNS filters run before file-based filters, which run before DNS-based filters. The order of execution is not configurable and I don't intend to change that fact (it would be a monumental task, not to mention very difficult to configure). The current order is documented here: http://www.spamdyke.org/documentation/FAQ.html#FEATURE1 Lastly, because this discussion is about current features, could we move it to the spamdyke-users mailing list? The spamdyke-dev list is really for discussions of beta versions of spamdyke. -- Sam Clippinger Felix Bünemann wrote: > Am 20.09.2008 um 02:23 schrieb Felix Bünemann: > > >> OK, what doesn't make sense to me is as to why to differentiate >> between .com/.net etc. and .de/.uk? If a dialup host sends spam it >> shouldn't matter if his RDNS is .com or .de ... >> I think most spam should be blocked by simple rules without requiering >> RBL lookups and the latency required to do so. >> > > Which leads me to the conclusion, that it should be possible to define > the order in that the different filters are executed. > > Can you specify what's the current order of filter execution? > > -- Felix > ___ > spamdyke-dev mailing list > spamdyke-dev@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-dev > ___ spamdyke-dev mailing list spamdyke-dev@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
Am 20.09.2008 um 02:23 schrieb Felix Bünemann: > OK, what doesn't make sense to me is as to why to differentiate > between .com/.net etc. and .de/.uk? If a dialup host sends spam it > shouldn't matter if his RDNS is .com or .de ... > I think most spam should be blocked by simple rules without requiering > RBL lookups and the latency required to do so. Which leads me to the conclusion, that it should be possible to define the order in that the different filters are executed. Can you specify what's the current order of filter execution? -- Felix ___ spamdyke-dev mailing list spamdyke-dev@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
OK, what doesn't make sense to me is as to why to differentiate
between .com/.net etc. and .de/.uk? If a dialup host sends spam it
shouldn't matter if his RDNS is .com or .de ...
I think most spam should be blocked by simple rules without requiering
RBL lookups and the latency required to do so.
Some stats show me, that while most spam from country TLDs is blocked
by the IP_IN_CC_DNS rule, most com/net/org spam gets blocked by RBL or
custom RDNS rules:
348007 DENIED_IP_IN_CC_RDNS
-- Top 5 TLD --
53.17% ru
10.08% tr
6.61% br
2.59% il
2.42% de
168360 DENIED_RBL_MATCH
-- by RBL --
77.60% zen.spamhaus.org
14.08% ix.dnsbl.manitu.net
8.32% bl.spamcop.net
-- Top 5 TLD --
42.11% net
21.07% ru
13.99% com
5.04% pl
2.60% de
7008DENIED_IP_IN_RDNS
-- Top 5 TLD --
60.57% net
38.53% com
0.86% org
0.03% arpa
0.01% edu
4833DENIED_BLACKLIST_NAME
-- Top 5 TLD --
100.00% net
-- Felix
Am 19.09.2008 um 17:36 schrieb Sam Clippinger:
> No, the "reject-ip-in-cc-rdns" filter won't stop these names because
> they end in ".net", which is a three-character TLD. If they ended
> in a
> two-character TLD like ".us", it would work.
>
> -- Sam Clippinger
>
> Felix Bünemann wrote:
>> Hello Sam,
>>
>> I assumed this should be blocked by the IP_IN_CC_RDNS rule, but
>> apparently it isn't.
>>
>> -- Felix
>>
>> Am 19.09.2008 um 00:47 schrieb Sam Clippinger:
>>
>>
>>> That rDNS name should be blocked, assuming that your keyword file
>>> contains at least one of the following entries:
>>> dip
>>> .t-dialin.net
>>> .dip.t-dialin.net
>>>
>>> -- Sam Clippinger
>>>
>>> Felix Bünemann wrote:
>>>
I just took a look at the code and found a segment which should
already take care of this:
/*
* This block looks for the IP address as a sequence of hex
bytes.
* For example, if the IP is 85.135.72.234, this block looks for
* 5080d7e3.
*/
if (!return_value)
{
tmp_strlen = snprintf(tmp_ip, MAX_IP, "%.2x%.2x%.2x%.2x",
ip_ints[0], ip_ints[1], ip_ints[2], ip_ints[3]);
SPAMDYKE_LOG_EXCESSIVE(current_settings,
LOG_DEBUGX_IP_IN_RDNS,
tmp_strlen, tmp_ip, strlen_target_name, target_name);
if (strstr(target_name, tmp_ip) != NULL)
return_value = 1;
}
}
So I wonder why the host listed below was matched by
FILTER_BLACKLIST_NAME. I was under the impression that
FILTER_IP_IN_CC_RDNS has a higher precedence than the blacklist
file,
but I might be misatken.
Please shed some light on this Sam.
-- Felix
Am 19.09.2008 um 00:16 schrieb Felix Bünemann:
> Hello,
>
> I noticed that spamdyke 4.0.4 is not blocking dialup hosts which
> use
> hex-encoded ip-adress in their RDNS.
>
> T-Online, the biggeste German internet provider uses this scheme:
>
> 87.150.36.222 rdns: p579624de.dip.t-dialin.net
>
> 87=0x57 150=0x96 36=0x24 222=0xDE
>
> Should be pretty easy to add support for this.
>
> -- Felix Buenemann
>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>
>
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>> ___
>>> spamdyke-dev mailing list
>>> spamdyke-dev@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>>
>>
>> ___
>> spamdyke-dev mailing list
>> spamdyke-dev@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
No, the "reject-ip-in-cc-rdns" filter won't stop these names because
they end in ".net", which is a three-character TLD. If they ended in a
two-character TLD like ".us", it would work.
-- Sam Clippinger
Felix Bünemann wrote:
> Hello Sam,
>
> I assumed this should be blocked by the IP_IN_CC_RDNS rule, but
> apparently it isn't.
>
> -- Felix
>
> Am 19.09.2008 um 00:47 schrieb Sam Clippinger:
>
>
>> That rDNS name should be blocked, assuming that your keyword file
>> contains at least one of the following entries:
>>dip
>>.t-dialin.net
>>.dip.t-dialin.net
>>
>> -- Sam Clippinger
>>
>> Felix Bünemann wrote:
>>
>>> I just took a look at the code and found a segment which should
>>> already take care of this:
>>>
>>> /*
>>> * This block looks for the IP address as a sequence of hex
>>> bytes.
>>> * For example, if the IP is 85.135.72.234, this block looks for
>>> * 5080d7e3.
>>> */
>>> if (!return_value)
>>> {
>>> tmp_strlen = snprintf(tmp_ip, MAX_IP, "%.2x%.2x%.2x%.2x",
>>> ip_ints[0], ip_ints[1], ip_ints[2], ip_ints[3]);
>>>
>>> SPAMDYKE_LOG_EXCESSIVE(current_settings, LOG_DEBUGX_IP_IN_RDNS,
>>> tmp_strlen, tmp_ip, strlen_target_name, target_name);
>>> if (strstr(target_name, tmp_ip) != NULL)
>>> return_value = 1;
>>> }
>>> }
>>>
>>>
>>> So I wonder why the host listed below was matched by
>>> FILTER_BLACKLIST_NAME. I was under the impression that
>>> FILTER_IP_IN_CC_RDNS has a higher precedence than the blacklist file,
>>> but I might be misatken.
>>>
>>> Please shed some light on this Sam.
>>>
>>> -- Felix
>>>
>>> Am 19.09.2008 um 00:16 schrieb Felix Bünemann:
>>>
>>>
>>>
Hello,
I noticed that spamdyke 4.0.4 is not blocking dialup hosts which use
hex-encoded ip-adress in their RDNS.
T-Online, the biggeste German internet provider uses this scheme:
87.150.36.222 rdns: p579624de.dip.t-dialin.net
87=0x57 150=0x96 36=0x24 222=0xDE
Should be pretty easy to add support for this.
-- Felix Buenemann
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>> ___
>>> spamdyke-dev mailing list
>>> spamdyke-dev@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>>
>>>
>> ___
>> spamdyke-dev mailing list
>> spamdyke-dev@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>
>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
Hello Sam,
I assumed this should be blocked by the IP_IN_CC_RDNS rule, but
apparently it isn't.
-- Felix
Am 19.09.2008 um 00:47 schrieb Sam Clippinger:
> That rDNS name should be blocked, assuming that your keyword file
> contains at least one of the following entries:
>dip
>.t-dialin.net
>.dip.t-dialin.net
>
> -- Sam Clippinger
>
> Felix Bünemann wrote:
>> I just took a look at the code and found a segment which should
>> already take care of this:
>>
>> /*
>> * This block looks for the IP address as a sequence of hex
>> bytes.
>> * For example, if the IP is 85.135.72.234, this block looks for
>> * 5080d7e3.
>> */
>> if (!return_value)
>> {
>> tmp_strlen = snprintf(tmp_ip, MAX_IP, "%.2x%.2x%.2x%.2x",
>> ip_ints[0], ip_ints[1], ip_ints[2], ip_ints[3]);
>>
>> SPAMDYKE_LOG_EXCESSIVE(current_settings, LOG_DEBUGX_IP_IN_RDNS,
>> tmp_strlen, tmp_ip, strlen_target_name, target_name);
>> if (strstr(target_name, tmp_ip) != NULL)
>> return_value = 1;
>> }
>> }
>>
>>
>> So I wonder why the host listed below was matched by
>> FILTER_BLACKLIST_NAME. I was under the impression that
>> FILTER_IP_IN_CC_RDNS has a higher precedence than the blacklist file,
>> but I might be misatken.
>>
>> Please shed some light on this Sam.
>>
>> -- Felix
>>
>> Am 19.09.2008 um 00:16 schrieb Felix Bünemann:
>>
>>
>>> Hello,
>>>
>>> I noticed that spamdyke 4.0.4 is not blocking dialup hosts which use
>>> hex-encoded ip-adress in their RDNS.
>>>
>>> T-Online, the biggeste German internet provider uses this scheme:
>>>
>>> 87.150.36.222 rdns: p579624de.dip.t-dialin.net
>>>
>>> 87=0x57 150=0x96 36=0x24 222=0xDE
>>>
>>> Should be pretty easy to add support for this.
>>>
>>> -- Felix Buenemann
>>>
>>> ___
>>> spamdyke-dev mailing list
>>> spamdyke-dev@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>>
>>
>> ___
>> spamdyke-dev mailing list
>> spamdyke-dev@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
That rDNS name should be blocked, assuming that your keyword file
contains at least one of the following entries:
dip
.t-dialin.net
.dip.t-dialin.net
-- Sam Clippinger
Felix Bünemann wrote:
> I just took a look at the code and found a segment which should
> already take care of this:
>
> /*
> * This block looks for the IP address as a sequence of hex bytes.
> * For example, if the IP is 85.135.72.234, this block looks for
> * 5080d7e3.
> */
> if (!return_value)
>{
>tmp_strlen = snprintf(tmp_ip, MAX_IP, "%.2x%.2x%.2x%.2x",
> ip_ints[0], ip_ints[1], ip_ints[2], ip_ints[3]);
>
>SPAMDYKE_LOG_EXCESSIVE(current_settings, LOG_DEBUGX_IP_IN_RDNS,
> tmp_strlen, tmp_ip, strlen_target_name, target_name);
>if (strstr(target_name, tmp_ip) != NULL)
> return_value = 1;
>}
> }
>
>
> So I wonder why the host listed below was matched by
> FILTER_BLACKLIST_NAME. I was under the impression that
> FILTER_IP_IN_CC_RDNS has a higher precedence than the blacklist file,
> but I might be misatken.
>
> Please shed some light on this Sam.
>
> -- Felix
>
> Am 19.09.2008 um 00:16 schrieb Felix Bünemann:
>
>
>> Hello,
>>
>> I noticed that spamdyke 4.0.4 is not blocking dialup hosts which use
>> hex-encoded ip-adress in their RDNS.
>>
>> T-Online, the biggeste German internet provider uses this scheme:
>>
>> 87.150.36.222 rdns: p579624de.dip.t-dialin.net
>>
>> 87=0x57 150=0x96 36=0x24 222=0xDE
>>
>> Should be pretty easy to add support for this.
>>
>> -- Felix Buenemann
>>
>> ___
>> spamdyke-dev mailing list
>> spamdyke-dev@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>>
>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
>
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
Re: [spamdyke-dev] Additional IP_IN_CC_RDNS scheme
I just took a look at the code and found a segment which should
already take care of this:
/*
* This block looks for the IP address as a sequence of hex bytes.
* For example, if the IP is 85.135.72.234, this block looks for
* 5080d7e3.
*/
if (!return_value)
{
tmp_strlen = snprintf(tmp_ip, MAX_IP, "%.2x%.2x%.2x%.2x",
ip_ints[0], ip_ints[1], ip_ints[2], ip_ints[3]);
SPAMDYKE_LOG_EXCESSIVE(current_settings, LOG_DEBUGX_IP_IN_RDNS,
tmp_strlen, tmp_ip, strlen_target_name, target_name);
if (strstr(target_name, tmp_ip) != NULL)
return_value = 1;
}
}
So I wonder why the host listed below was matched by
FILTER_BLACKLIST_NAME. I was under the impression that
FILTER_IP_IN_CC_RDNS has a higher precedence than the blacklist file,
but I might be misatken.
Please shed some light on this Sam.
-- Felix
Am 19.09.2008 um 00:16 schrieb Felix Bünemann:
> Hello,
>
> I noticed that spamdyke 4.0.4 is not blocking dialup hosts which use
> hex-encoded ip-adress in their RDNS.
>
> T-Online, the biggeste German internet provider uses this scheme:
>
> 87.150.36.222 rdns: p579624de.dip.t-dialin.net
>
> 87=0x57 150=0x96 36=0x24 222=0xDE
>
> Should be pretty easy to add support for this.
>
> -- Felix Buenemann
>
> ___
> spamdyke-dev mailing list
> spamdyke-dev@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
___
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
