Thoughts regarding X-Originating-IP headers

[pup_seba]

Hi,

Just wondering, how do you usually configure this? In my case, I usually try to leave it on, and if false positives come up because of it, then I turn it off. I like having the traceability it provides, but most of the times it gives more problems than solutions.

[L. Mark Stone]

Years ago I would turn off X-Originating-IP, but now I keep it turned on because It is necessary for the IP blocking capability of DoSFilter, which I find very useful.

The false positives in my experience are all from ZCO users on dynamic and other IP addresses that SpamAssassin wants to block/score highly. The fix for this latter problem is to change the score for the two SpamAssassin tests that cause this. As I mention in my Anti-Spam Best Practices 2019 blog post, if you add these two lines to /opt/zimbra/data/spamassassin/localrules/sauser.cf (creating the file if it doesn't already exist), you'll stop blocking legitimate emails sent by ZCO users.

Code: Select all

score DOS_OUTLOOK_TO_MX 0
score TO_EQ_FM_DIRECT_MX 0

If you see other false positives, that would be good to know. I'd be happy to update my blog post accordingly!

Blog post here: https://www.missioncriticalemail.com/20 ... ices-2019/

Hope that helps,
Mark

[pup_seba]

Hi Mark!

Barely today, it happend to me that in my lab enviroment, when sending mails with that option enabled, these SA filters where kicking in:
RCVD_IN_PBL=3.558
RDNS_NONE=1.274
RCVD_IN_SORBS_DUL=0.001

I was performing the tests from my home (i was testing some other thing actually), which in fact is a dyanamic IP that is listed in PBL and others.

I guess best course of action here would be to lower these scores?

[L. Mark Stone]

I think it could be good to reduce the RCVD_IN_PBL yes.

Interesting old discussion on this here:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6501

All the best,
Mark

[ccelis5215]

Hi Mark!

Barely today, it happend to me that in my lab enviroment, when sending mails with that option enabled, these SA filters where kicking in:
RCVD_IN_PBL=3.558
RDNS_NONE=1.274
RCVD_IN_SORBS_DUL=0.001

I was performing the tests from my home (i was testing some other thing actually), which in fact is a dyanamic IP that is listed in PBL and others.

I guess best course of action here would be to lower these scores?

Hi, messages from internal users, authenticate users?

ccelis

[andrey.ivanov]

I usually leave the X-originating-IP header intact for debugging/traceability but i switch off its verification from spamassassin rules (10_default_prefs.cf file in default and updated rules):

Code: Select all

# delete X-Originating-IP from spamminess analysis
sed -i 's@X-Originating-IP @@' /opt/zimbra/data/spamassassin/rules/10_default_prefs.cf
sed -i '/qx(\$restart);/ i qx(sed -i "s#X-Originating-IP ##" /opt/zimbra/data/spamassassin/rules/10_default_prefs.cf);' /opt/zimbra/libexec/zmsaupdate
sed -i '/qx(\$restart);/ i qx(sed -i "s#X-Originating-IP ##" /opt/zimbra/data/spamassassin/state/3.004001/updates_spamassassin_org/10_default_prefs.cf);' /opt/zimbra/libexec/zmsaupdate

The part with zmsaupdate is necessary since it downloads new rules every day. This replacement by sed is to be done after each zimbra version change. I use this method since Zimbra 8.0 and it was always working fine.

[JDunphy]

Have you tried this in salocal.cf ... I can see from my comments I wasn't pleased with running BL tests against client side headers. You can also remove explicit headers if you still want to filter on some but not all with SA. I have always thought that trusted_networks was responsible for some of these rules firing against authenticated users. Certainly, PBL was never ment to be run against authenticated clients from reading the projects goal. I don't have problems with these rules firing in our configurations by SA and we still leave the header as a courtesy. I am laughing at my comments now since I must of really been in a bad mood with a false positive to take them all out. LOL

Code: Select all

# No RBL checks on X- headers. We commented out the adding to the list of X- headers to check
#   against blacklists (RBL). Makes no sense to have these checks.
# Headers to parse for originating IP address
if (can(Mail::SpamAssassin::Conf::feature_originating_ip_headers))
clear_originating_ip_headers
#originating_ip_headers X-Yahoo-Post-IP X-Originating-IP X-Apparently-From
#originating_ip_headers X-SenderIP X-AOL-IP
endif

[pup_seba]

Nope, i never digged so deep I will usually break more things that I'll improve

While we are at it, is this the place to tune if we want to hide our hostnames to the public? I'm talking about the local hostnames that appear in the headers of the mail.

[JDunphy]

While we are at it, is this the place to tune if we want to hide our hostnames to the public? I'm talking about the local hostnames that appear in the headers of the mail.

I am not sure... In the past, I didn't like leaking the ip addresses for our remote offices or our homes when using MUA's because of this header ... so I used postfix_header_checks to fix headers I didn't like. Sometimes, I would replace it with our external ip like the zimbra server but other times, just created a new header that made up some fib. You could probably do it there to sanitize your outgoing email if that was a desired goal.

Code: Select all

% grep -i X-Originating */*/*
mods/opt.zimbra.conf/postfix_header_checks:/^X-Originating-IP:.*24\.X\.Y\.Z.*/         REPLACE XX-Originating-IP: Authenticated phone or internet dongle on network

I don't find much value in doing this anymore, but I get that it's another layer even if its obfuscation and might be appropriate for some security policies.

[pup_seba]

And just like that...you saved me probably hours of trying to find out how to do this. Thanks a lot!!!