Postscreen exceptions and blacklisting

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

Postscreen exceptions and blacklisting

Nikolaos Milas
Hello,

I have tried to whitelist some servers for postscreen, but I notice that
they continue to get blocked if they are blacklisted.

What I am doing wrong in whitelisting them?

How can I successfully whitelist them so that they are not blocked even
if they are blacklisted in a RBL/RSBL?

Here is a session with remote server 195.134.100.81 (ours is 62.217.124.2):

Aug 31 11:14:01 mailgw3 postfix/postscreen[6476]: CONNECT from
[195.134.100.81]:50520 to [62.217.124.2]:25
Aug 31 11:14:02 mailgw3 postfix/dnsblog[6328]: addr 195.134.100.81
listed by domain b.barracudacentral.org as 127.0.0.2
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DNSBL rank 2 for
[195.134.100.81]:50520
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
[195.134.100.81] blocked using b.barracudacentral.org; from=<>,
to=<[hidden email]>, proto=SMTP, helo=<mta02.uoa.gr>
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
[195.134.100.81] blocked using b.barracudacentral.org;
from=<[hidden email]>, to=<[hidden email]>, proto=SMTP,
helo=<mta02.uoa.gr>
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DISCONNECT
[195.134.100.81]:50520

My setup (on Postfix 2.11.0):

