• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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