rbl check debug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

rbl check debug

David Wells - Alfavinil S.A.
Hi!

I have a postfix-3.3.2 installation (installed from source on slackware
14.2 from the slackbuilds package) that does rbl checks in the
smtpd_recipient_restrictions section. I have been seeing an increasing
amount of spam coming in so I added more reject_rbl_client instances
listing more and more rbl servers. However I still am seeing large
ammounts of spam getting through and I have checked several mails that
have come in using http://multirbl.valli.org/ and the servers from which
they arrive are listed in at least one of these rbl checks, most times
in more than one. Is there a way to debug why these mails are getting
through even though they come from an rbl blacklisted server?

This is the output of postconf -n

> command_directory = /usr/sbin
> compatibility_level = 2
> content_filter = amavisfeed:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> ddd $daemon_directory/$process_name $process_id & sleep 5
> html_directory = /usr/doc/postfix-3.3.2/html
> inet_protocols = ipv4
> insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
> mail_owner = postfix
> mailbox_command = /usr/libexec/dovecot/deliver -f "$SENDER" -a
> "$RECIPIENT"
> mailbox_size_limit = 0
> mailq_path = /usr/bin/mailq
> manpage_directory = /usr/man
> message_size_limit = 20971520
> meta_directory = /etc/postfix
> mydestination = $myhostname localhost.$mydomain localhost $mydomain
> mydomain = alfavinil.com
> myhostname = mail.alfavinil.com
> newaliases_path = /usr/bin/newaliases
> queue_directory = /var/spool/postfix
> readme_directory = /usr/doc/postfix-3.3.2/README_FILES
> sample_directory = /etc/postfix
> sendmail_path = /usr/sbin/sendmail
> setgid_group = postdrop
> shlib_directory = /usr/lib/postfix
> smtpd_client_restrictions = check_client_access hash:/etc/postfix/access
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, check_sender_access
> hash:/etc/postfix/sender_access, check_recipient_access
> hash:/etc/postfix/protected_destinations, check_client_access
> hash:/etc/postfix/rbl_whitelist, check_client_access
> regexp:/etc/postfix/rbl_whitelist_regexp, reject_unauth_destination,
> reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
> reject_rbl_client dnsbl.sorbs.net, reject_rbl_client
> dyna.spamrats.com, reject_rbl_client spam.spamrats.com,
> reject_rbl_client noptr.spamrats.com, reject_rbl_client
> auth.spamrats.com, reject_rbl_client dnsbl-1.uceprotect.net,
> reject_rbl_client dnsbl-2.uceprotect.net, reject_rbl_client
> dnsbl-3.uceprotect.net, reject_rbl_client b.barracudacentral.org,
> reject_rbl_client dnsbl.spfbl.net, reject_rbl_client
> rbl.blockedservers.com, reject_rbl_client bl.mailspike.net,
> reject_rbl_client bl.nosolicitado.org, reject_rbl_client all.s5h.net
> smtpd_restriction_classes = insiders_only
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous noplaintext
> smtpd_sasl_tls_security_options = noanonymous
> smtpd_sender_restrictions = reject_unknown_sender_domain
> smtpd_tls_CApath = /etc/ssl/certs
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/ssl/certs/fullchain.pem
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
> aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
> smtpd_tls_key_file = /etc/ssl/private/privkey.pem
> smtpd_tls_security_level = may
> unknown_local_recipient_reject_code = 550

These are the contents of rbl_whitelist

> axoft.com OK
> rgcc.com.ar                     OK
> arnetbiz.com.ar                 OK
> websitewelcome.com              OK
> messagelabs.com                 OK
> perfora.net                     OK
> toservers.com                   OK
> grupooperadores.com             OK
> ecs-publi.erreparmail.com       OK
> mx236-39.interman.com.ar        OK
> interquimica.com.uy             OK
> bma-borrachas.com.br            OK
> repicky.com.ar                  OK
> 200.47.67.78                    OK
> srv25.repicky.local             OK
> ecs-srv5.erreparmail.com        OK
> adiel.toservers.com             OK
> 190.61.250.130                  OK

These are the contents of rbl_whitelist_regexp
> /^mail-.*\.google\.com$/ OK
> /^sonic.*\.yahoo\.com$/                 OK
> /^rout.*\.hes\.trendmicro\.com$/        OK
> /^semf.*\.mfg\.siteprotect\.com$/       OK
> /^mx.*-.*\.interman\.com\.ar$/          OK
> /^sender.*-of-o.*\.zoho\.com$/                  OK
> /^hm.*-.*\.locaweb\.com\.br$/           OK
> /^srv.*\.repicky\.local$/               OK
> /^ecs-srv.*\.erreparmail\.com$/         OK

