rspamd, postscreen, rbl, surbl, server doing double work?

[David Mehler]

Hello,

I'm wondering if my email server running postfix 3.3 and rspamd 1.79
is doing double work in the area of rbl/surbl setups. First I have
postfix's postscreen going that's the first block below. Then I have
rspamd's rbl and surbl configurations.

I'd appreciate it if someone could check these over and let me know if
the server is doing double duty and if so what a more streamlined
approach would be.

Thanks.
Dave.

# postfix postscreen
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3
b.barracudacentral.org*2
bl.spameatingmonkey.net*2
bl.spamcop.net
dnsbl.sorbs.net
psbl.surriel.com
bl.mailspike.net
swl.spamhaus.org*-4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_whitelist_threshold = -1

#local.d/rbl.conf:
default_received = true;

# local.d/surbl.conf:
# List of domains that are not checked by surbl
whitelist = "file://$CONFDIR/surbl-whitelist.inc";
# Additional exceptions for TLD rules
exceptions = "file://$CONFDIR/2tld.inc";

rules {
"SURBL_MULTI" {
# DNS suffix for this rule
suffix = "multi.surbl.org";
bits {
# List of bits ORed when reply is given
JP_SURBL_MULTI = 64;
AB_SURBL_MULTI = 32;
MW_SURBL_MULTI = 16;
PH_SURBL_MULTI = 8;
WS_SURBL_MULTI = 4;
SC_SURBL_MULTI = 2;
}
}
"URIBL_MULTI" {
suffix = "multi.uribl.com";
bits {
URIBL_BLACK = 2;
URIBL_GREY = 4;
URIBL_RED = 8;
}
}
"RAMBLER_URIBL" {
suffix = "uribl.rambler.ru";
# Also check images
images = true;
}
"DBL" {
suffix = "dbl.spamhaus.org";
# Do not check numeric URL's
noip = true;
}
"SEM_URIBL_UNKNOWN" {
suffix = "uribl.spameatingmonkey.net";
bits {
SEM_URIBL = 2;
}
noip = true;
}
"SEM_URIBL_FRESH15_UNKNOWN" {
suffix = "fresh15.spameatingmonkey.net";
bits {
SEM_URIBL_FRESH15 = 2;
}
noip = true;
}
}

# follow redirects when checking URLs in emails for spamminess
redirector_hosts_map = "/usr/local/etc/rspamd/redirectors.inc";

[Vsevolod Stakhov]

On 04/08/2018 18:06, David Mehler wrote:
> Hello,
>
> I'm wondering if my email server running postfix 3.3 and rspamd 1.79
> is doing double work in the area of rbl/surbl setups. First I have
> postfix's postscreen going that's the first block below. Then I have
> rspamd's rbl and surbl configurations.
>
> I'd appreciate it if someone could check these over and let me know if
> the server is doing double duty and if so what a more streamlined
> approach would be.

The beast approach is to use Rspamd only. Blocking email based solely on
RBLs could be dangerous.

[Philip Paeps]

On 2018-08-04 23:06:32 (+0600), David Mehler wrote:
> I'm wondering if my email server running postfix 3.3 and rspamd 1.79
> is doing double work in the area of rbl/surbl setups. First I have
> postfix's postscreen going that's the first block below. Then I have
> rspamd's rbl and surbl configurations.
> I'd appreciate it if someone could check these over and let me know if
> the server is doing double duty and if so what a more streamlined
> approach would be.

You're doing double work, but this is not necessarily a problem. Your
postscreen setup will keep the worst of the spammers from even getting
mail as far as rspamd. The weighting also seems reasonable enough to
prevent too many false positives on that level.

Rspamd will check the RBLs again, but it will weigh the scores together
with all the other scores it keeps. Something that managed to slip
through postscreen will be trapped by Rspamd.

If you're running a local DNS resolver, the RBL lookup by Rspamd will
(generally) hit the cache, so checking again isn't all that expensive.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

[Philip Paeps]

Given the setup David pasted, with postscreen weighing the scores of
several RBLs, I don't think that's a problem at all.

It's pretty difficult for a legitimate mailer to get themselves listed
by so many RBLs and failing to be sufficiently whitelisted by DNSWL.