Usermin adding X-Originating-IP causes SpamAssassin to classify valid email as spam

I had an incredible false-positive today:

  1. Logged-in from a dynamic IP address into Usermin on port 20000 as normal.
  2. Sent an email to another email address on the same server, both managed by Virtualmin Pro with local DNS server on that same server (!) with valid SPF records AND with valid rDNSes
  3. It arrived into the spambox

Reason:

Content analysis details:   (6.5 points, 5.0 required)

pts rule name              description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                           [188.60.90.1 listed in zen.spamhaus.org]
1.6 RCVD_IN_BRBL_LASTEXT   RBL: RCVD_IN_BRBL_LASTEXT
                           [188.60.90.1 listed in bb.barracudacentral.org]
0.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
                           [188.60.90.1 listed in dnsbl.sorbs.net]
1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS

Looking at the raw email headers, the only place where that IP address is listed is:

X-Originating-IP: 188.60.90.1

And that may have had been added only by Virtualmin !

Maybe a different "X-" header could be used for that information ? or actually not be added at all, as it is a privacy issue too (as you sometimes log into Usermin to get a clean and valid IP address) ?

I'm classifying this as a Usermin bug, as SpamAssassin verifies that IP address in their database as SMTP ORIGIN.

Status: 
Active

Comments

Howdy -- You can disable the X-Originating-IP header by going into Webmin -> Webmin -> Usermin Configuration -> Usermin Modules -> Read Mail, and set "Include browser IP in X-Originating-IP header" to "No".

Thanks!

Indeed both following are YES by default:

Include browser IP in X-Originating-IP header? Include Webmin version in X-Mailer header?

imho, as SpamAssissin is highly sensible to them (and applies the wrong RBL Dynamic-IP rule using them) both should be No by default.

(This doesn't mean that the originator's IP address doesn't have to be stored locally in the logs in case of abuse, but that's already the case somewhere probably?)

I'll change this to "No" by default in the next Usermin release.