MDaemon Technologies, Ltd.

Aleksandar

1/3/24, 3:50 AM

Happy Holidays everyone

I was wondering if it would be possible to implement AV exclusions based on file name/type, something like "Password Protected File Exclusions"?
Or this can be done now but I just don't know how?

Not sure, but I think something like that existed a while ago, in the times MDaemon Security had Kaspersky AV engine.
In any case, CfExcludes.dat contains [RESTRICTED_EXCLUDES] section, but manually entering file type (and changing/reverting/saving any of the AV parameters so this change would be accepted) doesn't work. Filetype I want to exclude is already added to CF, Attachments, Exclusions but AV (Ikarus, namely) is quarantining them anyway.

Also, I tried looking around in MDaemon\SecurityPlus\Ikarus folder for possible exclusion file, no luck. Maybe editing scanserver.json could resolve this particular situation but I was unable to find anything regarding its syntax on the Net. But in any case, MDaemon level exclusions list, regulating both Ikarus and ClamAV would be a better solution.

Regards

24
Posts

451
Views

A

Arron Staff

1/3/24, 7:31 AM

Happy Holidays!

The only way I can think of to exclude all files of a specific type from AV scanning would be to manually implement rules in the content fitler to handle the routing of messages based on AV scanning results. This gets very complicated very quickly though.

What does the \MDaemon\SecurityPlus\Ikarus\scan.server\log\scan\ScanServer.log file show is happening when IKARUS scans the file?

Can you provide a sample email that IKARUS is quarantining so that we can test it?

A

Aleksandar

1/3/24, 8:47 AM

Hello @Arron

This is something i already asked about here, XLSM attachments
I have 3 internal users with their couple of external contacts exchanging emails containing specific XLSMs. I've put external people in (email address) AV exclusions, both FROM and BOUND For lists (my logic was, these are all corporate users, behind Exchange Online Protection, emails from them should be safe), so they are not the problem. 3 internal users use these XLSM forms, reply to these external people, but also have each other on cc as well.
So when one of them emails message like that, copy for external recipient(s) goes no problem, but internal emails end up in quarantine and sender's copy simply vanishes, no trace in Sent Items (as I've already reported here)

>What does the \MDaemon\SecurityPlus\Ikarus\scan.server\log\scan\ScanServer.log file show
[03.01.2024 15:04:47][2B20] {"crc64":6029448166492061129,"filetype":1817,"filetype_name":"E-Mail","status":"pseudosig","infected_item":"e:\\mdaemon\\queues\\temp\\md5001000044887.wrk==>TEST.xlsm","sigid":103,"signame":"macro autoopen found","num_items":11,"time":174,"input":"e:\\mdaemon\\queues\\temp\\md5001000044887.wrk","client":"127.0.0.1"}

> Can you provide a sample email
Sure. I just don't want to post it here. Can we do that off the Forum?

This is not a false alarm type situation. File has active macros. Sometimes these emails get stuck in Hosted Security Gateway quarantine although above mentioned external users are also AV exempt there. But if I could, for example, exclude Specific_name_*.xlsm I could force them to use that naming convention and resolve this issue.

Thank you

A

Arron Staff

1/3/24, 10:42 AM

sender's copy simply vanishes, no trace in Sent Items (as I've already reported here)

Looking back at our previous discussion, the message is not vanishing. It is being detected by AV engines when the message is uploaded to the server. Based on your previous request, we have updated the IMAP server to honor IP exclusions from AV scanning. Make sure you are running MDaemon 23.5.1 for this to work. If you are still having issues with the messages being removed from sent items, check the quarantine on the server. The messages may be getting detected by the Mailbox Scanning.

I just don't want to post it here. Can we do that off the Forum?

Now that I know what is happening, I won't need the sample email.

One option is to turn off macro detection entirely. As mentioned previously, AV engines should detect malicious office documents whether they have macros or not, so blocking all office documents with macros is an extra layer of protection, but if you need macros in office documents, then turning off macro detection might be the best option. We also discussed how to turn off macro detection in ClamAV, but I don't see a mention of how to do the same in IKARUS. To turn off macro detection in IKARUS, edit the C:\MDaemon\SecurityPlus\Ikarus\scan.server\conf\scanserver.json file and change:

"autoopen_macros": true,

to

"autoopen_macros": false,

