Re: [cobalt-security] Pros & Cons of change to Sendmail and can you do this on a Qube 3 ?

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

> 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