> not the same thing, this is a reject for non existant domains. Dropping > mail for which reverse dns produces a different name then the mailserver > used to id' itsself will block way more servers.
In my experience this is a two egdged sword and I wouldn't recommend it. Here is an example to illustrate the problems: My email address is <username>@solarspeed.net. The domain resides on a server that is named "nathan.smd.net" and hosts multiple domains on the same IP, but also on other IPs associated to that box. One of the domains on the same IP is "solarspeed.de". Now when you do a reverse lookup on said IP, then the reported name is "solarspeed.de" (not .net!), but it could also be another random domain name which happens to run on the same IP. Additionally my mail relay is mail.smd.net and doesn't even run on the same domain, same IP or same server for that matter. So in my case the reverse lookup on the IP will return a different name than used in the "From" field of the email. The same will happen for all cases of virtual hosting where multiple domains are hosted on the same IP, which is a common and perfectly legit scenario. In the end you might block a lot of legitimate emails with this method. The DNS based approaches which yield the best results in my experience are: 1.) Blocking emails from domains with faked host or domain names 2.) Using as many good RBL lists as is sensible Aside from that and beyond pure RBL checking: 3.) Using SpamAssassin with all goodies enabled (DCC, Razor, Pyzor, Bayes) 4.) Using the plugin Mail::SpamAsssassin::SpamCopURI 0.14 (see: http://sourceforge.net/projects/spamcopuri ). It'll be a built in feature of SpamAssassin-3.0 as it has prooven it's worth. Said plugin is a new feature which scans message bodies for URLs. The extraxted host and domain names are then queried against a Spamhaus RBL list which contains such blacklisted promo URLs (or the domains which they're hosted on). These four methods combined are still not bullet proof - of course. But they get 98% or more of all SPAM and generate very few false positives. The side effect of that much filtering is additionally needed processing power, processing time and of course increased network traffic due to all the RBL lists that are queried. -- With best regards, Michael Stauber _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
