Page 1 of 1
Posted: 20 Oct 2021 13:44
I've been running EFA 3 for a while now and I'm really happy with everything it does. I've been meaning to upgrade for a while, but things have been a bit chaotic over the past year (as you all probably know).
In the meantime, the unfortunate news about CentOS came to light, so I am a bit hesitant to stick with it for a purpose as important as e-mail filtering.
Has there been any progress on Debian/Ubuntu compatibility and is there an approximate release date? If it's not too much longer, I would much prefer to use that than a very soon to be EOL linux distro.
Posted: 21 Oct 2021 20:44
Yes, progress is being made. I am actively working on the debian build.
Posted: 14 Mar 2022 08:57
Hi! Any update/progress on the v5 Debian release?
Posted: 15 Mar 2022 02:10
Still ongoing. Status is still lots to do.
Posted: 21 Mar 2022 08:57
Hi, I´m also interested in the progress here. I have been using eFa for over 15 years (back when it was called ESVA). Today we run a cluster of somewhat modified version of eFa v4. We have dockerized eFa v4, and run a cluster of eFa services that all talk to a central MariaDB cluster. MailWatch is also a central component that talk to each eFa v4 docker container. We store and analyze all logs from eFa in an ELK stack. Currently we have 5 different virus scanners in each eFa container. In front of the eFa containers we have a HAProxy cluster which works very well. For simplicity, all eFa containers fetch their configuration from a private repo on GitHub every 10th minute. So whenever we change a rule it is propagated within 10 minutes which is fine for our needs (and we have the option of rollback of rules as GitHub provides revision control).
Running a CentOS based application in a docker container is a real pain. Even the startup services require kernel access, and it is a total mess to make things work. Don't get me wrong, it do work fine, and we have been running eFa for years in this docker environment (all on Ubuntu hosts). And it do scale easily by just adding more containers in the pool.
However, it's time to rewrite and make a new version of our docker image of eFa. And this time, I would like to abandon CentOS and move to Debian/Ubuntu. I would love to base this on your work, as I would hate to make a complete fork of v4 to port it to Ubuntu. Do you have a roadmap, or can I help in any way on the development?
Posted: 22 Mar 2022 15:19
Interested! I was almost going to switch to AlmaLinux 8 or RockyLinux 8, but if v5 is going to be Deb/Ub, I can wait
Posted: 03 Sep 2023 21:20
Jumpstarting this necro-thread.
Long story short, I'm working on a Debian 12 based build. It's a bit rough around the edges at the moment, but I'm just about ready to move it from the lab onto an external test server once I resolve a clamav issue.
There's no MailWatch yet, and it's also missing a bunch of the scanning options (only because I haven't got that far yet).
What is working though is most of the core stuff and security features like UFW integrated with fail2ban, spf, dkim, dmarc, MailScanner, Spamassassin... Like I said once I get the clamav bit working (it's throwing some errors and crashing) then I'll statr to be able to put it through its paces on the actual interwebs and see how it copes when I dump a couple of million emails on it from a load test server. just to see what happens
all in the name of science.
I'm doing this build for myself, but I'll be sharing it with Shawn once it's a bit more refined and I generalize it.
I'm interested in centralizing the MailWatch functionality for my own use, but might be useful for some of the larger users out there too.
I've also devised a kind of centralized configuration management system too - that's _really_ rough at the moment, but it means that DKIM keys and other config items are replicated across the farm of servers (push rather than pull based - because security I guess).
Posted: 04 Sep 2023 15:01
Posted: 07 Sep 2023 10:44
Posted: 15 Sep 2023 05:52
So... Where to start...
After a few false starts and some late nights I have what I think is a good foundation.
I tried and failed with MailScanner - I don't think the problem is with MailScanner itself, but a lack of stability in perl modules, and perhaps MailScanner has kind of been superseded as the "glue" that holds everything together.
Back in the day, MailScanner was absolutely essential to bring all the modules together, but now I'm not so convinced, because Postfix is now able to relatively cleanly pull all the modules together, and do it pretty efficiently too.
On initial connection, Postfix can make decisions pretty much immediately on whether the sending mailserver is worth having a conversation with - does it conform to proper standards like helo, checking pointer records, does the domain even exist?
Then of course services like greylisting plug directly into the MTA. Just these steps are going to drop a lot of the lazy spammers.
Checking SPF branches off the MTA early on, then back for the milters for dkim, dmarc, then spamassassin for the scoring if the message gets through the SPF, DKIM, DMARC challenge (remember these are all done BEFORE the message is queued). Spamassassin can check rules based allow/block lists (example DNSWL), and works directly with the likes of spamhaus DQS without the need for a recursive resolver (yay!). Obviously SpamAssassin is the major filter here, but it's also expensive in terms of CPU cycles etc, but by putting it behind all the cheaper filters, means it has less to do. The way things are with my system right now is that once a message passes spamassassin, it is then accepted into the mailqueue, where it gets picked up by clamsmtp. I prefer this approach rather than another milter in the chain, but after further testing I might revisit the milter approach. The great thing with the milters, is that if any one of them dies, Postfix will just bypass it and pass the message onto the next in the chain OR it will just drop the message depending on how you configure the default actions - there is nothing getting stuck in any queues (so actually nothing to monitor in that regard).
The way that Spamassassin works is that it just scores the messages. it has three possible actions: Pass (below the threshold), forward clearly marked as spam (I like this) and reject for high scoring spam - there is nothing to release from the server (which actually greatly simplifies things).
I would like to get some stats out of the system once I'm happy enough to put it into production - things like messages per domain, messages dropped, etc.. There are options out there for that but for now I'm focused on the functionality rather than how pretty it is.
The other thing that I've done is created a management layer. The filter boxes all work independently, but occasionally need config updates, etc, so I've built some scripts that will push the changes via rsync over ssh to them (example a new domain is added - a lot of stuff has to happen - DKIM keys need to be created and distributed (the filters verify inbound mail, but sign outbound mail), the transport tables need to be updated, spamassassin needs to be told to ignore outbound messages, opendkim needs to know which messages to sign (and not validate), etc. That's working well.
Is it as user-friendly as eFa yet? no, not yet, but it can be tamed.
Once I'm happy enough I'll send a copy to Shawn and he can have a look at it, roll his eyes at my terrible "code" and fix it.
I'm working on the basis that I don't want to have to pull in software etc from non-standard Debian repositories - and on Debian 12, that's actually working really well, so that's great.
Posted: 20 Nov 2023 15:06
I, too, am eagerly awaiting the release of eFa 5. Currently, I'm using eFa 4 on a VPS with CentOS 8.5. I've noticed that some have tried integrating additional antivirus scanning engines besides Clamd. I'm keen to learn which antivirus engines you've successfully integrated, particularly interested in one with sandboxing capabilities. I use Falcon Go as an EDR, but unfortunately, it's not compatible with MailScanner.