efa-project.org

Over the last 72 hours We have seen the MSMilter randomly stop working
gateway postfix/smtpd[20780]: NOQUEUE: milter-reject: EHLO from mail.mydomainnamehere.co.uk[x.x.x.x]: 451 4.7.1 Service unavailable - try again later; proto=SMTP helo=<mail.mydomainnamehere.co.uk>

I can't find anything in the logs.

What is the status of the MSMilter daemon when this occurs?

systemctl -l status msmilter
gives me

msmilter.service - LSB: MSMilter daemon
Loaded: loaded (/usr/lib/MailScanner/init/msmilter-init; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/msmilter.service.d
└─override.conf
Active: active (exited) since Thu 2021-01-21 14:50:49 GMT; 24h ago
Docs: man:systemd-sysv-generator(8)
Process: 26525 ExecStop=/usr/lib/MailScanner/init/msmilter-init stop (code=exited, status=0/SUCCESS)
Process: 26542 ExecStart=/usr/lib/MailScanner/init/msmilter-init start (code=exited, status=0/SUCCESS)
Main PID: 26549 (code=exited, status=0/SUCCESS)

However in mailwatch it shows

MSMilter: NO 0 children

So it seems to be running.

Do you see it on a port listening with netstat?

To get the system working at the weekend i have just disabled DKIM & DMARC.

It would appear to clamav thats the problem. Is there anyway we can remove it?

I just setup a new VM with RockyLinux 8.8 and efa-4.0.4 last night. I was seeing these same errors. Trying to figure out what milter was the culprit seemed more difficult than it should have been especially at 2 am.

I eventually figured out that the opendmarc.conf and opendkiim.conf were both set to only listen on a socket rather than on the inet:889x@localhost. After I corrected the config files, and restarted the opendmarc and opendkim services, it appears to work.

lambert wrote: 15 Jun 2023 17:51 I just setup a new VM with RockyLinux 8.8 and efa-4.0.4 last night. I was seeing these same errors. Trying to figure out what milter was the culprit seemed more difficult than it should have been especially at 2 am.

I eventually figured out that the opendmarc.conf and opendkiim.conf were both set to only listen on a socket rather than on the inet:889x@localhost. After I corrected the config files, and restarted the opendmarc and opendkim services, it appears to work.

I'm not alone then.

I just performed three clean installs on a minimal AlmaLinux 8 installation with exactly the same results each time as you described, and ultimately had to resort to exactly the same fix. Opendkim and opendmarc both appear to be configured for unix sockets by default, whereas EFA's configuration seems to be expecting TCP.

This is my first experience with the EFA.

Do you know whether it's generally regarded as being suitable for production environments?

EFA is a collection of mature software glued together into a pretty decent package for administrators. It's mature enough that the developers of EFA don't seem to spend much time on it anymore, because old installs just work. The "issues" tend to be packaging of the mature software being done differently in post-CentOS distributions.

I suspect there could be some EFA market share increase from Barracuda refugees in the last few weeks. I only had to re-install because I'm moving my in home VM servers and wanted an MX online while the servers are on the truck. I just wish the milter error logging said which milter was having an issue. EFA probably wants TCP sockets because it's handy if you happen to have functions running on different boxes.

Like all spam filtering software, you have to watch it to ensure that it doesn't do anything too surprising in your environment with your users. Obvious spam markers for some groups are just everyday parts of routine messages for other groups.

lambert wrote: 21 Jun 2023 01:03from Barracuda refugees in the last few weeks.

What's up with Barracuda? I've not been following them. Just curious.

pdwalker wrote: 21 Jun 2023 02:21 What's up with Barracuda? I've not been following them. Just curious.

A zero day exploit...

https://nvd.nist.gov/vuln/detail/CVE-2023-2868

...and some additional information...

https://www.bleepingcomputer.com/news/s ... -day-flaw/

I think they and their clients have survived it reasonably well though.

lambert wrote: 15 Jun 2023 17:51 I just setup a new VM with RockyLinux 8.8 and efa-4.0.4 last night. I was seeing these same errors. Trying to figure out what milter was the culprit seemed more difficult than it should have been especially at 2 am.

I eventually figured out that the opendmarc.conf and opendkiim.conf were both set to only listen on a socket rather than on the inet:889x@localhost. After I corrected the config files, and restarted the opendmarc and opendkim services, it appears to work.

Thank you. Not sure I would have ever figured this out without your post.

My thanks too. I had to set up a fresh install of 4.0.4 using the script on HW (non-VM) using Rocky 8.9 and hit this same issue. You'll also find it discussed in more detail here: https://github.com/trusteddomainproject ... issues/179