efa-project.org

Sorry, please disregard this and apologies for not updating sooner.
We found this issue with the postfix settings was caused by an error in our Linux OS hardening script. Not related to the eFA installer.

Does anyone have information on why eFA5 creates the postfix default mynetworks settings as:
mynetworks = 127.0.0.0/8 [::1]/128 hash:/etc/postfix/transport
And this is reset to this prepended string when you use eFA-Configure and add a relay; it becomes:
mynetworks = 127.0.0.0/8 [::1]/128 hash ...

The web GUI needs to be completely revamped, with an underlying PHP framework and a small mSQL/postgress database to hold the settings and functions that are in eFA-Configure cli menu.

After initial installation of eFa 5.0, Fail2ban reports not able to start.
This is simply due to the mailwatch jail log file not existing yet. Fail2ban does not work until the log file is created (automatically when a php-fpm error log is recorded) and the server rebooted or Fail2ban service started ...

This issue is not an issue. Fixed with an update of SSH keys and can access AWS LS/EC2 installations.
Would be nice if there was a cut-down installer or script option which assumes ipv4, ipv6 and shell user (and keys) are already set up outside of the eFa installation process.

We are setting up an experimental project with two linked/sync'd EFA 5.0 machines - one on-premise and the other in AWS. On premise works ok, but it seems the standard EFA setup causes issues with AWS SSH connectivity. Likely due to the creation of new login accounts and SSH keys. We also had the ...

The other related issue we are seeing is the server's /etc/hosts file keeps getting wiped and replaced with a default settings file, losing the few custom (but critical) host/IP entries we have.

We arent sure what has changed with eFA... Our stack of eFa 4.0 servers had been running completely ...

ok, i guess we could alter this line in /usr/sbin/eFa-Monitor-cron...

# Monitored Service Array (daemon=sysv)
MonitoredServices=("mysqld=mysqld" "MailScanner=mailscanner" "master=postfix" "httpd=httpd" "clamd=clamd@scan" "unbound=unbound" "dccifd=adcc" "MSMilter=msmilter")
to
# Monitored Service ...

Is there any way to reconfigure EFA to let us continue using NAMED DNS service instead of UNBOUND.

This needed because our gateways are also setup for REVERSE DNS lookups for our email sending systems.
Getting UNBOUND to work reliably for REVERSE DNS is a huge pain, and our NAMED setup has worked ...

Installing EFA on CentOS Stream 8 works perfectly.
and as long as you dont need/use the custom action - you really just need to copy over your rules and config files.

This isnt really a bug I guess... more of 'depricated' maybe?

The spam custom action (CustomAction.pm) no longer works in EFA 4.0. So no spam reporting link and no spam release notification email possible.

This might be a good thing - as it forced us to re-evaluate if these items are really needed ...

Its worth noting...

Out of the 5 LINUX distro/versions we tested (extensively), CentOS Stream 8 is the ONLY one which worked absolutely perfectly, first time without a SINGLE adjustment, fix, tweak or modification of any kind. We tested different concoctions of Debian, Ubuntu, CentOS7, and Stream.

It would be really helpful to remove the one small dot/period after "release 8." in the EFA 4.0 install script.
* CentOS stream reports the version and "release 8" with no decimal place after.

#remove the dots after release number, here:
# elif [[ $OSVERSION =~ .*'release 8.'.* ]]; then
#so you get ...

This makes it super difficult for debugging actions.

It seems the Spam "Actions" information does not show the actions taken for each particular message, but instead what actions are currently set.
If "Spam Actions" are set to "store-spam" then later changed to "deliver", all historical messages will show the current "Spam: Actions(s): deliver" as the ...

We cannot figure out why some messages show inbound, next hop relay/delivery information and some not. Even though all messages are delivered.

We have spent quite a bit of time trying to track down the common denominator, but nothing seems to fit. All messages external, to the same internal domain ...

After initially infuriated by the decision to eliminate Centos 8 and beyond (we manage 100s of Cento 6/7 servers) we have now come around to appreciate some really significant benefits to deploying CentOS Stream 8 distribution (upstream, between FEDORA and REDHAT).

One of the big improvements is ...

The easiest best solution to prevent spoofing in a standard, simple environment is ADD BLACKLIST from @yourdomain to @yourdomain. If you handle multiple domains, add a BLACKLIST entry for each combination which should NEVER pass through your external SMTP gateway.

Internally, all network equipment ...

We recently began running very heavy, pre-production testing of EFA4 and found lots of problems with the "custom(spam)" or "custom(nonspam)" custom perl action. In general, it seems CustomAction.pm really no longer works.

One of the effects of this is we can no longer send the "Mark as SPAM" link ...