how to bypass the filtering of incoming emails from a specific external relay

[richardlg61]

Hello, I need help on my installation.

I would like the incoming mail from an external antispam solution to a specific internal mail domain behind EFA not to be filtered but I don't know the recommended configuration to apply on my EFA server.

Is it possible ? Can you help me ?

Thanks you.
Richard.

[shawniverson]

Yes, you can. Probably the easiest way would be simply to add the domain to your allow/white list:

From: default
To: example.org

[richardlg61]

Hi shawniverson

Ok thank you !

I have another question, why systematically, the rule "SPF_FAIL" and "SPF_HELO_NONE" appears ? It increases the score, yet the original IP address of the sender is present in their SPF record so it is valid.

I have the impression that the EFA server is checking the IP of the last relay and not the original IP of the sender.
Is this normal?

Richard.

[shawniverson]

That is normal because you are behind another relay.

[richardlg61]

Okay, but instead of whitelisting incoming emails from the external relay to my internal mail server.
In my configuration : EXTERNAL_RELAY <-> FW <-> EFA <-> MAIL SERVER
Is it possible to trust the external relay easily without executing the SpamAssassin rules?
The fact of whitelisting does not please me too much because if the day or our client no longer has the current anti-spam solution, all unwanted emails will go through the EFA.

I made several modifications on two files (/etc/mail/spamassassin/mailscanner.cf and /etc/mail/spamassassin/local.cf) to try to approve the external relay but i can't, something must be missing.

in /etc/mail/spamassassin/mailscanner.cf

Code: Select all

score ALL_TRUSTED -5

in /etc/mail/spamassassin/local.cf

Code: Select all

trusted_networks 123.45.6.7 

#   if you have taken the time to correctly specify your "trusted_networks",
#   this is another good way to save CPU
#
shortcircuit ALL_TRUSTED             on

I also restarted the Mailsanner and spamassassin services without success.
The shortcircuit plugin is enabled.

Can you help me ? Thanks.

Richard

[shawniverson]

That should be working if your shortcircuit plugin is enabled.

Maybe run sa-update?

[richardlg61]

sa-update dont work :/

I found the solution thanks to the Debug option of spamassassin to avoid checking the SPF for mails coming from an external relay. Spam rules still apply.
In /etc/mail/spamassassin/local.cf,
I declared the "internal_networks" parameter for the "trusted_networks" parameter to take effect and inform the mail servers in "trusted_networks" and "internal_networks" parameters.

By default, the "internal_networks" parameter is not present and is required for trusted_networks to work.
Anyway, that's what I understood

Now :

Code: Select all

Oct 19 17:30:39.800 [3100851] dbg: netset: trusted_networks patricia lookup on 217.XXX.XXX.XXX, 17 networks, result: 1, 0.060 ms
Oct 19 17:30:39.800 [3100851] dbg: netset: internal_networks patricia lookup on 217.XXX.XXX.XXX, 4 networks, result: 0, 0.012 ms
Oct 19 17:30:39.800 [3100851] dbg: received-header: relay 217.XXX.XXX.XXX trusted? yes internal? no msa? no
Oct 19 17:30:39.801 [3100851] dbg: received-header: parsed as [ ip=xx.xxx.xxx.xxx rdns=external_mailserver helo=external_mailserver by=other_mx ident= envfrom= intl=0 id=4HXmVl2nZvz1pDr auth= msa=0 ]

[shawniverson]

Interesting, I don't have internal_networks defined but mine seems to work. Not sure why though. According to the documentation if internal_networks is not set, then internal_networks is supposed to default to trusted_networks.

"If trusted_networks is set and internal_networks is not, the value of trusted_networks will be used for this parameter."

[richardlg61]

Yes, it's strange ^^

Without internal_networks parameter configured :

Code: Select all

Oct 21 13:49:03.985 [3528494] dbg: config: internal_networks not configured, using trusted_networks configuration for internal_networks; if you really want internal_networks to only contain the required 127/8 add 'internal_networks !0/0' to your configuration
Oct 21 13:49:03.986 [3528494] dbg: received-header: parsed as [ ip=35.xxx.xxx.xxx rdns=xxxxxxxxxxxxx helo=xxxxxxxxxxxxxx by=xxxx ident= envfrom= intl=0 id=4HWH8b5LdFzGwFQF auth= msa=0 ]
Oct 21 13:49:03.986 [3528494] dbg: netset: trusted_networks patricia lookup on 35.xxx.xxx.xxx, 17 networks, result: 1, 0.045 ms
Oct 21 13:49:03.986 [3528494] dbg: netset: trusted_networks cached lookup on 35.xxx.xxx.xxx, 17 networks, result: 1
Oct 21 13:49:03.986 [3528494] dbg: received-header: relay 35.xxx.xxx.xxx trusted? yes internal? yes msa? no

And IP is automatically considered as internal network while it is an external ip.

However, how can you avoid spam filtering emails from approved external relays?
I can't do it

Richard

[pdwalker]

*bump*

I had to solve this problem today.

trusted_relays wasn't honouring the ip addresses I had defined as "safe", but worked when I defined them as internal_relays.

[MarkMe]

*bump*

I had to solve this problem today.

trusted_relays wasn't honouring the ip addresses I had defined as "safe", but worked when I defined them as internal_relays.

Is the problem is resolved yet? Or not?

[pdwalker]

it's resolved for me by defining the internal_relays parameter.