Not sure if it makes a difference but we're not using a TIE server. I had to open SR 4-17454222971 because it detects outlook.exe trying to access winmail.exe and it says it is a trojan and would be blocked. I was told that because it violates one of the built in rules, i would not be able to make an exemption for it. I have submitted the .exe several times in a password protected .zip as requested, but so far they just keep requesting the file again.
Same here with "detects outlook.exe trying to access winmail.exe" but only around 1% of the clients.
I think that happens IF the enduser has an Account or a software which tries to use such an E-Mail account (To sync Calendar or send E-mail).
Like when you have an application that can send E-Mail and then recursive goes through all the client has to send an E-mail (Accounts Settings etc.)
This is the same behaviour as malware.
To open a ticket was correct way since they only way to get it running is to exclude the file HARD from ENS and ATP which we don't want.
Now i originaly come from Groupware Exchange and i hate software that triggers that (You should not) so i understand Mcafee somehow in blocking that or thinking it malware.
We even have a software inhouse development which we sell to customers which does the same suspicious behaviour. You can't talk with developers about that. They want
to send E-mail from a client and Groupware team does not want to open some relay even auththenticated from each client VLAN.
Thank you for your response. That one does make sense to me of why it's being detected. I have the Action Enforcement set to balanced right now, and I keep getting notifications about
CUNINST.DLL, STCTRACEU.DLL, MSI31DD.TMP, MICROSOFT.PHOTOS.DLL, PHOTOSAPP.WINDOWS.DLL, MEDIAENGINE.DLL, APPCORE.WINDOWS.DLL, MICROSOFT.PHOTOS.AGM.NATIVE.WINDOWS.DLL, COMSVCCONFIG.NI.EXE, DFSVC.NI.EXE, MICROSOFT.BUILD.NI.DLL, MSBUILD.NI.EXE, MICROSOFT.BUILD.ENGINE.NI.DLL, MICROSOFT.INTERNAL.TASKS.DATAFLOW.NI.DLL, WSATCONFIG.NI.EXE, SMSVCHOST.NI.EXE, MICROSOFT.INTERNAL.TASKS.DATAFLOW.NI.DLL, MSI5033.TMP, MICROSOFT.ACTIVITIES.BUILD.NI.DLL, MICROSOFT.OFFICE.TOOLS.NI.DLL, MICROSOFT.OFFICE.TOOLS.COMMON.NI.DLL, MICROSOFT.OFFICE.TOOLS.EXCEL.NI.DLL, MICROSOFT.OFFICE.TOOLS.EXCEL.IMPLEMENTATION.NI.DLL, MICROSOFT.OFFICE.TOOLS.COMMON.IMPLEMENTATION.NI.DLL, MICROSOFT.OFFICE.TOOLS.EXCEL.NI.DLL, MICROSOFT.OFFICE.TOOLS.COMMON.IMPLEMENTATION.NI.DLL, MICROSOFT.OFFICE.TOOLS.NI.DLL, MICROSOFT.OFFICE.TOOLS.OUTLOOK.NI.DLL, MICROSOFT.OFFICE.TOOLS.COMMON.NI.DLL, MICROSOFT.OFFICE.TOOLS.OUTLOOK.IMPLEMENTATION.NI.DLL, MICROSOFT.OFFICE.TOOLS.V4.0.FRAMEWORK.NI.DLL, MICROSOFT.OFFICE.TOOLS.WORD.NI.DLL, MICROSOFT.OFFICE.TOOLS.COMMON.IMPLEMENTATION.NI.DLL, MICROSOFT.OFFICE.TOOLS.WORD.IMPLEMENTATION.NI.DLL, MICROSOFT.BUILD.NI.DLL, MICROSOFT.VISUALBASIC.COMPATIBILITY.NI.DLL, MICROSOFT.TRANSACTIONS.BRIDGE.DTC.NI.DLL, MICROSOFT.VISUALSTUDIO.TOOLS.APPLICATIONS.HOSTING.NI.DLL, MICROSOFT.VISUALBASIC.COMPATIBILITY.DATA.NI.DLL
PHOTOSAPP.WINDOWS.DLL, MICROSOFT.PHOTOS.AGM.NATIVE.WINDOWS.DLL, APPCORE.WINDOWS.DLL, MEDIAENGINE.DLL
However when I check ePO it says the files violated no rules and ATP would allow. Should I change my Action Enforcement to Productive?
1 of 1 people found this helpful
Those are the same Files we have and which are problem of our case <4-17441502971> which is currently at TIER III Development.
Sadly Mcafee does not take this serious enough we think from our side.
Currently we have around 10'000 add. Files in the TIE ebcause of that. Every time he compiales a Assembly or tries to do that he gets a new MD5.
We had to take a look at the POSTGRE SQL DB yesterday because if such a case happens it will take down the TIE once because of space.
I changed the action enforcement to productive and I haven't got anymore notifications about those files yet. Guess I will wait until McAfee resolves your SR and the SR I opened for WINMAIL before I deploy it to more workstations.