Search results

@MacGyver No that wouldn't be practical. You should disable SMTP_AUTH on port 25 and have your clients sending using the submission port 587. Then you can restrict sending to countries that you authorize: https://www.danami.com/clients/knowledgebase/242

@Hangover2 Yes we've optimized the journald log parser in the next version of Warden so log lookups are almost instant now reguardless of journald size :)

@Hangover2 Warden will detect if DCC is setup as a service and you will see it listed on the Warden dashboard under the services section. It should run way faster then just using the DCC binary.

@Hangover2 Also make sure that you are running DCC as a service and not just calling the binary. We have instructions here: https://docs.danami.com/warden/user-guide/antispam-plugins/dcc#enable-the-dcc-interface-daemon

@papahausa These are the only settings that you should be migrating across servers are policy settings, blacklists and whitelists. https://www.danami.com/clients/knowledgebase/247/-How-can-I-migrate-Warden-settings-from-one-server-to-another-.html Many settings are OS specific so you will...

@MacGyver You can hover your mouse over every setting in Juggernaut to get detailed information about what each setting does: https://www.danami.com/clients/knowledgebase/172/How-can-I-get-detailed-help-about-a-specific-setting.html Without "Drop incoming logging" enabled an IP address being...

@MacGyver You should always use the IPtables search on the dashboard or using the command line instead of trying to search the Logs -> IPTables logs: To search for an IP address csf --grep <ipaddress> It will tell you exactly what is being blocked and more importantly the reason why it was...

This is because dovecot 2.4 logs to a different format that doesn't match the old filter. As a temp fix you can replace the old filter with the latest dovecot filter from the fail2ban github repo. I've tested the new dovecot filter it and it works with dovecot 2.4...

You should also check for any customizations to the dovecot configs in /etc/dovecot/conf.d/ . Plesk 18.0.73 upgraded to dovecot 2.4 which uses an entirely different config format so any customizations would need to be updated to the new format...

Check the systemd-journal for errors with the command: journalctl -xeu dovecot.service If you see the error below then you have to update the Warden extension to the latest version: Fatal: Error in configuration file /etc/dovecot/conf.d/99-warden.conf line 9: Unknown section name The latest...

@Alexander Bien Make sure that you have updated to Plesk Obsidian 18.0.73 Update 2 as they should have fixes for that: From the Plesk changelog: Fixed the issue where, after updating to Plesk Obsidian 18.0.73, Thunderbird could not send or receive emails when “Encrypted Password” was selected...

I recommend that you tail your maillog and then do a send a receive with your email client and check for any errors: tail -f /var/log/maillog

Check and make sure that the dovecot service is running properly on the server with the command: systemctl status dovecot

@Geraldo V Vieira Plesk Obsidian 18.0.73 upgraded dovecot to version 2.4 which has an entirely different syntax from 2.3 so the old syntax will not work. You will have to update your configuration accordingly. https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html

We have released Juggernaut Firewall 5.02 with adds AlmaLinux 10 support: https://www.danami.com/clients/announcements/164/Juggernaut-Security-and-Firewall-5.02-Released.html

We have released Warden 5.03 which should fix any issues related to Plesk 18.0.73 with dovecot 2.4: https://www.danami.com/clients/announcements/165/Warden-Anti-spam-and-Virus-Protection-5.03-Released.html

@papahausa The team worked over the weekend to get everything fixed. It is in final testing and will be released in the next few days.

@danami Does this mean anything learnt by Warden in that time is also lost? Yes it would be lost. I recommend that you switch back to the default MySQL backend.

@lightingman2003 Looking at your screenshot it looks like you are using Redis as your Bayes back end (because it doesn't have token counts like the default MySQL back end). So when you reboot it clears anything stored in Redis because redis isn't set to persist...

@lightingman2003 Are you maybe using Redis as the Bayes back end? Remember that Redis is an in memory engine and would get cleared when Redis is rebooted (if you don't have Redis set to save to storage). If you aren't using Redis then I recommend opening a support ticket in our client area then...