Postfix Access File Syntax?

l008com

l008com

I use my Postfix Access file to block certain hosts from accessing my mail server. Typically spam comes from semi random IPs but sometimes, particularly in russia, a spammer will flood me using random IPs from all the ranges the data center owns. Way too many to block individually.

So the Access file uses a format I've never seen used before. If you wanted to block 10.11.12.1 through 10.11.12.255, you'd just do:
10.11.12 REJECT Spamming host blocked

That works fine enough. But some of these data centers have huge ranges, and multiple different independent ranges. My access file was getting very long, and would have doubled in size adding the latest russian data center.

So I went through and added teh new data center using CIDR formatting. And I converted all my old rules to that formatting too. Now instead of having 200 lines of rules, I have 13 lines. Which probably makes no difference for the software itself but it makes a big difference for the human eyes trying to read the file.
10.11.12.0/24 REJECT Spamming host blocked

But here's the problem. It's not working. I'm still getting messages coming from IPs in the blocked ranges. So I had two thoughts:
Do you have to do something specific to enabled CIDR syntax in Postfix files? The docs are kind of unclear but it looked like it was supported?
Or is there a bug in the way CIDR syntax is read? This came to mind because I do seem to be getting LESS spam from these hosts, and the IPs that I'm still getting spam through are similar, as if the rules are not being interpreted right? (or maybe my formatting is wrong?)

Here is an actual rule:
94.139.240.0/22 REJECT IT-GRAD Network is a SPAM source

Which from my understanding is supposed to block 94.139.240.1 through 94.139.243.255. Yet I still get spams from the 94.139.242.x range.

Weird right?

Also, I am not married to CIDR at all. Is there some other way to notate ranges of IPs of varying sizes in single lines?
 
Why don't you block those IP addresses/ranges on the firewall? My firewall has whole blocks of known "bad" providers.

I use Exim and have sshguard(8) setup to block all the bruteforces. Exim itself has a link with spamassasin, certain addresses that are on blacklists get blocked at the HELO stage. Don't even allow them to submit something, they get killed immediately.
 
It depends on how you linked in the block file, I think?

ie
Code: 
check_client_access cidr:/blockfile
vs
Code: 
check_client_access hash:/blockfile
operate differently.

How do you have it configured? If you look at


and just search around for CIDR you'll find this

"Note 3: CIDR ranges cannot be specified in hash tables. Use cidr tables if CIDR ranges are used."
 
Ok so here's what I have in my postfix main.cf file:

smtpd_recipient_restrictions=check_recipient_access hash:/usr/local/cutedge/postfix/etc/access,
check_sender_access hash:/usr/local/cutedge/postfix/etc/access,
check_client_access hash:/usr/local/cutedge/postfix/etc/access,
permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

smtpd_client_restrictions=check_client_access hash:/usr/local/cutedge/postfix/etc/access,
permit_sasl_authenticated,reject_rbl_client sbl.spamhaus.org,reject_rbl_client xbl.spamhaus.org,reject_rbl_client bl.spamcop.net,reject_rbl_client psbl.surriel.com,reject_rbl_client b.barracudacentral.org
Click to expand...

So can I specify BOTH a hash:/etc/access and a cidr:/etc/access_cidr in all of the things that are referencing that same access file? So I can block the specific host and all the big ranges? If so, what is the exact syntax do to that? do I just double define the parameters? Like this for example? Or is there a different way:

smtpd_recipient_restrictions=check_recipient_access hash:/usr/local/cutedge/postfix/etc/access,
check_recipient_access cidr:/usr/local/cutedge/postfix/etc/access_cidr,
check_sender_access hash:/usr/local/cutedge/postfix/etc/access,
check_sender_access cidr:/usr/local/cutedge/postfix/etc/access_cidr,
check_client_access hash:/usr/local/cutedge/postfix/etc/access,
check_client_access cidr:/usr/local/cutedge/postfix/etc/access_cidr,
permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Click to expand...
 
l008com said:
Here is an actual rule:
94.139.240.0/22 REJECT IT-GRAD Network is a SPAM source

Which from my understanding is supposed to block 94.139.240.1 through 94.139.243.255. Yet I still get spams from the 94.139.242.x range.

Weird right?
Click to expand...

Check which database formats you can use with your postfix's version with postconf -m.
CIDR table support was introduced with Postfix version 2.1

As a side note, any pcre, texthash, cidr and regexp tables are entirely loaded on memory at postfix startup. If you apply any changes to such table and want to enforce them, issue a postfix reload.

l008com said:
So can I specify BOTH a hash:/etc/access and a cidr:/etc/access_cidr in all of the things that are referencing that same access file? So I can block the specific host and all the big ranges? If so, what is the exact syntax do to that? do I just double define the parameters? Like this for example? Or is there a different way:
Click to expand...

Yes. As /usr/local/cutedge/postfix/etc/access_cidr is a different file in postfix's view, excepting its formatted as a CIDR notation but it's rather cumbersome at best because you can too define an access rule for a single host in a CIDR access map.

After making change to a table, you can use postmap(1) to check if the access rule is effective or not.
 
Yup cidr IS in the list.

So to be clear, you're saying YES ad in, yes I can define the same attribute twice to "double up" on the rules?

check_recipient_access hash:/usr/local/cutedge/postfix/etc/access, check_recipient_access cidr:/usr/local/cutedge/postfix/etc/access_cidr
Click to expand...

^ that should work, even though I'm defining check_recipient_access twice? I just want to be doubley sure I'm doing the right thing here. If this works, then that should make is super easy for me to block problem ISPs that are usually in russia.
 
You must log in or register to reply here.
Back
Top