• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Postfix configuration: reject_rbl_client

M

mirage

Guest
Hello -

postconf -n outputs among other things:

smtpd_client_restrictions = reject_rbl_client


In my maillog I constantly get this line:

warning: restriction reject_rbl_client requires domain name argument


I therefore have to believe that postfix is misconfigured and that a domain name providing the RBL would have to follow the reject_rbl_client parameter.

What is the correct way to fix this? I don't just wanna go into postfix configuration files and make the change myself if Plesk updates just nail right over it the next time around.

I realize it's not a critical error. But I don't link extraneous warnings in my logfiles if it can be fixed through proper configuration.

Any help?
 
In short, this is a small plesk bug.

This is related to settings -> mail server settings -> Switch on spam protection based on DNS blackhole lists.
Even if checkbox is off, plesk add this line "smtpd_client_restrictions = reject_rbl_client". If you have anything in rbl list,
this becomes "smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org" (if you're using this DNS blackhole) and warnings disappear.


You can safely remove this line from main.cf, but it will come back soon enough.
 
there is another small annoying bug, which I just noticed.
I'm using zen.spamhaus.org as DNS blackhole, but since some of our clients sometimes get blacklisted, my solution for main.cf was:
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org
I'm accepting mail from my clients even they get blacklisted.

Now the annoying thing about this plesk feature is, that if I change some settings, reject_rbl_clients becomes first:
smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, permit_mynetworks, permit_sasl_authenticated

And that is not a welcome feature.

To replicate bug. Turn on dns blackhole, turn off, turn on again.
 
Easy :)

Make a whitelist:

Then modify main.cf

smtpd_client_restrictions = check_client_access hash:/etc/postfix/whitelist, check_sender_access hash:/etc/postfix/check_backscatterer, check_sender_access hash:/etc/postfix/check_spamcannibal, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org

Dont forget to postmap /etc/postfix/whitelist and the check_backscatterer and check_spamcannibal files! makes the .db extensions for postfix

the whitelist file is simply names of the servers and IPs you want to whitelist

k2smtpout01-01.prod.mesa1.secureserver.net OK
10.0.0.1 OK


Once the whitelists matches OK all the other tests on smtpd_client_restrictions are bypassed :)

I also found out how to stop backscatter for good:

content of check_backscatterer:

<> reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org


and content of check_spamcannibal:

<> reject_rbl_client bl.spamcannibal.org
postmaster reject_rbl_client bl.spamcannibal.org
MAILER-DAEMON reject_rbl_client bl.spamcannibal.org


See only emails from <> , postmaster , or MAILER_DAEMON are processed. As all these filthy diseased spam servers that backscatter are listed, say good bye to all those fake bounce emails :) they get killed off like they deserve. But you dont have to worry about kicking off real emails as the sender has to match those 3 only. Also you get real bounces as well.

I had a ticket and I asked plesk to allow you to add custom commands into the RBL line, as the whitelist must be first.


But use discretion on the whitelist, dont go foolish and add heaps of servers as your just letting them through the RBL checks. Also it works, but never whitelist a email address like [email protected] and certainly not @hisdomain.com as spammers fake sender addresses so it just allows them in.

I really love postfix as being a standard one (not a parallels one) you can add all the hacks you like.

The main.cf file only gets overwritten if you make mailserver changes.

Enjoy!
 
Ok, to be picky about your setup you should add permit_sasl_authenticated (For example, one of your clients is using laptop and does a lot of traveling. He logs on from all around the country/world). You can't add enough addresses to whitelist them and there is no point. Just make sure your clients use sasl auth and there is almost no need for whitelist additional ip addresses (I add them in my_networks).

What will you do, if you get a call from your client complaining that he cannot send email? Whitelist some spamhole?

I suppose you check sasl_authenticated users in recipient_restrictions, but if clients ip address is blacklisted he won't get that far (his ip addressed gets verified earlier than his sasl auth and he gets denied).


Still, lets get to the point - which is plesk bug. Your wishlist about custom line is not necessary. Plesk respects the line, but it wants to add reject_rbl_client to the begining of the line, not the end as it should.
 
This only affects instalations which are using postfix as MTA.

This bug affects only if you are using rbl_lists and some of your clients are blacklisted.

If you are not using rbl_list this does not affects you at all.

If you are using them, your server is refusing mail from your own clients (usually they are traveling customers, using mobile connections, etc.)

If you are affected (people are complaining that they cannot send mail) - the fix is in this thread.
 
