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 to define >>>> the order in that the different filters are executed. >>>> >>>> Can you specify what's the current order of filter execution? >>>> >>>> -- Felix >>>> >>>> _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
