Sam Clippinger schrieb:
In the keyword file, any entry that starts with a dot will only match
the end of the rDNS name. So .net will only match
1.2.3.4.example.net; it will never match 1.2.3.4.network.com. As a
matter of fact, the _only_ way to match the last two words of a domain
name is to start the entry with a dot and match the entire end of the
line. This is to prevent an entry like dynamic from matching
1.2.3.4.dynamic.com.
Further, any matched keyword must be surrounded by non-alphanumeric
characters (unless it starts with a dot). For example, the keyword
dialup would NOT be found in the following rDNS names:
1.2.3.4.notdialup.example.com
1.2.3.4.dialup3.example.com
1.2.3.4.dialupisslow.example.com
1.2.3.4.thisisadialupconnection.example.com
This means some potential matches slip through the filter, but making
the search more strict would generate too many false positives. My own
keyword list contains entries like dip and cm, which are very
effective with the current algorithm but would cause huge problems if
they could be matched anywhere.
Thanks for the insight, I was currently using entries in the form of:
.dynamic.
.ppp.
etc.
I had added in the dots to avoid matching partial strings as you noted
above.
-- Sam Clippinger
-- Felix
Felix Buenemann wrote:
Hello,
sorry for the late answer. [offtopic] I've been deploying my qmail-etrn
+ openvpn based on demand relaying solution all day, which allows for
direct mail transfer to any dialup client MTA behind a firewall and gets
rid of the need for POP connectors that hammer the mailserver with
logins. It works by hooking up the clients local MTA via an always-on
client-cert based openvpn connection to the qmail server, which assigns
a fixed IP to the client and directly deliver mail via qmail smtproutes.
Additionally ETRN can be used to trigger retry of mail in the queue
(caused by local MTA reboot, disconnect, whatever).
If someone is interested in a similar solution please mail me in
private, because it's really offtopic ... (unless Sam objects to
this)[/offtopic]
Sam Clippinger schrieb:
The full story: [...]
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.
Actually even foreign ISPs usually use the same english keywords like
pppoe, ppp, pppool, dynamic etc. The real problem however are ISPs which
don't include such a keyword at all, like h1-2-3-4.provider.ru.
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
How do you differentiate between domains and regular keywords?
Wouldn't .net also match .network-specialist.com or .com .company.org?
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
This makes sense, thanks.
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.
Agree, I was going to suggest the same.
-- Sam Clippinger
-- Felix
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
