With the release of iOS 5, Apple added support for S/MIME to their platform. However, after spending a few hours with the new release we discovered that while it works great on Exchange 2007, it doesn’t quite work as expected on Exchange 2010.
What is the problem?
While using iOS 5 in conjunction with Exchange 2010, composing new encrypted messages works fine. But once you start sending replies with encryption enabled, your recipients will start asking why you are sending back blank replies. This is because an encrypted reply sent from this release appears blank in most clients!
This includes other ActiveSync devices that are not running iOS 5, any version of Outlook and Outlook Web App. Thankfully, this behavior only happens when replying to internal recipients. If the recipient is in another Exchange organization, the encrypted message is visible.
Why does this happen?
When an iOS 5 device replies to an S/MIME message while connected to an Exchange 2010 server, it uses an incorrect implementation of the Activesync protocol. Instead of using the SendMail command it uses the SmartReply command, causing the problem we see with the encrypted message. When performing the same operation with an Exchange 2007 server we can see the iOS 5 device uses the correct behavior, which is why this only happens when the device is connected to Exchange 2010.
Below is the command posted to each version of Exchange from the iOS 5 device:
To Exchange 2010:
POST /Microsoft-Server-ActiveSync/default.eas?User=User&DeviceId=ApplDeviceID&DeviceType=iPhone&Cmd=SmartReply HTTP/1.1
To Exchange 2007:
POST /Microsoft-Server-ActiveSync/default.eas?User=UserName&DeviceId=ApplDeviceID&DeviceType=iPhone&Cmd=SendMail&SaveInSent=T
Resources:
The Activesync Open Protocol Specifications on SmartReply and SendMail are included below:
SmartReply: http://msdn.microsoft.com/en-us/library/ee217283(v=EXCHG.80).aspx
SendMail: http://msdn.microsoft.com/en-us/library/ee178477(v=EXCHG.80).aspx
When running Get-MessageTrackingLog in Exchange 2007 or later, you may have noticed that sometimes the “MessageInfo” field contains a date and other times it’s a three character code. Looking at the log files this field is labeled “message-info”.
This three digit code logs the authentication method and domain. The first two digits of that code are the hex value of the authentication method used in the transaction, the third character is the “domain” (not sure what that means).
The table below maps the possible values with the associated authentication methods:
| Value | Authentication Method |
|---|---|
| 00 | None |
| 01 | SenderId |
| 02 | MutualTLS |
| 03 | MapiSubmit |
| 04 | SecureMapiSubmit |
| 05 | SecureInternalSubmit |
| 06 | TLSAuthLogin |
| 07 | Login |
| 08 | Pickup |
| 0A | NTLM |
| 0B | GSSAPI |
| 0C | MUTUALGSSAPI |
| 0D | Custom |
| 10 | SecureExternalSubmit |
| 11 | DirectTrustTLS |
| 12 | Replay |
