• 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

SMTP, rblsmtpd issue

Gorlist

Basic Pleskian
Morning, since upgrading to latest plesk 8.4 from 8.3 we've been suffering from number of email problems, mostly just relay lock - but majority of its now resolved.

Yesterday visited a client to find the server is blocking outgoing emails from their Outlook Express.

rblsmtpd pid 26558, error 0x800CCC60 - spamhaus.org

Ive done some searching and found their ISP is listed on the PBL database, and according to the PBL website their solution is just make sure "SMTP Authentication" is enabled - unfortunately this doesn't seem to resolve the issue (as it was already enabled).

Some of the online advice is to use a whitelist, but from what I can see their appears to be some form of plesk/qmail/DNSBL problem?

Ive also got another client with outgoing issues which maybe similar (not yet checked).

Any advice would be most appreciated!
 
Until awaiting a fix I have had to turn off any DNS lookup of spamhaus.org on my server.

I have had no response to queries about this, and asked, over a week ago, the volume license holder (pipex/webfusion) to request immediate fixes from swsoft, to no avail.

I am dissapointed by 8.4.0 And even more dissapointed by the delay in getting out a fix, and a new update. I am upset as this is a commercial product so we expect better.

I can accept bugs and failed updates from time to time. But this was a major crunch. The almost silence and slow slow response from SWSOFT is upsetting. We could do with a progess report on this forum, and a listing of the problems they have found, so at least we know that they have heard about our plight and problems we are all having, and they are working on fixing them There does not seem any fixes for UBUNTU as yet.

It would be nice to know if they have any dates in mind to roll out a fixing update.
 
Gorlist -- I think there is an easy solution for your problem.

If you use an dnsrbl in Plesk that lists the IP of someone trying to connect to your server to send email then they will not be able to use your server for smtp on port 25. The dnsrbl will block their attempts. This is normal and expected behaviour in Plesk.

The instructions you read about using authenticated smtp to get around the problem do not apply to the default installation of Plesk (and other similar setups). The idea of the instructions you read is that by using authenticated smtp you will bypass the dnsrbl, and therefore will not be blocked. This does not happen with the default installation of Plesk so the instructions won't work (they are rather simplistic).

The solution in Plesk 8.4 is a simple one. Enable the "submission" option in Plesk, ask your customers to change to port 587 from port 25 in their email clients and require them to use smtp authentication (remember to open up your firewall for port 587 too). This basically creates a second smtp instance listening on port 587 instead of port 25, does not have any dnsrbl blocking and REQUIRES users to use smtp authentication in order to be able to use it. No spam will come via that port because a) server to server email transfer happens on port 25 and b) it requires authentication.

(A similar solution will work in earlier versions of Plesk but rather than ticking a box in the control panel to get it to happen you have to copy a single file and edit two lines in it, but it works just as well and basically does the same thing)

The other option you can go for is to install spamdyke (search the forum for step by step instructions) which does bypass all dnsrbls when smtp authentication takes place. Note that when you use spamdyke you will not be able to use pop-before-relay authentication, and that you set up dnsrbls within spamdyke's configuration files, not via Plesk. spamdyke does add a whole plethora of additional anti-spam measures, however, and it is well worth installing if you don't need pop-before-relay.

gerryb - it is possible what I've described will solve your problem too if you found the solution to your problem was to turn off the dnsrbl lookups. What I don't understand is why you might thing this is related to 8.4 since the Plesk dnsrbl blocking has always worked like this. This makes me wonder if I've misunderstood your problem (and maybe Gorlist's too?).

I know there have been other issues reported regarding using short names and authentication (serious Plesk bug, now fixed as I understand it) and what have you, and in Ubuntu an incompatibility with a newly released Ubuntu update (Not a Plesk bug but a problem that Parallels needs to work around if that Ubuntu update itself isn't at fault), but none of that has any relation to dnsrbls as far as I know.

Anyway, I hope some of this helps. If not, and if it is not a problem covered elsewhere in another topic on the forum, please provide more details and maybe someone will be able to help even if I can't.

Faris.
 
Hi Faris, thank you for the reply & workaround.

The only issue of concern is before going to 8.4 from 8.3, im sure one of the clients emails did send/function correctly, who now is blocked by the server (though I can't confirm) - unless his ISP has only just appeared on the spamhaus list.

I did some reading up on spamdyke but decided not to install it at the time as it might have of only just compounded the issue.

Interested in greeby's reply.

Thanks again.

Question: Ive enabled email submission, restarted qmail, but for the firewall does 587 only have to be open to accept incoming, or does it need to be forwarded to 25?
 
Hey Faris,is it okay to enable email submission and run spamdyke at the same time. Will port 25 still be available? I want to enable this too for clients that have ISP like Cox blocking port 25 and will like to use a different port for their email but i have spamdyke installed already,

Gorlist, the best thing you can do is install spamdyke. i did a while ago and i love it. it is great against spam without the hassles of RBL blocking for authenticated users.
 
Back
Top