• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Priority DNSBL vs. Whitelist

WebPro24

New Pleskian
Hello,

in the Plesk mailserver settings, DNS blackhole lists (like spamhaus.org) can be enabled to prevent spam. We want to use this, but need to enter an IP-range into the whitelist (that is also in the mailserver settings), to make sure, that certain IPs are never blocked. Whats the priority between the DNSBL and the whitelist? Does the whitelist stops IPs from been blocked, even if they are on a DNSBL? Is there a difference between Onyx and Obsidian in this?

Thank you
 
DNSBL is always handled first, because the purpose of that is to save cpu time on processing unnecessary mails before they even reach any software package on the system. The "Whitelist" is part of the anti spam solution. This only applies after all pre-processing (like blacklists) has been done.

Also see this thread, maybe this addresses your issues, too:
 
Hello,

thanks for your usefull answer. I found the following link regarding this problem:

> "The whitelist will override DNS blackhole lists, as the whitelisted addresses are listed in the "mynetworks" which are processing in the first place."
So, who is right?
 
Oh no, I am so sorry, I did not pay exact attention that you wrote "IP addresses". The whitelist I meant was the SpamAssassin whitelist where you can enter domains and wildcards for addresses. That is definitely processed last. I did not take the network IP whitelist into account. Plesk staff is (of course) right.

Actually, yes, the entries in the network IP whitelist go into the "mynetworks" parameter the Postfix main.cf configuration file. By definition, IP addresses listed in the "mynetworks" parameter are treated like "local" system IPs, so that several security mechanisms to mails coming from these IPs are omitted. Postfix will forward mail from clients in authorized networks to any destination.

There is a downside to this: It means, that the IP address block is not only passing the incoming DNSBL filters, but it also behaves as if it was the same machine. Spam sent from the outside for relaying will be relayed without further checks, because the IP is trusted. Other emails from the outside that want to abuse your system as a relay server will be relayed, too, without authorization, because the system will treat them as locally submitted mails.
 
Hello,

thanks for your reply.

The misunderstanding is no problem.

Please let me first clarify something: We both now talk about the following Whitelist, right?

Tools & Settings > Server-Wide Mail Settings > White List > Add Network

Please let me briefly explain our situation: The emails of our customers are filtered by external mailfilters, that are registered as MX in the DNS. To bypass spam-filtering like this, some spammers rarely send the emails directly to the server (adressing the host or IP). This is the situation we now have. To solve this, the best option in our scenario seems to be using DNSBL, because the spammer IPs are on some blacklists. But then we also have to whitelist the IP-net of the mx-mailfilter servers, because it´s not impossible that mx-mailfilter IPs sometimes get blacklisted, because they are relaying emails, that may sometimes include spam that was not recognized. That´s the background for my question about whitelisting, because in this scenario, the whitelist must(!) have priority, or it may happen, that all emails from the mx-mailfilters are treated as spam, if the mx-mailfilters get blacklisted, what would be quite a desaster of course.

> The whitelist I meant was the SpamAssassin whitelist where you can enter domains and wildcards for addresses.
> That is definitely processed last.

You may be right with this, but in SpamAssassin, there is the following option:
> trusted_networks ip.add.re.ss[/mask] ... (default: none)
> What networks or hosts are 'trusted' in your setup.
> ... DNS blacklist checks will never query for hosts on these networks.

So with "trusted_networks" SpamAssassin may be an option in our scenario, too.
 
The emails of our customers are filtered by external mailfilters, that are registered as MX in the DNS. To bypass spam-filtering like this, some spammers rarely send the emails directly to the server (adressing the host or IP).
in your scenario with external service, why not accept only the IP/range from the external mailfilters and block the others for example with an firewall rule?
 
in your scenario with external service, why not accept only the IP/range from the external mailfilters and block the others for example with an firewall rule?

In such a setup, you usually set the MX entries such that the external filter has the highest priority but the 'real' mailserver is also listed at a lower priority so that in case the external server fails for whatever reason, mail can still be delivered directly as a fallback.
If you do not want to be directly connected at all, you should not list the 'real' mailserver as MX.
 
Back
Top