After following the guide to Update the ISPConfig Perfect Server from Ubuntu 22.04 to Ubuntu 24.04 everything seemed to be working fine, until I noticed that I'm no longer receiving any e-mail. I can send e-mail successfully out from ISPConfig to external addresses, and can send mail to myself using my ISPConfig SMTP server, but when I try to send to ISPConfig from an outside address it bounces back as being rejected by my ISPConfig SMTP host with a message about the client host (mail sender) being blocked by zen.spamhaus.org: [my e-mail address] host [my ISPConfig host name] [my ISPConfig IP] SMTP error from remote mail server after RCPT TO:<[my e-mail address]>: 554 5.7.1 Service unavailable; Client host [IP address of SMTP sender] blocked using zen.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/[some cloudfare IP]/ Reporting-MTA: dns; [SMTP sender hostname] When I viewed the Mail Log in ISPConfig, I saw Milter errors which indicated that rspamd was no longer running. warning: connect to Milter service inet:localhost:11332: Connection refused Indede, the rspamd service was masked, so I revisited the procedure I followed some time ago when I migrated from amavis to rspamd. Now the rspamd service is running again, but unfortunately I continue to not receive any mail send from outside my own domain. I also see some NOQUEUE errors. How do I resolve these? 2026-02-17T08:43:54.134294+01:00 [myHostName] postfix/smtpd[509133]: NOQUEUE: reject: RCPT from mail-ed1-x532.google.com[2a00:1450:4864:20::532]: 554 5.7.1 Service unavailable; Client host [2a00:1450:4864:20::532] blocked using zen.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/141.101.104.39/; from=<[test sender]@gmail.com> to=<[my address on my ISPConfig host> proto=ESMTP helo=<mail-ed1-x532.google.com> Now when I test send from outside to ISPConfig I still don't see any new traffic on the rspamd GUI history console. The last entry there is from just prior to my Ubuntu 24 update.
Output of common-issues command: $ sudo wget -q -O htf-common-issues.php "http://gitplace.net/pixcept/ispconfig-tools/raw/stable/htf-common-issues.php" && php -q htf-common-issues.php [sudo] password for [me]: PHP Warning: fopen(./htf_report.txt): Failed to open stream: Permission denied in /home/[me]/htf-common-issues.php on line 34 PHP Fatal error: Uncaught TypeError: fclose(): Argument #1 ($stream) must be of type resource, false given in /home/[me]/htf-common-issues.php:35 Stack trace: #0 /home/[me]/htf-common-issues.php(35): fclose() #1 {main} thrown in /home/[me]/htf-common-issues.php on line 35
Please, I need urgent help. By upgrading I have totally screwed up my e-mail system and I have no idea how to get it working again. I'm missing important messages and it's my own fault, somehow.
In /var/mail/log I see errors such as the following: postfix/smtpd[507329]: fatal: proxymap service is not configured for table "mysql:/etc/postfix/mysql-verify_recipients.cf"
Have you customized your postfix configuration, and did you run an ISPConfig update with reconfigureservices = yes after the Ubuntu upgrade? And did you test if the email works now after you removed the spamhaus balcklist?
Btw, you got these errors because you did not run it as root, you must use: sudo -s to become root user and then run the script. But we do not need the script for your current issue, so you don't have to run it again.
I have not, to my knowledge, customized postfix. I did run the 'ispconfig_update.sh --force' command as instructed by the Ubuntu upgrade guide, and let the default reconfigure-services command proceed with the default 'yes'. Yes, mail does now appear to be received successfully. I don't know if the situation is truly permanently resolved, though.
Yes, the issue is resolved permanently by removing Spamhaus RBL. Spamhaus has been causing issues for quite a while, which's why ISPConfig does not set it anymore on new installations.
Thanks, I later found an older discussion about this, from 2022. Is it sensible, though, that this only, coincidentally, suddenly, became a problem this past Sunday morning, precisely when I updated from Ubuntu 22 to 24? That RBL entry has obviously been there quite some time. Since the messages were immediately and permanently rejected, I guess they're really gone, aren't they? They're not stored anywhere I could get at now?
Probably is coincidental, yes. One of the messages mentions that one of the Ip addresses is on an open resolver list. To ensure that your system is not an open DNS resolver, you should check that. Various sites on the internet provide open DNS resolver tests. Rejected messages are not stored on your system.
Man, what a horrible coincidence. I would suggest adding a step to clear the RBL entry to the Amavis–rspamd replacement guide so others might avoid this problem, i suspected as much. However, a couple of messages sent from gmail users have gradually arrived, late, over the past half-hour or so, so perhaps others will. I suspect that some will never arrive, though.
This is not related to Amavis vs. Rspamd, it's a Postfix RBL that is set in Amavisd and Rspamd setups, and not everyone has issues with it. So its more like when you have issues, remove it. And we do not set it anymore by default, as it causes support or users think ISPConfig is not working, while it's just Spamhaus, which blocks an IP. Yes, it depends on the sender if they retry it or not.
Do you think there's anything I could have configured better to be alerted to the fact that messages were being rejected? Of course, it's quite likely that lots of messages are legimately rejected, but obviously in this case I would sure like to have known about it.
There is not that much you can do. There are tools to scan the log for anomalies, but I guess you would get quite a few false positives when you want to scan for the number of email rejections and then determine if the number of rejections is an anomaly or just an incoming wave of spam emails.
We use some extensive monitoring for all our mail related services. I will not provide any hands-on guiding here as it is quiet custom and highly depends on the individual setup. We use a mix of the following tools to monitor things like ratelimited ips, log error for specific messages, outgoing mail count per server, incoming mail count per server, how many rejects/accepts/discards/defferes/add header/rewrite subjects, top receiving/sending domains/ips, top spammers by ip/domain, extensive postfix qeue monitoring, dovecot replicator... Our alerting is based on this as well. The tools we use include: Grafana, Clickhouse, Influx, Loki, Prometheus, node-exporter, custom scripts This monitors the postfix, dovecot and rspamd services as well as some smaller custom things