Save the file and then restart the scanserver service.

Another option would be to password protect the files. If the files are password protected, you can configure exclusions based on sender or recipient and filename.

We have an item on our wishlist to allow more flexibility for the AV exclusions. It will be considered for future versions.

A

Aleksandar

1/3/24, 12:57 PM

the message is not vanishing

I meant, from the user standpoint.
We are running MDaemon 23.5.1 and the issue is still happening

Another option would be to password protect the files.

I don't like the idea of turning off macro detection completely. So I tried the passsword protection suggestion.
In 'Password Protected File Exclusions', I've added individual senders and recipients with *.xlsm file name. Then I tried with *-xlsm in 'Exclude these files'. These can be combined, right? I can exclude only certain users for certain type of password protected files and/or exclude some file types for everyone?
Whichever combination I try I get the same result:
Wed 2024-01-03 19:24:36.069: ----------
Wed 2024-01-03 19:25:41.864: MDaemon AntiVirus processing e:\mdaemon\queues\local\md3501001380701.msg...
Wed 2024-01-03 19:25:41.864: * Message return-path: prvs=1732ccf413=aleksandar.devecerski@wbm.rs
Wed 2024-01-03 19:25:41.864: * Message from: aleksandar.devecerski@wbm.rs
Wed 2024-01-03 19:25:41.864: * Message to: administrator@wbm.rs
Wed 2024-01-03 19:25:41.864: * Message subject: XLSM Test 6
Wed 2024-01-03 19:25:41.864: * Message ID: <b55f283b-1e35-4649-a8cc-df2ddf30917d@wbm.rs>
Wed 2024-01-03 19:25:41.864: Start MDaemon AntiVirus results
Wed 2024-01-03 19:25:42.078: * IKARUS AV: infected macro autoopen found (0.132 s) TEST.xlsm (E:\MDaemon\CFilter\TEMP\872820470\pd73631021.att)
Wed 2024-01-03 19:25:46.324: * ClamAV: clean (4.247 s) TEST.xlsm (E:\MDaemon\CFilter\TEMP\872820470\pd73631021.att)
Wed 2024-01-03 19:25:46.324: * (IKARUS AV) TEST.xlsm is infected by macro autoopen found
Wed 2024-01-03 19:25:46.324: * Total attachments scanned : 3 (including multipart/alternatives and message body)
Wed 2024-01-03 19:25:46.324: * Total attachments infected : 1
Wed 2024-01-03 19:25:46.324: * Total attachments disinfected: 0
Wed 2024-01-03 19:25:46.324: * Total errors while scanning : 0
Wed 2024-01-03 19:25:46.352: * Message moved to e:\mdaemon\cfilter\quarant\md5001000002166.msg
Wed 2024-01-03 19:25:46.355: * Virus notification sent to aleksandar.devecerski@wbm.rs (sender)
Wed 2024-01-03 19:25:46.359: * Virus notification sent to administrator@wbm.rs (recipient)
Wed 2024-01-03 19:25:46.362: * Virus notification sent to postmaster@wbm.rs (admin)
Wed 2024-01-03 19:25:46.362: End of MDaemon AntiVirus results
Wed 2024-01-03 19:25:46.362: ----------

In the end I tried "autoopen_macros": false,
This is working as expected.

A

Arron Staff

1/3/24, 2:48 PM

We are running MDaemon 23.5.1 and the issue is still happening

Do you have the option enabled to exclude trusted IP addresses from AV scanning? And is the IP the connection is coming from listed as a trusted IP address?

What does the IMAP log show is happening?

I don't like the idea of turning off macro detection completely. So I tried the passsword protection suggestion.
In 'Password Protected File Exclusions',

The log is not indicating that the attachments are password protected. In order for the password protection option to work, the files cannot be allowed to be opened unless the password is provided.

If the files are read protected by the password and you are still having issues, please send me a copy of the file so that I can test with it. You can upload the file to https://mdaemon.sharefile.com/r-r77d4332c21ab4a28afe9e84ea94e2f3c, just let me know once the upload is complete.

A

Aleksandar

1/4/24, 3:12 AM

Do you have the option enabled to exclude trusted IP addresses from AV scanning? And is the IP the connection is coming from listed as a trusted IP address?
What does the IMAP log show is happening?

