Question SPAM Whitelist before DNSBL-Service to allow (override) temporarily blocked domains e.g. from freemailers

[W4ru]

Hello!

As known, whitelist entries can be set.
https://docs.plesk.com/en-US/obsidi...ide-black-and-white-lists.59436/Unfortunately, these seem to be processed only after defined lists (e.g. xbl.spamhaus.org).

If so-called freemailers are blocked in such a list (currently zen.spamhaus.org blocks e.g. gmx.de https://www.spamhaus.org/sbl/query/SBL594401 ),

the whole list must be removed. Moreover, you only become aware of this when it is "too late".

In the whitelist a defined list of positive addresses of the freemailer would be possible and the DNSBL service lists then sit for further behind it.

Would this be an improvement for SPAM handling?

 

[Peter Debik]

Hi @W4ru, this is technically not possible, because the Anti-Spam-Whitelist is something different than the DNSBL function. The DNSBLs like zen.spamhaus.org work through DNS, because that way requests are handled lightening fast. A DNS request is sent to the BL and the BL returns a response like 127.0.0.<code>. For example 127.0.0.1 could mean "coast is clear" while 127.0.0.2 could mean "known spammer". This is a process done from within the Postfix (sendmail) daemon (or at least attached to it).

So what you are asking is that if you set a wildcard whitelist-entry like *@alloweddomain.tld, mails that are coming from alloweddomain.tld should be excluded from DNSBL lookups. This is something that the existing DNSBL algorithms do not support. It would require several extra checks on domain resolution and would slow the overall process down. It would also require modification of the SMTP service. If you believe that such a special function should be added to Plesk, please define it on Feature Suggestions: Top (2197 ideas) – Your Ideas for Plesk If it gets many votes, maybe it will be realized.

For the time being, maybe you can use Postfix's permit_dnswl_client parameter. I suggest to add it to your Postfix config file like this:
In /etc/postfix/main.cf find the line smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, ....
Behind permit_sasl_authenticated and before reject_rbl_client insert , permit_dnswl_client list.dnswl.org.
The list.dnswl.org is doing the opposite of what DNSBLs do. They maintain a whitelist of well known email providers so that their mails won't be processed by blacklists.
A complete entry of that line would for example look similar to this:

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_dnswl_client list.dnswl.org, reject_rbl_client sbl.spamhaus.org,
reject_rbl_client xbl.spamhaus.org, reject_rbl_client b.barracudacentral.org

The extra whitelist insertion will not be overwritten by Plesk if you apply changes to the blacklists from within GUI.

 

[W4ru]

Thank you Peter, for this detailed explanation.

Indeed, I had also thought in this way (your description), but now I also understand in detail what is occurring that way.

Your further hints really motivate me to implement this, as it will be a benefit for all users in any case. Many thanks for that as well!

For the submission of an idea I also already have a suggestion (here only sketch):

The DNSBL data could be cached in the local Plesk (hourly poll would be loosely ok) and then put against a whitelist and only this is actually applied.

Thanks again!

 

[Peter Debik]

If you can outline your idea for a new feature, please add it to Feature Suggestions: Top (2198 ideas) – Your Ideas for Plesk

 

[danami]

@W4ru You should note that our Warden Anti-spam and Virus Protection extension allows you to whitelist/blacklist by IP addreses / CIDR, envelope senders, envelope recipients etc. This all happens at the postfix level. So you instead of having to remove the whole RBL you can just add the IP address / CIDR to the whitelist and it will bypass the DNSBL.