The main.cf file only gets overwritten if you make mailserver changes.

So it's definitely a good idea to keep a backup of it. While we may not be changing mailservers once a month, a Plesk-Upgrade (which happens automatically for me) can really throw a wrench in you configuration.'

As for the 'small' bug, I just hope that Parallels will pay attention to it and not define 'reject_rbl_client' if no domains are set or the spamfilter is off completely.

Overall - despite a lot of the negative vibes in these forums - I really like Plesk and what Parallels has done with in 9.x. My customers do as well.

Cheers,
-m
 
ok, my proble is the problem enonced in this post:

In my maillog I constantly get this line:

warning: restriction reject_rbl_client requires domain name argument


but mails to send don't sent...

what's the problem?
 
Spamming a forum wont help you much.
The answer is in log files. If you are that desperate, at least put some relevant maillog entries.
This is just a warning, it does not afffect mail deliveries.
 
Whereever the error show. maillog is the most current one. maillog.process the last one before that.
 
Feb 10 22:34:46 ks361518 postfix/smtpd[32297]: disconnect from unknown[209.85.132.189]
Feb 10 23:38:06 ks361518 postfix/anvil[31704]: statistics: max connection rate 1/60s for (smtp:65.191.222.37) at Feb 10 23:29:54
Feb 10 23:38:06 ks361518 postfix/anvil[31704]: statistics: max connection count 1 for (smtp:65.191.222.37) at Feb 10 23:29:54
Feb 10 23:38:06 ks361518 postfix/anvil[31704]: statistics: max cache size 2 at Feb 10 23:30:57
Feb 10 23:38:22 ks361518 pop3d-ssl: Connection, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 pop3d-ssl: LOGOUT, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 pop3d: Connection, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 pop3d: LOGOUT, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 imapd-ssl: Connection, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 imapd-ssl: 1234305502.717602 LOGOUT, ip=[127.0.0.1], rcvd=12, sent=310, maildir=/etc/rc.d/init.d
Feb 10 23:38:22 ks361518 imapd: Connection, ip=[127.0.0.1]
Feb 10 23:38:22 ks361518 imapd: 1234305502.722107 LOGOUT, ip=[127.0.0.1], rcvd=12, sent=308, maildir=/etc/rc.d/init.d
Feb 10 23:41:21 ks361518 postfix/smtpd[778]: connect from unknown[88.252.171.40]
Feb 10 23:41:23 ks361518 postfix/smtpd[789]: connect from unknown[127.0.0.1]
Feb 10 22:41:23 ks361518 postfix/smtpd[778]: NOQUEUE: client=unknown[88.252.171.40]
Feb 10 22:41:23 ks361518 postfix/smtpd[789]: EF7C113FC080: client=unknown[88.252.171.40]
Feb 10 23:41:23 ks361518 before-remote[787]: check handlers for addr: [email protected]
Feb 10 23:41:23 ks361518 before-remote[787]: check handlers for addr: [email protected]
Feb 10 23:41:23 ks361518 before-queue[783]: check handlers for addr: [email protected]
Feb 10 23:41:23 ks361518 before-queue[783]: check handlers for addr: [email protected]
Feb 10 23:41:24 ks361518 postfix/cleanup[790]: EF7C113FC080: message-id=<[email protected]>
Feb 10 23:41:24 ks361518 postfix/qmgr[13566]: EF7C113FC080: from=<[email protected]>, size=1173, nrcpt=1 (queue active)
Feb 10 22:41:24 ks361518 postfix/smtpd[789]: disconnect from unknown[127.0.0.1]
Feb 10 23:41:24 ks361518 postfix-local[792]: postfix-local: [email protected], [email protected], dirname=/var/qmail/mailnames
Feb 10 23:41:24 ks361518 postfix-local[792]: hook_dir = '/usr/local/psa/handlers/before-local'
Feb 10 23:41:24 ks361518 postfix-local[792]: recipient[3] = '[email protected]'
Feb 10 23:41:24 ks361518 postfix-local[792]: handlers dir = '/usr/local/psa/handlers/before-local/recipient/[email protected]'
Feb 10 23:41:24 ks361518 postfix-local[792]: found handlers entry = '/usr/local/psa/handlers/before-local/global/10-dd52-domainkeys-2jEq6X'
Feb 10 23:41:24 ks361518 postfix-local[792]: call_handlers: call executable = '/usr/local/psa/handlers/info/10-dd52-domainkeys-2jEq6X/executable'
Feb 10 23:41:24 ks361518 dk_check[796]: DK_STAT_NOSIG: No signature available in message
Feb 10 23:41:24 ks361518 postfix-local[792]: handlers_stderr: PASS
Feb 10 23:41:24 ks361518 postfix/pipe[791]: EF7C113FC080: to=<[email protected]>, relay=plesk_virtual, delay=1, delays=0.98/0.01/0/0.04, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Feb 10 23:41:24 ks361518 postfix/qmgr[13566]: EF7C113FC080: removed