Both
- 192.168.1.227 (work IP address, client Outlook using Connector) and
- 93.93.192.81 (home IP address, client Thunderbird using IMAP)
are in Trusted IPs.

and

Connector log:
Thu 2024-01-04 09:14:57.082: ---------- End partial transcript.
Thu 2024-01-04 09:15:07.948: [06163506] Session 06163506; child 0056
Thu 2024-01-04 09:15:07.948: [06163506] Accepting IMAP connection from 192.168.1.227:50831 to 192.168.1.19:143
Thu 2024-01-04 09:15:07.950: [06163506] --> * OK mail.wbm.rs IMAP4rev1 ready
Thu 2024-01-04 09:15:07.951: [06163506] <-- 00000000 CAPABILITY
Thu 2024-01-04 09:15:07.951: [06163506] --> * CAPABILITY IMAP4rev1 NAMESPACE IDLE STARTTLS LOGINDISABLED COMPRESS=DEFLATE ACL UNSELECT UIDPLUS QUOTA BINARY XLIST SASL-IR
Thu 2024-01-04 09:15:07.951: [06163506] --> 00000000 OK CAPABILITY completed
Thu 2024-01-04 09:15:07.952: [06163506] <-- 00000001 STARTTLS
Thu 2024-01-04 09:15:07.952: [06163506] --> 00000001 OK Begin TLS negotiation
Thu 2024-01-04 09:15:07.968: [06163506] SSL negotiation successful (TLS 1.2, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
Thu 2024-01-04 09:15:07.975: [06163506] <-- 00000002 CAPABILITY
Thu 2024-01-04 09:15:07.975: [06163506] --> * CAPABILITY IMAP4rev1 NAMESPACE AUTH=LOGIN AUTH=PLAIN IDLE COMPRESS=DEFLATE ACL UNSELECT UIDPLUS QUOTA BINARY XLIST SASL-IR
Thu 2024-01-04 09:15:07.975: [06163506] --> 00000002 OK CAPABILITY completed
Thu 2024-01-04 09:15:08.029: [06163506] <-- 00000003 AUTHENTICATE PLAIN ******
Thu 2024-01-04 09:15:08.029: [06163506] Authenticating deva@wbm.rs...
Thu 2024-01-04 09:15:08.076: [06163506] Authenticated as deva@wbm.rs
Thu 2024-01-04 09:15:08.084: [06163506] --> 00000003 OK AUTHENTICATE completed
Thu 2024-01-04 09:15:08.085: [06163506] <-- 00000004 CAPABILITY
Thu 2024-01-04 09:15:08.085: [06163506] --> * CAPABILITY IMAP4rev1 NAMESPACE AUTH=LOGIN AUTH=PLAIN IDLE COMPRESS=DEFLATE ACL UNSELECT UIDPLUS QUOTA BINARY XLIST SASL-IR
Thu 2024-01-04 09:15:08.085: [06163506] --> 00000004 OK CAPABILITY completed
Thu 2024-01-04 09:15:08.085: [06163506] <-- 00000005 X-GWINIT 7.0.7
Thu 2024-01-04 09:15:08.086: [06163506] --> 00000005 OK "7.0.7"
Thu 2024-01-04 09:15:08.086: [06163506] <-- 00000006 COMPRESS DEFLATE
Thu 2024-01-04 09:15:08.087: [06163506] --> 00000006 OK DEFLATE active
Thu 2024-01-04 09:15:08.087: [06163506] <-- 00000007 NAMESPACE
Thu 2024-01-04 09:15:08.087: [06163506] --> * NAMESPACE (("" "/")) (("~" "/")) (("#" "/"))
Thu 2024-01-04 09:15:08.087: [06163506] --> 00000007 OK NAMESPACE completed
Thu 2024-01-04 09:15:08.088: [06163506] <-- 00000008 GETQUOTA ""
Thu 2024-01-04 09:15:08.089: [06163506] --> * QUOTA "" (STORAGE 1038943 31457280)
Thu 2024-01-04 09:15:08.089: [06163506] --> 00000008 OK GETQUOTA completed
Thu 2024-01-04 09:15:08.090: [06163506] <-- 00000009 MYRIGHTS "Sent Items"
Thu 2024-01-04 09:15:08.091: [06163506] --> * MYRIGHTS "Sent Items" lrswipcda
Thu 2024-01-04 09:15:08.091: [06163506] --> 00000009 OK MYRIGHTS completed
Thu 2024-01-04 09:15:08.102: [06163506] <-- 0000000a APPEND "Sent Items" (\Seen) " 4-Jan-2024 09:15:00 +0100" {1017900}
Thu 2024-01-04 09:15:08.105: [06163506] --> + Ready for append literal
Thu 2024-01-04 09:15:08.172: [06163506] Passing message through AntiVirus (Size: 1017900)...
Thu 2024-01-04 09:15:09.241: [06163506] * Recipient, sender or IP in exclusion list
Thu 2024-01-04 09:15:09.241: [06163506] ---- End AntiVirus results
Thu 2024-01-04 09:15:09.246: [06163506] --> 0000000a NO Could not append message
Thu 2024-01-04 09:15:09.249: [06163506] <-- 0000000b LOGOUT
Thu 2024-01-04 09:15:09.249: [06163506] --> * BYE IMAP engine signing off (no errors)
Thu 2024-01-04 09:15:09.249: [06163506] --> 0000000b OK LOGOUT completed
Thu 2024-01-04 09:15:09.250: [06163506] IMAP session complete, (Bytes in/out: 725567/5501)
Thu 2024-01-04 09:15:09.250: ----------

IMAP log:
Thu 2024-01-04 09:22:44.013: --------- Partial transcript, remainder will follow.
Thu 2024-01-04 09:18:38.373: [06163524] Session 06163524; child 0063
Thu 2024-01-04 09:18:38.373: [06163524] Accepting IMAP connection from 93.93.192.81:63335 to 192.168.1.19:993
Thu 2024-01-04 09:18:38.396: [06163524] SSL negotiation successful (TLS 1.2, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256)
Thu 2024-01-04 09:18:38.396: [06163524] --> * OK mail.wbm.rs IMAP4rev1 ready
Thu 2024-01-04 09:18:38.429: [06163524] <-- 85 capability
Thu 2024-01-04 09:18:38.429: [06163524] --> * CAPABILITY IMAP4rev1 NAMESPACE AUTH=LOGIN AUTH=PLAIN IDLE COMPRESS=DEFLATE ACL UNSELECT UIDPLUS QUOTA BINARY XLIST SASL-IR
Thu 2024-01-04 09:18:38.429: [06163524] --> 85 OK CAPABILITY completed
Thu 2024-01-04 09:18:38.437: [06163524] <-- 86 authenticate PLAIN
Thu 2024-01-04 09:18:38.437: [06163524] --> +
Thu 2024-01-04 09:18:38.445: [06163524] <-- ******
Thu 2024-01-04 09:18:38.445: [06163524] Authenticating deva@wbm.rs...
Thu 2024-01-04 09:18:38.493: [06163524] Authenticated as deva@wbm.rs
Thu 2024-01-04 09:18:38.498: [06163524] --> 86 OK AUTHENTICATE completed
Thu 2024-01-04 09:18:38.535: [06163524] <-- 87 capability
Thu 2024-01-04 09:18:38.535: [06163524] --> * CAPABILITY IMAP4rev1 NAMESPACE AUTH=LOGIN AUTH=PLAIN IDLE COMPRESS=DEFLATE ACL UNSELECT UIDPLUS QUOTA BINARY XLIST SASL-IR
Thu 2024-01-04 09:18:38.535: [06163524] --> 87 OK CAPABILITY completed
Thu 2024-01-04 09:18:38.557: [06163524] <-- 88 COMPRESS DEFLATE
Thu 2024-01-04 09:18:38.557: [06163524] --> 88 OK DEFLATE active
Thu 2024-01-04 09:18:38.577: [06163524] <-- 89 select "Drafts"
....
Thu 2024-01-04 09:23:42.408: [06163537] Sending FETCH response (not logged)...
Thu 2024-01-04 09:23:42.408: [06163537] --> 390 OK FETCH completed
Thu 2024-01-04 09:23:44.418: [06163537] <-- 391 IDLE
Thu 2024-01-04 09:23:44.418: [06163537] --> + idling
Thu 2024-01-04 09:24:11.328: [06163537] --> 391 OK IDLE terminated
Thu 2024-01-04 09:24:11.336: [06163537] <-- 392 append "Sent Items" (\Seen) {1002479}
Thu 2024-01-04 09:24:11.339: [06163537] --> + Ready for append literal
Thu 2024-01-04 09:24:11.433: [06163537] Passing message through AntiVirus (Size: 1002479)...
Thu 2024-01-04 09:24:11.472: [06163537] * Recipient, sender or IP in exclusion list
Thu 2024-01-04 09:24:11.472: [06163537] ---- End AntiVirus results
Thu 2024-01-04 09:24:11.476: [06163537] --> 392 NO Could not append message
Thu 2024-01-04 09:24:19.927: [06163537] <-- 393 logout
Thu 2024-01-04 09:24:19.927: [06163537] --> * BYE IMAP engine signing off (no errors)
Thu 2024-01-04 09:24:19.927: [06163537] --> 393 OK LOGOUT completed
Thu 2024-01-04 09:24:19.928: [06163537] IMAP session complete, (Bytes in/out: 722095/32149)
Thu 2024-01-04 09:24:19.929: ----------

Sending test message from Webmail got it saved to Sent Items (although copy for recipient was quarantined, I guess because webmail servers IP address is not in Trusted IPs).

The log is not indicating that the attachments are password protected

XLSMs are password protected, worksheets/structure but not to open. Sorry.

I've just uploaded 2 typical XLMs to WeTransfer with notification to be sent to arron.caruth@mdaemon.com. Hope that is OK, link you provided is showing "Invalid Link. The link you are trying to access does not exist." this morning

A

Arron Staff

1/4/24, 8:07 AM

The IMAP log shows the message was excluded from AV scanning when uploading to the sent items folder, but the APPEND command still failed. I was not able to reproduce this in my test environment.

Is the IMAP connection going through any type of proxy, gateway, or firewall that could be impacting the session?

Is there any AV running on the MDaemon server that could be preventing the file from being written to disk?

Are there any errors in the windows event log around the time the client attempted to upload the message to the server?

XLSMs are password protected, worksheets/structure but not to open.

No worries, in order for MDaemon to handle files as password protected, a password must be required to open the file. If we can open and read the file without providing a password, so can MDaemon.

A

Aleksandar

1/4/24, 8:46 AM

Is the IMAP connection going through any type of proxy, gateway, or firewall that could be impacting the session?

No proxy/gateway, only (Symantec) endpoint security firewall on each client

Is there any AV running on the MDaemon server that could be preventing the file from being written to disk?

Yes, Symantec Endpoint Security, but everything MDaemon related is excluded

Are there any errors in the windows event log around the time the client attempted to upload the message to the server?

No, nothing that would point to this
Checkin around just now I see that we had a LOT of "NO Could not append message" in logs, with different codes in front of it
For example:
Thu 2024-01-04 08:38:17.613: [06163365] --> 0000000a NO Could not append message
Thu 2024-01-04 08:42:20.930: [06163387] --> 0000000a NO Could not append message
Thu 2024-01-04 08:47:32.769: [06163396] --> 0000000a NO Could not append message
Thu 2024-01-04 08:54:50.331: [06163424] --> 0000000a NO Could not append message
Thu 2024-01-04 08:33:43.281: [06163356] --> 00000018 NO Could not append message
Thu 2024-01-04 08:38:16.928: [06163356] --> 00000027 NO Could not append message
Thu 2024-01-04 08:41:10.931: [06163284] --> 0000002e NO Could not append message
Thu 2024-01-04 09:02:56.196: [06163450] --> 0000000a NO Could not append message
Thu 2024-01-04 09:05:10.209: [06163456] --> 0000000a NO Could not append message
Thu 2024-01-04 09:07:22.736: [06163471] --> 0000000a NO Could not append message
Thu 2024-01-04 09:08:54.115: [06163479] --> 0000000a NO Could not append message
Thu 2024-01-04 08:50:02.456: [06163379] --> 0000002c NO Could not append message
Thu 2024-01-04 09:12:02.780: [06163497] --> 0000000a NO Could not append message
Thu 2024-01-04 09:15:09.246: [06163506] --> 0000000a NO Could not append message
Thu 2024-01-04 09:29:46.027: [06163574] --> 0000000a NO Could not append message
Thu 2024-01-04 09:34:04.103: [06163587] --> 0000000a NO Could not append message
Thu 2024-01-04 09:36:46.676: [06163594] --> 0000000a NO Could not append message
Thu 2024-01-04 09:38:55.265: [06163607] --> 0000000a NO Could not append message
Thu 2024-01-04 10:18:44.297: [06163714] --> 0000000a NO Could not append message
Thu 2024-01-04 10:21:37.690: [06163727] --> 0000000a NO Could not append message
Thu 2024-01-04 10:24:24.657: [06163734] --> 0000000a NO Could not append message
Thu 2024-01-04 10:35:13.425: [06163764] --> 0000000a NO Could not append message
Thu 2024-01-04 11:46:27.213: [06164000] --> 0000000a NO Could not append message
Thu 2024-01-04 11:49:52.855: [06164013] --> 0000000a NO Could not append message
Thu 2024-01-04 12:08:43.534: [06164046] --> 0000000a NO Could not append message
Thu 2024-01-04 12:07:42.375: [06164020] --> 00000055 NO Could not append message
Thu 2024-01-04 12:09:35.389: [06164050] --> 0000000a NO Could not append message
Thu 2024-01-04 10:41:22.149: [06163463] --> 000000a0 NO Could not append message
Thu 2024-01-04 12:17:09.259: [06164082] --> 0000000a NO Could not append message
Thu 2024-01-04 12:09:34.502: [06164020] --> 00000065 NO Could not append message
Thu 2024-01-04 12:11:36.650: [06164020] --> 0000007b NO Could not append message
As far as I could check in a couple of minutes, all of these happened to those users whose computers I've put in Trusted IPs list.
Mostly mine, I've done a lot of testing today 😫 Asked them about possibly missing messages sent today, one of them confirmed he is missing 2 messages which should have been in his Sent Items.
So I'm removing them from Trusted IPs.

A

Arron Staff

1/4/24, 4:41 PM

Did removing IPs from the trusted IP list fix the issue?

I would reccomend checking the Symantec End Point logs, just in case.

Is the drive where user mailboxes are stored running out of space?

Please try running Procmon on the MDaemon server and monitor the user mailboxes when an IMAP client is attempting to APPEND a message to user's sent items folder and an error ("NO Could not append message") is returned. You should see MDaemon attempting to write a MSG file to the Sent Items folder of a user mailbox.

A

Aleksandar

1/5/24, 3:56 AM

Did removing IPs from the trusted IP list fix the issue?

It seems so. Only my computer is in Trusted IPs and all of this morning's "NO Could not append message" are mine
No complaints from people affected by this yesterday and their Sent Items.IMAP folders contain MSGs dated today

I would reccomend checking the Symantec End Point logs, just in case.

I am doing that every day, of course. Checking AV seems to be a conventinal wisdom, but I don't think it has anything to do with this. You see, we have made a switch from Symantec's Endpoint Protection (on-premise solution) to their cloud based Endpoint Security year and a half ago. After initial config and some later tweaking very little was changed in the configuration and certainly nothing in last couple of weeks. Also, I've checked MDaemon logs 10 days back and there was not a single "NO Could not append message" error until 2 days ago when I added these addresses in Trusted IPs.
Of course, issue could be initiated by something Symantec did from their side (they had bad AV definitions and similar slip ups in the past), but affecting just these computers in exactly the same time I made these changes? Not very likely.

Is the drive where user mailboxes are stored running out of space?

No. RAID HD array, more then 50% free.
Also, people in question are not anyway near their MD quotas.

Please try running Procmon on the MDaemon server

I have no previous experiences with ProcMon, so I would need some guidance what exactly to do/look for.
Here you can find 3 ProcMon logs for situations marked red in above screen (start ProcMon on the server, enter filter "Path" to my Sent Items.IMAP folder, send message from my computer, verify that it wasn't copied in Outlook Sent Items and then save ProcMon log)
Also, there was nothing in Event Viewer at these times.
Logs 4 and 5 are for successful creations of md5001000006986.msg and md5001000006987.msg.
Not all messages encounter "NO Could not append message" error. If I start new, blank message, type only couple of characters it is pretty much always saved in Sent Items. Looks like message size might have to do something with the issue.

A

Arron Staff

1/5/24, 8:02 AM

Can you send me the logs from procmon and provide the path to the sent items folder that the message should have been written to?

You can upload the logs to https://mdaemon.sharefile.com/r-r77d4332c21ab4a28afe9e84ea94e2f3c

A

Aleksandar

1/5/24, 8:17 AM

Can you send me the logs from procmon and provide the path to the sent items folder that the message should have been written to?

There was a link to WeTransfer in my previous post (in "Here you can find..."). No matter. Logs are here https://we.tl/t-gMBaTQEY5g
Local path on a server is E:\MailStore\deva\Sent Items.IMAP

You can upload the logs to https://mdaemon.sharefile.com/r-r77d4332c21ab4a28afe9e84ea94e2f3c

This is not working for me for some reason

A

Arron Staff

1/5/24, 2:20 PM

I see why the link is not working for you. There is a comma being added to the end of it. Sorry, I must have messed it up when I pasted it.

https://mdaemon.sharefile.com/r-r77d4332c21ab4a28afe9e84ea94e2f3c

This one should work.

It looks like the the process monitor logs you provided use a filter that was a little bit too restrictive. Its not actually showing the activity for the files in the folder, just the folder itself.

If you still have the original log files, you should be able to just adjust the filters and resend me the logs. Set the filter using Path contains E:\MailStore\deva\Sent Items.IMAP.

Also, I've found the error you are getting only occurs when MDaemon is unable to copy the file from its Temp queue to the user's mailbox. Please add another filter to include the path to MDaemon's Temp queue. By default it is in MDaemon\Queues\Temp, but it can vary. You can find the Temp= path in the MDaemon.ini file under [Directories].

If you do not have the original process monitor logs, would you be able to capture a new set that include the time period when the error occurred?

Thanks,

A

Aleksandar

1/5/24, 3:24 PM

It looks like the the process monitor logs you provided use a filter that was a little bit too restrictive
Please add another filter to include the path to MDaemon's Temp queue.

Temp path is e:\MDaemon\Queues\Temp...

,,,and this is how filters were setup...

...for the new capture few minutes ago (Logfile.1.PML and Logfile.2.PML -> message not saved in Sent Items, Logfile.3.PML -> message saved).

Archive uploaded

A

Arron Staff

1/7/24, 7:23 AM

Please use "contains" for the Relation instead of "is" for both of the Path filters.

A

Aleksandar

1/7/24, 7:45 AM

Please use "contains" for the Relation instead of "is" for both of the Path filters.

New logs uploaded. The same logic (logs 1&2 message not saved in Sent Items, log 3 message saved)

A

Arron Staff

1/8/24, 9:05 AM

Can you confirm that for the tests you have the option enabled to exclude trusted IP addresses from scanning, and that the connecting IP address was on the trusted IP list? Is MDaemon still conifgured this way?

Can you upload a copy of your MDaemon\SecurityPlus\ClamAV\conf\clamd.conf, mdaemon\app\cfilter.ini, \MDaemon\SecurityPlus\Ikarus\scan.server\log\scan\scanserver.log, ClamD log from the MDaemon\logs directory if it exists, and your IMAP log that includes the same sessions show in the procmon logs?

A

Aleksandar

1/8/24, 9:51 AM

Can you confirm that for the tests you have the option enabled to exclude trusted IP addresses from scanning, and that the connecting IP address was on the trusted IP list? Is MDaemon still conifgured this way?

Yes. I have left (only) my work computer in the Trusted IP list (192.168.1.227). MD is still configured that way.

Can you upload a copy of...

Archive with requested files uploaded..
No ClamD logs present. The only logs with ClamD in their names are AntiVirus-ClamAVUpdater-2024-01-*.log
I've added MDaemon-Connector log as well as "NO Could not append message" is displayed in them (sessions 06168475 and 06168477 for procMon logs 1 and 2, session 06168484 for log 3).

A

Arron Staff

1/8/24, 2:32 PM

We have a new cfilter.dll for you to try. Please download it from https://mdaemon.sharefile.com/d-s4846a90e46b54bceb3852ee38bd0f7c3

Once the zip is downloaded, extract the dll, go to the MDaemon\app directory and rename the current cfilter.dll. Copy the new dll into the same location and then restart MDaemon. Once MDaemon is restarted please run the same test again.

If you are still having the same issue after putting the new dll in place, please capture new logs with processmonitor and send them to me along with IMAP and IKARUS scan server logs.

MD AV File Type Exclusions