Re: malware bytes on SM server

Question asked by Hemen Shah - 4/26/2018 at 12:31 PM

Answered

Hi,

Anyone using Malware Bytes on SM 15.x installed server ?

Is it required to exclude mailservice.exe along with other SM spool and domain folders ?

Thanks

6 Replies

Reply to Thread

Employee Replied

4/26/2018 at 2:57 PM

Employee Post Marked As Answer

Hi Hemen,

You won't need to exclude mailservice.exe. However, you do need to exclude the Domains folder. (You don't want it to scan the GRP files, but it'll need to scan the spool for messages that come in.) That said, if MalwareBytes is detecting SmarterMail as a threat, an exclusion will be needed.

Hemen Shah Replied

4/27/2018 at 5:22 AM

Hi,
Its not detecting as a threat but have observed spool getting stuck sometimes post installation of MBytes, also if we dont exclude SPOOL folder then what about CLAM AV, will it not get conflict with MBytes ?

Thanks

Employee Replied

4/30/2018 at 9:52 AM

Employee Post

Hemen,

MBytes should not conflict with ClamAV however I would recommend disabling ClamAV to see if the issue persists. There may be a file locking condition that's occurring. During the time of delivery, if you review the delivery logs are you seeing any GRP files being locked ?

Hemen Shah Replied

5/3/2018 at 4:47 AM

Hi, I do see couple of Mailbox locked issue, but then i have already excluded spool folder in Malwarebytes as i want Clamd to keep running and scanning for mails.

Hemen Shah Replied

5/3/2018 at 4:47 AM

Anyone using Malware Bytes on SM server, then would request their experience on the same.

Employee Replied

5/21/2018 at 12:55 PM

Employee Post

Hemen, mailbox locked scenarios are encountered when the users GRP file is being help open by SmarterMail (such as an ongoing POP connection), or a third party application such as Malware bytes.

If you haven't already done so, you will want to add exclusions for *.GRP files to prevent locking.

You can also run handle.exe from sysinternals the next time a locking condition is encountered, this tool can be found here: https://docs.microsoft.com/en-us/sysinternals/downloads/handle

You can call handle through a command similar to this 'handle.exe SmarterMail\Domains\<Domain>\Users\<UserID>\Mail\Inbox' to see a list of handles on the GRP files within the Inbox folder. If there are any applications listed other than mailservice.exe, you will want to investigate to see why they are keeping GRP files open. If you only see SmarterMail accessing the files, the end user likely has a POP client that's connecting too frequently and taking a long time to return the content leading to the mailbox becoming locked for an extended period.

This is something we can assist you in tracking down if you submit a ticket with our support department if you're seeing it frequently within your environment.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text