Hi, 2 days ago I upgraded setup on Debian 9 to ISPConfig 3.2 from 3.1.15. There are issues appeared with e-mail. 1) Some e-mail can't be sent, client host [xx.yy.zz.cc] blocked using zen.spamhous.org. However, this is an error since this host belongs to hp.com. Morever, there are false triggers of this feature, I can't send e-mails between 2 account of my own server. How to disable this feature? Is it NOT enough to turn off "System -> Server config -> Mail -> Real-time Blackhole List", I still can't send e-mails between my 2 own account on same server, client host blocked using zen.spamhous.org 2) Some Apple Mail clients don't fetch new e-mail from server at random. We have company e-mails on iPhone and desktop, and while new e-mails are seen on server and iPhone, they don't fetched by Apple Mail. All Apple Mail desktops use pop3. Previously everything was fine. 3) Few macOS desktop clients can't connect to pop/smtp server at all with no meaningful error message. Cleared Apple Mail cache, all same.
1: You can remove the RBL under System -> Server config -> server1.example.com -> Mail -> Real-time Blackhole List 2: Did you change the default dovecot config and are those changes overwritten? Is there still a valid certificate for the domain they use? I saw issues in the past with Apple Mail when a server went from a valid to a invalid certificate. 3: My answer to 2 applies here aswell. If that doesn't fix it, please read this aswell: https://www.howtoforge.com/community/threads/please-read-before-posting.58408/
Thanks for quick reply ! 1) I have removed Real-time Blackhole List, problem remain. 2) I did not changed dovecot config manually, everything was done automatically by ISPConfig script. 3) We use self-signed certificate all the time for many years.
Alright, please go through https://www.howtoforge.com/community/threads/please-read-before-posting.58408/ Share the output of the test script here if you can't find a solution in the FAQs there.
OK, I found solution for this problem - new e-mails NOT downloaded from server. Go to "~/Library/Mail/vXX/MailData" and delete all files containing "MessageUidsAlreadyDownloaded***", where Vxx - your Apple mail version. After this new e-mails appear in your mailbox. Hope this helps someone else, too.
htf_report.txt attached. Server is on DMZ 192.168.xx.xx with port forwarding on router/firewall (same setup as before upgrade).
Unchecked -> RBL under System -> Server config -> server1.example.com -> Mail -> Real-time Blackhole List, see screenshot. Still getting: Oct 19 11:53:56 mail postfix/smtpd[22425]: NOQUEUE: reject: RCPT from unknown[213.226.141.252]: 554 5.7.1 Service unavailable; Client host [213.226.141.252] blocked using zen.spamhaus.org; https://www.spamhaus.org/query/ip/213.226.141.252 / https://www.spamhaus.org/sbl/query/SBLCSS; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<[10.xx.xx.xx]>". 213.226.141.252 is an IP for mobile clients from our GSM operator. I did resync, restarted postfix/dovecot still same nasty issue, staff can't send e-mails from mobile phones. PS. I think for whatever reason ISPConfig have not removed link to spamhaus.
This means the external server is blocking your emails. So this would be a outgoing email. Issue 3: Can you check that your IP is not listed by Fail2Ban for the jail dovecot: Code: fail2ban-client status dovecot
fail2ban-client status dovecot do not lists this IP As I mentioned, resolved problem with spamhaus RBL, edited /etc/postfix.main.cf and removed reject_rbl option.
Anyone can own ip addrs that end up on spam blacklists; you could look up more info with spamhaus to see why it was listed. You're probably sending on the wrong port (25). The location where the rbl check is performed changed in 3.2, it is now in smtpd_client_restrictions, and applies to port 25 connections; ports 465 and 587 override smtpd_client_restrictions in /etc/postfix/master.cf (you might consult a perfect server guide and verify that yours is set correctly). Also if needed for external (non-submission) smtp clients, you can add an entry in Email > Postfix Whitelist using type Client to bypass the rbl check. Might be ssl/tls related? Eg. are these quite old clients? Do you still have any of these failing clients? If so, is MessageUidsAlreadyDownloaded a binary file or text? I wonder what your UID's used to be vs. what you see now. I still have a 3.1 box, and it has `pop3_uidl_format = %08Xu%08Xv` in dovecot.conf, which is the same as my 3.2 boxes. You said you didn't have any custom dovecot config, so... not sure what's going on here. If that setting isn't being changed, and you don't have it set in your own postfix template (in conf-custom/install/), something is amiss; you might enable debug mode in your server, add something to the rbl list and save it, then run server.sh manually to see what shows up.
OK, problems solved, here is a short summary. 1) Some e-mail can't be sent, client host [xx.yy.zz.cc] blocked using zen.spamhous.org. MANUALLY edit /etc/postfix.main.cf and remove reject_rbl option, and restart Postfix. 2) Some Apple Mail clients don't fetch new e-mail from server at random. Go to Apple Mail data folder "~/Library/Mail/vXX/MailData" and delete all files containing "MessageUidsAlreadyDownloaded ***", where Vxx - your Apple mail version. After this new e-mails appear in your mailbox. I don't know if these files are binary or text, just trash them. 3) Few macOS desktop clients can't connect to pop/smtp server at all with no meaningful error message. Copy all messages from "Inbox -> your mail account" + "Sent -> your mail account" to another folders, then delete account. If you don't copy messages as I described here they will be wiped out forever. Then add e-mail account(s) in preferences.
Code: smtpd_sender_restrictions = {reject_aslm} check_sender_access regexp:{config_dir}/tag_as_originating.re, permit_mynetworks{reject_slm}, permit_sasl_authenticated, reject_non_fqdn_sender, check_sender_access regexp:{config_dir}/tag_as_foreign.re, check_sender_access proxy:mysql:{config_dir}/mysql-virtual_sender.cf smtpd_client_restrictions = check_client_access proxy:mysql:{config_dir}/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks{rbl_list}, permit_sasl_authenticated, reject_unauth_pipelining {reject_unknown_client_hostname}, permit i think, the smtpd_client_restrictions you should be changed so they match smtpd_sender_restrictions. i.e. move permit_sasl_authenticated in front of permit_mynetworks{rbl_list}
