efa-project.org

Should be fixed now. One of the mirrors was way behind.

I believe this is the DKIM code in SpamAssassin that is the culprit here. I'd be curious how this compares to the Authentication-Results header in the same email. I'm betting that opendkim says it is passing and SpamAssassin is erroneously saying otherwise.

This definitely looks like a bug. The Received line should always look like this: Received: from out208-127.dm.aliyun.com (out208-127.dm.aliyun.com [140.205.208.127]) and never like this: Received: from out208-127.dm.aliyun.com (4S00JX0yDtz4x8Mx) The "4S00JX0yDtz4x8Mx" is a smtp queue ID. ...

I am deciding what to do. I have been away most of this year due to many things going on in my life.

I have an "eFa v5" built on CentOS 9 Stream, though. With some fixes I can get it out the door. This would get anyone interested an upgrade path for continued OS support.

I will work on getting things fixedup for CentOS 7 here. Apologies for the delay. I have had health issues.

I'm not exactly sure why this is failing. To troubleshoot, what I would do is manually carry out the restore tasks that can be found in /var/eFa/lib/eFa-Configure/func_systemrestore So, starting on line 60 when a backup is chosen it starts by cd in to /var/eFa/backup and then expands the tarball. Th...

Just out of curiosity, did you set up the replacement with eFa Init before restoring the backup?

It appears either the database isn't running or wasn't initialized, which means you may need to run through setting up the appliance, then run the restore over it so that the database is in a ready state.

Your problem is likely clamd. The /var/log/maillog would reveal what is going on.

You are also on v3, and I'm surprised it is still even functioning.

Fixed here:

https://github.com/MailScanner/v5/pull/614

I'll roll up a new release of MailScanner and pull into eFa, I have quite a few fixes pending.

The DMARC reports are controlled with cron jobs that you can optionally disable. /etc/cron.daily/eFa-Daily-DMARC is probably the one you want to examine. Comment the line mentioning /usr/sbin/opendmarc-reports

Glad to know you got it fixed!

eFa is not ready for v9 OSes yet. I have to do some work there.

Yeah this is a bug. The PeerList needs to be comma separated. You can work around it by using brackets for the IP portion and editing /etc/opendkim.conf to comma separate the entries. I'll prepare a fix.

Are you setting that in eFa-Configure? If so, I bet we have a bug here. Let me check into it.

Try enclosing the IPv6 address in square brackets.

Well, I received the test email. It shows the partialMessage.bin as expected in the MailWatch UI (no filename defined, just a MIME type). When I received the email, the .ics file was intact. I also released the email a second time, and compared the attachment mime part with a sha256 hash: e56de70afa...

Time is precious. I'll get back to this soon. Feel free to jump in and see what we are up against (it is a lot).

CentOS 8 is EOL; switching to CentOS 8 Stream is appropriate.

@shawn Until now we can repeatable create a Zoom (https://zoom.us/) invitation for a video meeting. When sending such an invitation via local outlook to an EFAv4 protected mail server, this email gets there but with a partial message inside EFAv4 but delivers correct to outlook as you wrote in your...

Well, this gives me something to work with. I'll sign up for Zoom and run some tests. I don't have an O365 tenant, but maybe we can start here and see what may be happening. Maybe something is triggering a reconstruction of the mime parts during normal delivery and causing it to be reinserted incorr...

I did see where someone mentioned that releasing the mail from the UI leaves it intact, maybe this would be a way to capture one? Release it and get me a a raw copy with headers?

If you want me to fix this, then I need a good sample of one intercepted prior to it being processed by the system so that I can isolate what is leading to this problem. Under normal conditions a partialMessage.bin should not show up as such on a client, even though it shows up in the appliance that...

partialMessage.bin is normal behavior for MIME parts with a mismatched size, which is all-to-common with PDF attachments. What is not normal is this getting passed along to the client. I'm accepting samples to troubleshoot this further.