We have recently upgraded our EEFF 4.x software to the new version of File and Removable Media Protection 18.104.22.168. After the upgrade we noticed very unusual behavior in FRP when dealing with the emailing of encrypted files. In EEFF we were able to take a file that was encrypted on a computer's local hard drive with a specific encryption key, drag it into an email or use the attach a file feature in Outlook, and send the encrypted file in its encrypted state. In the new version of FRP, this behavior has now changed and as soon as someone attaches an encrypted file into an email, regardless if it is via Outlook, GMAIL, Yahoo, or some other email application, the file loses its encryption and is sent out in a decrypted status! I have setup a policy for "Encryption Options" and have added processes like Outlook.exe and iexplore.exe in the blocked processes section. Now if I try to send out a file that is already encrypted by either attaching it to an email with Outlook or another email web program within Internet Explorer for instance, the file is attached to the email with a special character at the end of the file name that looks like a big dot. If the recipient opens up the email on their computer, even with the FRP client software installed and access to the correct key to open the file, the file cannot be opened due to the special character messing with the file type association within Windows. The user would get a window asking what program they would like to use to open this file since Windows is unsure what file type it is. If the recipient removes this special character at the end of the file name by renaming the file, the file can be opened and appears to have retained the encryption.
The fact that in EEFF this was not an ssue and with FRP the process has changed is a bit concerning to me. Not only is the file sent out decrypted without creating the policy for the Encryption Options with the blocked processes, but even with the policy in place, the recipient would have to know to rename the file to remove the special character at the end of the file name in order to properly open the file. In my opinon the FRP software should be smart enough to retain the encryption that was previously set locally on the file when it is emailed out as an attachment and the recipient should just be able to either open it directly or save it to their hard drive and open it without any other special steps.
Has anyone else run into this issue and/or have you seen the same type of behavior with the special character appearing at the end of the file name when using the Encryption Options policy with the blocked processes?
Any suggestions or solutions to keep the process as seamless as possible?