efa-project.org

The problem here is not you but the remote party. Your server is merely finding the remote client in the rbl.

Looks like I need to fix that

custom(nonspam) overrides the Sign Clean Messages to add extra variables.

Do you have the following in MailScanner.conf

Sent you a PM

Please keep us posted. I would like to recreate the conditions that caused this crash to improve the system.

Very interested in this, any chance I can get a sample raw message with headers? This sounds like some kind of MIME parsing issue.

Is there any indication in the report that something is being blocked for some reason, like because a filename is too long?

If you can't reach port 25 on remote relays, something may be wrong networking-wise.

The problem can probably be troubleshooted with some networking tools such as ip, ping, traceroute, etc.

It sounds like things are dying on your box before the system crashes. How do your resources look? Any indication in the logs as to why?

This has my curiosity, going to try Turkish!

I hate my own code sometimes... :oops: Please download this copy and test and/or debug (DEBUG_MILTER can be set to true and restarted to get detailed logging to the maillog)... curl -sSL https://raw.githubusercontent.com/shawniverson/MailWatch/041722milter_relay/tools/Postfix_relay/mailwatch_milter_...

The milter_relay daemon is responsible for inserting into the table mtalog_ids. So if you aren't getting this information, this is where we need to focus. Restarting the milter_relay daemon causes it to rescan the maillog before following it live. So if it doesn't capture anything after restarting, ...

Try manually removing mariadb101u-devel and update again.

That is rather bizarre. That setting appears to be missing from your config?

Yeah that should be fine for now.

Hello,

You have a few options...

Switch to CentOS 8 Stream
Switch to Almalinux 8
Switch to RockyLinux 8

Sorry for the delay, I missed this one.

Are you able to set the dns using eFa-Configure for forwarding internally instead and leave resolv.conf pointing to 127.0.0.1 (unbound)? Is unbound running?

Thanks I need to push another MailWatch update, to get ESETS EFS to be recognized in the reports. I'll add this to my todo.

Still ongoing. Status is still lots to do.

Thanks, I'll get this corrected.

Report link is back in 4.0.4-32:

You will find the configuration options under 8) Spam Settings in eFa-Configure.

Options to control the report link:

1) Non Spam Settings
8) Trusted Networks
9) Inline Signature Rules

So, I would love to get my hands on a sample.

I also notice that this is occurring in the post scanning phase.

There's no reason for opendmarc to verify during this phase. We should add 127.0.0.1 and ::1 to ignore.hosts

What OS are your using?

This kind've sounds like another potential DoS attack on opendmarc. Is there any other details your can share? Is this a spam email that is causing this?