efa-project.org

I'm getting same kind of error:

/etc/cron.daily/mailscanner:

gzip: /etc/MailScanner/phishing.safe.sites.conf.master.gz: not in gzip format

Same problem here. I think the upgrade for MariaDB 10.1 to 10.2 is a major upgrade and needs an uninstall of MariaDB 10.1...

I did it this way:

Create a script /etc/cron.weekly/postfix-cert-update.cron:
!/bin/bash

# Update the postfix certificates from Apache2
echo Updating Postfix SSL certificate from Apache website
echo Checking if Apache certificate is newer than Postfix certificate....
if [[ "$(cp -uv /etc ...

I had the same issue. I've fixed it with the following steps:

1. Into the file /var/spool/postfix/.razor/razor-agent.conf add the line
razorhome = /var/spool/postfix/.razor

2. Into the file /etc/MailScanner/spamassassin.conf add the following section
ifplugin Mail::SpamAssassin::Plugin ...

@hunter-nl: This solution works!

I still have this problem, while my EFA version is upgraded: "MailWatch for MailScanner v1.2.15 running on eFa-4.0.3 - © 2006-2020."

How can I remove this error? I tried Henk's steps, but it did not work.

I have an equal problem:
/etc/cron.hourly/0yum-hourly.cron:

Could not get metalink https://mirrors.fedoraproject.org/metal ... ent=centos error was
14: curl

I have the same error from the cron update job:
/etc/cron.daily/0yum-daily.cron:

Failed to check for updates with the following error message:
Failed to build transaction: 1:eFa-4.0.2-7.eFa.el7.x86_64 requires clamav-server >= 0.101.0-1

Yes, yes, after trying a lot of other things, this finally did help!
I also have a hyper-v iso.

Since the upgrade to 3.0.1.8, I get this error while updating de GEOIP databases:
Downloading file, please wait...
Error occurred while downloading GeoIP IPv4 data file: cURL error 7: Failed to connect to 2400:cb00:2048:1::6810:262f: Network is unreachable
Error occurred while downloading GeoIP IPv6 ...

I deleted the whole list and was playing with it. After some time I noticed that this is working:

172.16.0.6255.255.255.255
172.16.0.38
IP DOES NOT MATCH SUBNET
192.168.2.254 255.255.255.255
172.16.0.38
IP DOES NOT MATCH SUBNET
172.16.0.0 255.255.255.0
172.16.0.38
IP MATCHES SUBNET
192.168 ...

I have the same problem and run the script:

172.16.0.0 255.255.0.0
172.16.0.38
IP DOES NOT MATCH SUBNET

This looks like a bug: it should be trusted but it isn't!