maybe the mails are sent in the virtual device only and not out?
 
Ok, to be picky about your setup you should add permit_sasl_authenticated (For example, one of your clients is using laptop and does a lot of traveling. He logs on from all around the country/world). You can't add enough addresses to whitelist them and there is no point. Just make sure your clients use sasl auth and there is almost no need for whitelist additional ip addresses (I add them in my_networks).

What will you do, if you get a call from your client complaining that he cannot send email? Whitelist some spamhole?

I suppose you check sasl_authenticated users in recipient_restrictions, but if clients ip address is blacklisted he won't get that far (his ip addressed gets verified earlier than his sasl auth and he gets denied).


Still, lets get to the point - which is plesk bug. Your wishlist about custom line is not necessary. Plesk respects the line, but it wants to add reject_rbl_client to the begining of the line, not the end as it should.

Plesk butchers any custom commands you have already, it adds , in them (breaks them) and yes as you said puts them at the end.

I do check sasl_authenticated in recp restrictions, that is plesk standard.
 
I do check sasl_authenticated in recp restrictions, that is plesk standard.

As I was saying, if this setup works for you, that's good. But for me it breaks some things (well, quite a few plesk standard things annoy me and I had to change them to get a working system).

Most tinkering I've done was done with about postfix.
one minor thing with smtpd_recipients, as I was writing above, had manually change that. Hopefully plesk default settings will be adjusted with time. (reject_rbl with be appended and permit_mynetworks, permit_sasl_authenticated will be moved from recipient restrictions to sender restrictions -> they make a much better sense in that part).

another major thing with postfix is spam filtering. I complain from time to time about spam hooks. They are not working properly or I missed the fix. The problem is mail is processed, identified as spam and then spam hook is not working and mail still gets delivered:
===========================
Feb 3 05:42:24 servis spamd[3655]: spamd: identified spam (12.4/5.0) for [email protected]:110 in 2.6 seconds, 2250 bytes.
Feb 3 05:42:24 servis spamd[3655]: spamd: result: Y 12 -NS_FROM_RFC_BOGUSMX,RCVD_IN_FIVETEN,RDNS_NONE,STO X_REPLY_TYPE,TVD_FINGER_02,UNPARSEABLE_RELAY,URIBL _BLACK,URIBL_SBL scantime=2.6,size=2250,[email protected],uid=1 10,required_score=5.0,rhost=localhost,raddr=127.0. 0.1,rport=/tmp/spamd_full.sock,mid=<000d01c985b1$5dac7a60$6400a8c 0@dcornely>,autolearn=spam
Feb 3 05:42:24 servis spam_hook[5954]: spam_hook: STOP mail for [email protected]
Feb 3 05:42:24 servis postfix-local[5953]: Warning: Handlers stack does not work
Feb 3 05:42:24 servis postfix/pipe[5952]: 6F6B2D6C007A: to=<[email protected]>, relay=plesk_virtual, delay=7.7, delays=4.9/0.01/0/2.8, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
===========================

As a workaround I had to put one more spamfilter manually (as smtpd_proxy_filter) which takes care the most of the spam for now. But this default plesk behaviour all spam which would pass rbls would be delivered.
 
actual plesk(9.2.2) still have this annoying bug,
but there is a temporarily, but working solution for this problem:

1. activate smtp-auth in plesks mailserver-settings
2. clear the input-field and disable the dnsbl-feature in plesks mailserver-settings
3. save the settings

4. edit your main.cf manually and set your smtpd_client_restrictions like this:
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net
5. restart postfix (/etc/init.d/postfix restart)

6. never touch the settings for smtp-auth and dnsbl in plesks mailserver-settings!
other settings e.g. max. message size, virus-filter oder webmail-frontend have no effect for smtpd_client_restrictions in the main.cf file :)

...tested on several systems


Update: Check the Postfix-Config after each Plesk-Update! The Autoupdater sometimes overwrites these settings :-(
It seems that the Problem still exists in Plesk 9.3.0...
 
Last edited by a moderator:
Back
Top