# postconf -n
allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
allowed_list2 = check_client_access
cidr:/etc/postfix/internalnetworks.cidr,reject
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[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
xxgdb $daemon_directory/$process_name $process_id & sleep 5
default_process_limit = 50
disable_vrfy_command = yes
enable_long_queue_ids = yes
header_checks = pcre:/etc/postfix/blacklisted_maillists
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_recipient_maps =
local_transport = error:local mail delivery is disabled
mail_name = NOA Mail Srv XAPITI XPICTOY
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 15728640
mydestination =
mynetworks = 127.0.0.1/32 [::1]/128
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_exceptions.cidr
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
psbl.surriel.com*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr,
space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr, hesperia-space.eu
relay_recipient_maps =
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_client_access
hash:/etc/postfix/amavis_bypass check_sender_access
hash:/etc/postfix/blacklisted_senders check_sender_access
pcre:/etc/postfix/blacklisted_maillists reject_unverified_recipient
reject_unauth_destination check_recipient_access
hash:/etc/postfix/protected_destinations permit_mynetworks
reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender
reject_unknown_sender_domain reject_non_fqdn_recipient
reject_unknown_recipient_domain reject_rbl_client b.barracudacentral.org
reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com
reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net
reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender
dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service
unix:postgrey/socket permit
smtpd_restriction_classes = allowed_list1,allowed_list2
smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1365536.crt
smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128
smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1365536.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtualmap

and cidr:/etc/postfix/postscreen_exceptions.cidr is:

    195.134.100.72       dunno
    195.134.100.69       dunno
    195.134.100.81       dunno
    195.134.100.119      dunno

Please advise!

Thanks a lot,
Nick

Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Nikolaos Milas
On 8/9/2017 11:36 πμ, Nikolaos Milas wrote:

> What I am doing wrong in whitelisting them?

Let me try to guess: should I use "permit" rather than "dunno" (in
postscreen_exceptions.cidr)?

If so, why "dunno" doesn't work? Shouldn't it whitelist a client from
any and all postscreen tests?

Please advise!

Thanks,
Nick
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

allenc
In reply to this post by Nikolaos Milas

In your exceptions list, use ACCEPT or REJECT;
DUNNO means "let something else decide" ...

Allen C

On 08/09/17 09:36, Nikolaos Milas wrote:

> Hello,
>
> I have tried to whitelist some servers for postscreen, but I notice that
> they continue to get blocked if they are blacklisted.
>
> What I am doing wrong in whitelisting them?
>
> How can I successfully whitelist them so that they are not blocked even
> if they are blacklisted in a RBL/RSBL?
>
> Here is a session with remote server 195.134.100.81 (ours is 62.217.124.2):
>
> Aug 31 11:14:01 mailgw3 postfix/postscreen[6476]: CONNECT from
> [195.134.100.81]:50520 to [62.217.124.2]:25
> Aug 31 11:14:02 mailgw3 postfix/dnsblog[6328]: addr 195.134.100.81
> listed by domain b.barracudacentral.org as 127.0.0.2
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DNSBL rank 2 for
> [195.134.100.81]:50520
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org; from=<>,
> to=<[hidden email]>, proto=SMTP, helo=<mta02.uoa.gr>
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org;
> from=<[hidden email]>, to=<[hidden email]>, proto=SMTP,
> helo=<mta02.uoa.gr>
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DISCONNECT
> [195.134.100.81]:50520
>
> My setup (on Postfix 2.11.0):
>
> # postconf -n
> allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
> allowed_list2 = check_client_access
> cidr:/etc/postfix/internalnetworks.cidr,reject
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[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
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> default_process_limit = 50
> disable_vrfy_command = yes
> enable_long_queue_ids = yes
> header_checks = pcre:/etc/postfix/blacklisted_maillists
> html_directory = no
> inet_interfaces = all
> inet_protocols = ipv4, ipv6
> local_recipient_maps =
> local_transport = error:local mail delivery is disabled
> mail_name = NOA Mail Srv XAPITI XPICTOY
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 15728640
> mydestination =
> mynetworks = 127.0.0.1/32 [::1]/128
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_exceptions.cidr
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
> psbl.surriel.com*2
> postscreen_dnsbl_threshold = 2
> postscreen_greet_action = enforce
> queue_directory = /var/spool/postfix
> relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr,
> space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr, hesperia-space.eu
> relay_recipient_maps =
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = check_client_access
> hash:/etc/postfix/amavis_bypass check_sender_access
> hash:/etc/postfix/blacklisted_senders check_sender_access
> pcre:/etc/postfix/blacklisted_maillists reject_unverified_recipient
> reject_unauth_destination check_recipient_access
> hash:/etc/postfix/protected_destinations permit_mynetworks
> reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender
> reject_unknown_sender_domain reject_non_fqdn_recipient
> reject_unknown_recipient_domain reject_rbl_client b.barracudacentral.org
> reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com
> reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net
> reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender
> dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service
> unix:postgrey/socket permit
> smtpd_restriction_classes = allowed_list1,allowed_list2
> smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
> smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1365536.crt
> smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128
> smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1365536.key
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_timeout = 3600s
> transport_maps = hash:/etc/postfix/transportmap
> unknown_local_recipient_reject_code = 550
> unverified_sender_reject_code = 550
> virtual_alias_maps = hash:/etc/postfix/virtualmap
>
> and cidr:/etc/postfix/postscreen_exceptions.cidr is:
>
>    195.134.100.72       dunno
>    195.134.100.69       dunno
>    195.134.100.81       dunno
>    195.134.100.119      dunno
>
> Please advise!
>
> Thanks a lot,
> Nick
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Nikolaos Milas
On 8/9/2017 1:56 μμ, Allen Coates wrote:

> DUNNO means "let something else decide" ...

Hi Allen,

I understand that, but shouldn't this also mean "Bypass ALL
postscreen-related checks & filtering", which should avoid blocking by
RBLs used within postscreen?

Cheers,
Nick
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Wietse Venema
Nikolaos Milas:
> On 8/9/2017 1:56 ??, Allen Coates wrote:
>
> > DUNNO means "let something else decide" ...
>
> Hi Allen,
>
> I understand that, but shouldn't this also mean "Bypass ALL
> postscreen-related checks & filtering", which should avoid blocking by
> RBLs used within postscreen?

It means this:

        dunno All postscreen(8) access lists implicitly have this  command  at
              the end.
              When   dunno  is executed inside a lookup table, return from the
              lookup table and evaluate the next command.
              When  dunno  is executed outside a lookup table,  terminate  the
              search,  and  subject  the client to the configured before/after
              220 greeting tests.

Just as with smtpd access maps, permit/reject are a final decision,
and dunno means 'let something else make the decision'.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Nikolaos Milas
In reply to this post by allenc
On 8/9/2017 1:56 μμ, Allen Coates wrote:

> In your exceptions list, use ACCEPT or REJECT;

By the way, can we interchangeably use any of the values ACCEPT / PERMIT
/ OK ?

If so, can you please reference any associated documentation?

I ask because at http://www.postfix.org/POSTSCREEN_README.html the
values described (for acceptance) are "PERMIT", while in the CIDR table
documentation (http://www.postfix.org/cidr_table.5.html) the respective
example shows: "OK".

Thanks a lot,
Nick
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Nikolaos Milas
In reply to this post by Wietse Venema
On 8/9/2017 2:42 μμ, Wietse Venema wrote:

> Just as with smtpd access maps, permit/reject are a final decision,
> and dunno means 'let something else make the decision'.

Thank you Wietse,

Please let my ask for a clarification here. The problem is that the
rejection seems to have happened by postscreen itself.

I would expect that by using dunno for a client in postscript_exceptions
(as follows):

    postscreen_access_list =
             permit_mynetworks,
             cidr:/etc/postfix/postscreen_exceptions.cidr

all the following postscreen directives would by bypassed for this client:

    postscreen_dnsbl_threshold = 2
    postscreen_dnsbl_sites =
             b.barracudacentral.org*2,
             zen.spamhaus.org*2,
             psbl.surriel.com*2
    postscreen_dnsbl_action = enforce
    postscreen_greet_action = enforce
    postscreen_blacklist_action = enforce

Isn't this true?

In particular, why the postscreen_access_list did not affect the
postscreen_dnsbl_action, which I would expect to be bypassed?

Can you please explain? Which postscreen actions are affected by
postscreen_access_list?

Sorry if my question is dumb.

Thanks a lot,
Nick

Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Matus UHLAR - fantomas
>On 8/9/2017 2:42 μμ, Wietse Venema wrote:
>>Just as with smtpd access maps, permit/reject are a final decision,
>>and dunno means 'let something else make the decision'.

On 08.09.17 15:03, Nikolaos Milas wrote:

>Please let my ask for a clarification here. The problem is that the
>rejection seems to have happened by postscreen itself.
>
>I would expect that by using dunno for a client in
>postscript_exceptions (as follows):
>
>   postscreen_access_list =
>            permit_mynetworks,
>            cidr:/etc/postfix/postscreen_exceptions.cidr
>
>all the following postscreen directives would by bypassed for this client:
>
>   postscreen_dnsbl_threshold = 2
>   postscreen_dnsbl_sites =
>            b.barracudacentral.org*2,
>            zen.spamhaus.org*2,
>            psbl.surriel.com*2
>   postscreen_dnsbl_action = enforce
>   postscreen_greet_action = enforce
>   postscreen_blacklist_action = enforce

>Isn't this true?

no.

use permit in postscreen_exceptions.cidr to avoid remaining tests or reject
to reject immediately.

dunno is not even documented to work with postfix.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet.
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

/dev/rob0
In reply to this post by Nikolaos Milas
On Fri, Sep 08, 2017 at 03:03:49PM +0300, Nikolaos Milas wrote:

> On 8/9/2017 2:42 μμ, Wietse Venema wrote:
> > Just as with smtpd access maps, permit/reject are a final
> > decision, and dunno means 'let something else make the decision'.
>
> Please let my ask for a clarification here. The problem is that
> the rejection seems to have happened by postscreen itself.
>
> I would expect that by using dunno for a client in
> postscript_exceptions (as follows):
>
>    postscreen_access_list =
>             permit_mynetworks,
>             cidr:/etc/postfix/postscreen_exceptions.cidr
>
> all the following postscreen directives would by bypassed for
> this client:
>
>    postscreen_dnsbl_threshold = 2
>    postscreen_dnsbl_sites =
>             b.barracudacentral.org*2,
>             zen.spamhaus.org*2,
>             psbl.surriel.com*2
>    postscreen_dnsbl_action = enforce
>    postscreen_greet_action = enforce
>    postscreen_blacklist_action = enforce
>
> Isn't this true?

No, and I thought that was already answered.

> In particular, why the postscreen_access_list did not affect the
> postscreen_dnsbl_action, which I would expect to be bypassed?

Your DUNNO result only terminated the postscreen_access_list test.

> Can you please explain? Which postscreen actions are affected by
> postscreen_access_list?

A permit/OK result causes all postscreen tests to be bypassed.

> Sorry if my question is dumb.

It's really the wrong question.  The fundamental problem is that
you're trusting unsafe DNSBL services for outright rejection.  This
typically is the case for those who need whitelisting.

>    postscreen_dnsbl_threshold = 2

Default there is 1, and the way you are scoring things, you didn't
need this.

>    postscreen_dnsbl_sites =
>             b.barracudacentral.org*2,

A very good list, but fully automated from Barracuda devices' input;
I have tried using it for rejection and had some complaints about
blocking real mail.

>             zen.spamhaus.org*2,

This is the only one I'd trust fully.

>             psbl.surriel.com*2

Also mostly automated, with a removal tool provided to end users,
whether spammers or not.

I'd replace your config with:

>    postscreen_dnsbl_threshold = 2
>    postscreen_dnsbl_sites =
>             b.barracudacentral.org,
>             zen.spamhaus.org*2,
>             psbl.surriel.com
>    postscreen_dnsbl_action = enforce

This changes BRBL and PSBL to the default score of 1.  More spam
would get through postscreen this way, but it's unlikely that you
would need to do much whitelisting.

Note, I would not stop there; I'd go the rest of the way to my
postscreen sample config as can be found at the site in .sig.
Upgrade to at least Postfix 2.11 if you're not there yet.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen exceptions and blacklisting

Nikolaos Milas
On 8/9/2017 4:17 μμ, /dev/rob0 wrote:

> ...

Thanks a lot for your detailed and valuable advice! It helped me a lot
to understand things better!

I will surely work on my configuration based on your recommendations.

I think I'll start by using your initial recommended changes and see how
it goes.

Unfortunately, I have to work on many other areas so I don't have much
time for experimentation.

Cheers,
Nick