Email attachment control with Standalone Sentry
Email attachment control determines if and how mobile devices view email attachments. The default setting for Attachment Control is disabled. If Attachment Control is set to disabled, Standalone Sentry delivers attachments as is to all devices.
Up to four emails embedded within the email are supported. All attachment control options are supported for each of the embedded emails. If an email contains five or more levels of embedded emails, Sentry encrypts/converts all attachments, including text and image files.
The following provide additional information about email attachment control with Standalone Sentry:
• | Email attachment control support |
• | Email attachment control options |
• | Remove attachment |
• | Open Only with Docs@Work and Protect with Encryption |
• | Deliver as is |
• | Open with Secure Email App |
• | Forward emails with attachments |
• | Attachment control recommendation for multiple Sentrys |
• | Default file name exclusion list |
• | Standalone Sentry S/MIME handling to sign or encrypt emails |
Email attachment control support
Standalone Sentry supports email attachment control only for the iOS native email client, and some AppConnect-enabled email apps. If you are using attachment control, and some iOS devices use other third-party iOS email clients for which attachment control is not supported, configure a separate Sentry for those devices. On that Sentry, do not enable attachment control.
Android devices using unsecured email apps have limited email attachment control support. You can configure the Standalone Sentry to remove the attachment or to deliver the attachment as is, without added security. However, for secure, AppConnect-enabled email apps on Android devices, you can configure Standalone Sentry to deliver the attachment for the secure app to open in the secure container.
Email apps on Windows devices have limited email attachment control support. You can configure Standalone entry to remove the attachment or to deliver the attachment as is, without added security.
Email attachment control options
For each Standalone Sentry, you configure email attachment control in the Admin Portal. The following table summarizes the email attachment control options that are supported on different devices:
Email attachment control option |
iOS devices using the iOS native email client |
iOS devices using supported AppConnect-enabled email apps |
Android devices using supported AppConnect-enabled email apps |
Other Platforms (Including Android using unsecured apps) |
Supported, but typically not used |
Supported, but typically not used |
Supported, but typically not used |
Supported |
|
Supported |
Not supported |
Not supported |
Not supported |
|
Supported, but typically not used |
Not supported |
Not supported |
Supported |
|
Not supported |
Supported |
Supported |
Not supported |
Remove attachment
The “Remove attachment” option causes the Standalone Sentry to remove attachments from emails, replacing each attachment with another file. The name of the replacement file is the original attachment file name appended with removed.html. For example, myDocument.pdf is replaced with myDocument.pdf.removed.html.
The replacement file contains the following text message:
“The original attachment was removed as required by the security policies of your administrator.”
On iOS devices, the message is translated according to the language setting of the device. The language defaults to United States English if the language setting is not one of the supported languages.
NOTE: | Typically, you won’t use this option on iOS devices with native email or supported AppConnect-enabled email apps or on Android devices that use secure apps. Other options are available on these devices that are less intrusive, but still keep the attachments secure. |
Open Only with Docs@Work and Protect with Encryption
The following describe how the option works:
• | About open only with Docs@Work and protect with Encryption |
• | Limitations |
• | When to use encryption |
• | Configuration considerations |
About open only with Docs@Work and protect with Encryption
Standalone Sentry encrypts the email attachments. Either a .secure (128-bit encryption) or a .attachctrl (256-bit encryption) extension is appended to the attachment’s file name.
The encrypted attachments open only in the Docs@Work app. The user cannot open the attachment using any other app on the device.
Docs@Work cannot display encrypted files in the following cases:
• | The file type is unsupported. |
In this case, an error message is presented when the user tries to view the attachment.
• | Its encryption key does not match the attachment’s encryption key. |
Docs@Work app encrypts the document when the device user sends the document as an email attachment. Either a secure (128-bit encryption) or a .attachctrl (256-bit encryption) is appended to the attachment’s file name.
• | If the encrypted attachment is emailed to a work account, the recipient receives an encrypted attachment. The encrypted attachment can be opened only Docs@Work. |
• | If the encrypted attachment is emailed to a non-work account, Standalone Sentry decrypts the attachment and an unencrypted attachment is sent to the non-work account. However, because the email goes through Sentry, you have a record of the email and the attachment being sent. |
NOTE: | Already encrypted attachments (.secure or .attachctrl) emailed from a non-work account to a non-work recipient are not readable by the recipient. Since emails from non-work accounts do not go through Sentry, Sentry does not decrypt the attachment. |
The following table summarizes when the recipient receives an encrypted attachment and whether the attachment is readable.
|
To work colleague |
To non-work colleague |
||||||||||||
From work account Attachment is encrypted |
|
|
||||||||||||
From non-work account An encrypted attachment is forwarded |
|
|
Limitations
Consider the case where you change attachment control handling on MobileIron Core to no longer be Open only with Docs@Work and protect with encryption. When Standalone Sentry sends subsequent emails to devices, it no longer encrypts the emails. However, the devices continue to encrypt Docs@Work attachments in emails that the user sends. If the recipient is a work colleague, the recipient can still read the attachment in Mobile@Work. However, non-work recipients cannot read the attachment. The reason is that the Standalone Sentry no longer decrypts the attachment in the sent email.
When to use encryption
The encryption protection provides additional access control for the attachment, making it prohibitively difficult for a malicious app to view the content. However, encryption protection has an impact to Standalone Sentry performance.
Therefore, use the encryption option only if you are operating in a high security environment.
Configuration considerations
Changing to or from this option may require you to re-push the Exchange app setting to the Standalone Sentry’s devices. For more information, see Impact of changing the encryption option.
This option only works with the Docs@Work app for iOS. To implement Open Only with Docs@Work and Protect with Encryption, you must also configure Docs@Work.
Deliver as is
The Deliver as is option delivers all email attachments in their original form. The device user views attachments with any available apps that work with the type of attachment.
Typically, you won’t use this option on iOS devices using the native email client because other options that keep the attachments secure are available.
Open with Secure Email App
Typically, you use this option on:
• | Android devices for which you have enabled secure apps and are using a supported AppConnect-enabled secure email app. This option delivers attachments to the secure AppConnect container. Only AppConnect apps can open the attachment. |
• | iOS devices using a supported AppConnect-enabled email app. This option delivers attachments to the email app. |
For more information about AppConnect apps, see the AppConnect and AppTunnel Guide.
Forward emails with attachments
When a device user forwards an email that has an attachment, the attachment in the forwarded email is the original attachment. However, if the ActiveSync server delivers the email to another device that Standalone Sentry manages, Standalone Sentry applies the email attachment control to the forwarded email’s attachment.
NOTE: | The exception to this behavior involves the behavior of the iOS native email client. If the email attachment control option is Remove Attachment, the iOS native email client forwards the replacement file, the file that contains the replacement text and has the .removed.html file extension. The original attachment is not forwarded. However, you typically do not use the Remove Attachment option on iOS devices. |
Attachment control recommendation for multiple Sentrys
If you are using encryption with attachment control, MobileIron recommends that all Sentrys have Open only with Docs@Work and protect with Encryption enabled for iOS using Native Email.
The attachment control encryption key, once it is generated, is persistent on Core. For the Docs@Work app, the key is pushed to the iOS device when the app does an AppConnect check in. Devices that have the encryption key will encrypt documents emailed from Docs@Work and is able to view encrypted documents in Docs@Work.
If your deployment has multiple Sentrys and some have Open only with Docs@Work and protect with Encryption enabled and others do not, attachment control may fail. An encrypted document is forwarded as is by a Sentry not configured to protect with encryption. In this case, you will not be able to view the encrypted document on mobile devices that do not have an encryption key. Since the document remains encrypted, you will also not be able to view it on non-mobile devices or on non-iOS email clients.
Default file name exclusion list
The File Name Exclusion text box specifies the file extensions that you always want Standalone Sentry to deliver as is, even though the attachment control option selected is “Open only with Docs@Work and protect with encryption”.
If the text box specifies no file extensions, the Standalone Sentry uses the following file extensions by default for the exclusion list:
• | txt |
• | html |
• | htm |
• | jpg |
• | jpeg |
• | gif |
• | png |
• | eml |
• | rpms |
• | rpmsg |
• | bmp |
• | tiff |
• | tif |
• | sdtid |
• | log |
• | ics |
NOTE: | When encryption is enabled for email attachments, the Docs@Work app encrypts all email attachments, including files in the exclusion list. However, Standalone Sentry decrypts the attachment and forwards it as an unencrypted file. |
The following table summarizes how the exclusion list impacts whether the Standalone Sentry applies each attachment control option:
|
File extensions in exclusion list |
File extensions not in exclusion list |
Open only with Docs@Work and protect with encryption |
Option not applied. Any appropriate app can open the file, which Sentry delivers as is. |
Applied. Files open only with Docs@Work and are protected with encryption. |
Remove Attachment |
Applied. Sentry removes the attachment. |
Applied. Sentry removes the attachment. |
Deliver as is |
Applied. Sentry delivers the attachment as is. |
Applied. Sentry delivers the attachment as is. |
Open with Secure Email App |
Applied. Only secure email apps can open the attachment. |
Applied. Only secure email apps can open the attachment. |
Standalone Sentry S/MIME handling to sign or encrypt emails
• | Digitally signed emails |
• | Encrypted emails |
Digitally signed emails
Most email apps can use S/MIME (Secure/Multipurpose Internet Mail Extensions) to digitally sign an email, if the email user requests it. The receiving email app processes this email signature to validate the following:
• | The sender’s identity |
• | Whether the email has been tampered with |
The Standalone Sentry does some processing on each email that is directed to an ActiveSync device when the email attachment control option is one of the following:
• | Open only with Docs@Work and protect with encryption |
• | Remove attachment |
This processing breaks the security of the email signature. Therefore, when an email app receives a signed email in these cases, the app always indicates to the user that it cannot validate the sender’s identity and that the email has been tampered with.
For example, the iOS native email client displays the email’s From field in red if:
• | an iOS device user has enabled S/MIME in the iOS Mail app |
• | the iOS native email client receives an S/MIME email through Standalone Sentry |
• | the email attachment control option is one of the options mentioned above |
Encrypted emails
S/MIME can also be used to encrypt emails, although this use of S/MIME is not common. Standalone Sentry passes along an S/MIME encrypted email with no impact to the email.