Thanks!
Best regards,
David Wells.


Reply | Threaded
Open this post in threaded view
|

Re: rbl check debug

Wietse Venema
David Wells:

> Hi!
>
> I have a postfix-3.3.2 installation (installed from source on slackware
> 14.2 from the slackbuilds package) that does rbl checks in the
> smtpd_recipient_restrictions section. I have been seeing an increasing
> amount of spam coming in so I added more reject_rbl_client instances
> listing more and more rbl servers. However I still am seeing large
> ammounts of spam getting through and I have checked several mails that
> have come in using http://multirbl.valli.org/ and the servers from which
> they arrive are listed in at least one of these rbl checks, most times
> in more than one. Is there a way to debug why these mails are getting
> through even though they come from an rbl blacklisted server?

Check the time TIME STAMPS in your logs.

Spammers are not immediately listed. There is a delay during which
a DNSBL will not list a spammer's IP address. By the time that you
do a maual DNSBL lookup, the DNSBL may have been updated.

Another possible reason is that DNS lookup result times out or fails
for other reasons; Postfix will log such problems.

        Wietse
>
>
Reply | Threaded
Open this post in threaded view
|

Re: rbl check debug

Viktor Dukhovni
In reply to this post by David Wells - Alfavinil S.A.
On Fri, Oct 16, 2020 at 06:04:20PM -0300, David Wells wrote:

> > smtpd_recipient_restrictions =
> >     permit_mynetworks, permit_sasl_authenticated,
> >     check_sender_access hash:/etc/postfix/sender_access,
> >     check_recipient_access hash:/etc/postfix/protected_destinations,
> >     check_client_access hash:/etc/postfix/rbl_whitelist,
> >     check_client_access regexp:/etc/postfix/rbl_whitelist_regexp,
> >     reject_unauth_destination,

Wietse's answer is the most obvious starting point, but if you want
to also look elsewhere:

Why is there a "check_sender_access" *before*
"reject_unauth_destination", and before the RBL checks?  Does the
"sender_access" table have anything other than REJECT rules?

> >     reject_rbl_client zen.spamhaus.org,
> >     reject_rbl_client bl.spamcop.net,
> >     reject_rbl_client dnsbl.sorbs.net,
> >     reject_rbl_client dyna.spamrats.com,
> >     reject_rbl_client spam.spamrats.com,
> >     reject_rbl_client noptr.spamrats.com,
> >     reject_rbl_client auth.spamrats.com,
> >     reject_rbl_client dnsbl-1.uceprotect.net,
> >     reject_rbl_client dnsbl-2.uceprotect.net,
> >     reject_rbl_client dnsbl-3.uceprotect.net,
> >     reject_rbl_client b.barracudacentral.org,
> >     reject_rbl_client dnsbl.spfbl.net,
> >     reject_rbl_client rbl.blockedservers.com,
> >     reject_rbl_client bl.mailspike.net,
> >     reject_rbl_client bl.nosolicitado.org,
> >     reject_rbl_client all.s5h.net

That's way too many, and many certainly too aggressive to be sufficient
on their own for a definitive reject.  Just zen.spamhaus.org is
generally all you can use without combining results for scoring.

And you certainly don't need a "noptr" list, just use:

    reject_unknown_reverse_client_hostname


> >     smtpd_restriction_classes = insiders_only

Where does this come into play?

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: rbl check debug

Dominic Raferd
In reply to this post by David Wells - Alfavinil S.A.
On 16/10/2020 22:04, David Wells wrote:

> I have a postfix-3.3.2 installation (installed from source on
> slackware 14.2 from the slackbuilds package) that does rbl checks in
> the smtpd_recipient_restrictions section. I have been seeing an
> increasing amount of spam coming in so I added more reject_rbl_client
> instances listing more and more rbl servers. However I still am seeing
> large ammounts of spam getting through and I have checked several
> mails that have come in using http://multirbl.valli.org/ and the
> servers from which they arrive are listed in at least one of these rbl
> checks, most times in more than one. Is there a way to debug why these
> mails are getting through even though they come from an rbl
> blacklisted server?
On top of the excellent advice already given, another possible cause:
you are not running a local DNS server and so your lookups are passing
through an external one (such as your ISP's) and are RBLs are refusing
to give (useful) responses because the source IP that they see (of the
external DNS server) doesn't look private or has submitted too many
lookups.
Reply | Threaded
Open this post in threaded view
|

Re: rbl check debug

Demi M. Obenour
In reply to this post by David Wells - Alfavinil S.A.
Just FYI, GMail marked this mail as spam.

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment