Re: [webmin-l] Virtualmin marking all email within domains on the server as spam

[Kris D. <kd...@vi...>]

Denis Croombs wrote:
> Yes and almost every available IP address I have for the last few months
> from my provider. (I have just tried 10 reboots in the last few minutes
> and all 10 were already also blocked)

[kdeugau@fatso ~]$ whois 86.41.66.254
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '86.40.0.0 - 86.42.255.255'

inetnum:        86.40.0.0 - 86.42.255.255
netname:        EIRCOM
descr:          Eircom
descr:          IP Network Infrastructure (ADSL Address Pools)
   [....]
route:        86.40.0.0/13
[snip]

It doesn't say, but I'd guess these are mostly not static IPs - and your 
note about getting a different IP on reboot indicates not.

That explains most of the SpamAssassin rule hits you reported - your 
reverse DNS looks like a dynamic IP because it is (several rules trigger 
on various subcases of this).

Also, many providers explicitly report blocks of their own IP address 
space to blacklist services (eg, Spamhaus PBL [the "Policy Block List"]) 
as IP ranges that should not be directly sending email to third parties. 
  I don't think the senderscore.com or Barracuda lists do this, but they 
*do* tag and report blocks of IP address space that look like dynamic IPs.

The remaining high-scoring rule (DOS_OUTLOOK_TO_MX) indicates the 
message was delivered directly to the MX machine from the sending 
client.  Since you're sending mail within a domain, or across domains 
hosted entirely on the same server, this is a bit harder to get around.

You'll have to read up on SpamAssassin's "trust path" settings - but 
note that you **really** need a static IP to effectively use these, as 
they rely on knowing which IPs are part of "your" network, and which IPs 
handle which bits of mail processing for your services.

Or you could set the score for this rule to 0, and accept the reduced 
accuracy this will cause.

I'm not aware of any Webmin/Virtualmin components that understand the 
finer details of SpamAssassin's configuration;  you'll probably have to 
add an entry either via the "Edit config file" option in Webmin, or in a 
shell session on the server.

I'm assuming Virtualmin usually sets up calls to SpamAssassin on mail 
delivery (eg from a global or per-user procmailrc), where the MX machine 
has already added its Received: header.  Other methods of calling SA (at 
different points in incoming mail processing) are known to falsely 
trigger a number of the rules you reported if you aren't careful in 
configuring both the caller and SA.

-kgd