iOS 7.1 Mail App Encrypting Certain Replies Inappropriately

Encrypted Reply

‘Reply All’ Via iOS 7.1 Mail App


 
We talked recently about Apple mostly fixing one bug related to S/MIME encrypted email messages with their release of iOS 7.1.  Now it appears that they may have another.

Normally when using S/MIME email signing and encryption, the Mail app will indicate a blue lock icon next to any recipient with whom you’ve previously received a signed message and installed their public certificate.  Any recipients for whom you don’t have a certificate installed, and are therefore unable to exchange encrypted mail, are shown in red with an unlock icon next to their name.  It’s perhaps the most visually intuitive S/MIME implementation out there.

If you’ve previously installed a certificate for every recipient on a given message, Mail will indicate that the message is Encrypted at the very top, again accompanied by a blue lock icon.  If there are any recipients on a message for whom you don’t have a certificate, the message will normally drop back to Not Encrypted at the very top and show the red unlock icon.  You would never want to send out a single encrypted message to a group of people such that only certain recipients had the means to decrypt and read it.

At the Connecticut-based healthcare practice where I work, we collaborate with outside technical people all the time.  In day-to-day e-mail exchanges, I’ll frequently receive e-mail messages from third parties where the sender chooses to include or carbon copy our CIO or one of my IT colleagues.  More to the point, someone who doesn’t use S/MIME signing and encryption will send me a message where they carbon copy someone who does use S/MIME.  Often the topic will merit a response, where I begin by hitting Reply All.

The iOS 7.1 Mail screen captured at the top of this article should not be possible.  You’re looking at a Reply All where I have no S/MIME certificate for the To party, but I do for the Cc’d party.  Yet the overall message status at the very top still indicates Encrypted.  If I began a new e-mail message to the very same recipients, the message status would be Not Encrypted.  This inadvertent Encrypted status on Reply Alls to a mixed group of recipients isn’t just a visual problem.  If sent, the reply message actually goes out encrypted as promised, such that only the name in blue will be able to read it.  Red recipients will get an smime.p7m attachment that they can’t do anything with.

Curiously, I’m only able to replicate this problem situation when doing a Reply All from my Microsoft Exchange e-mail account.  I’m unable to duplicate it when replying from Google-hosted IMAP accounts.  I should mention that while I’ve seen it happen from multiple devices running iOS 7.1, the device from which I recreated this scenario is an iPhone 5s that was completely wiped and reloaded after having been upgraded to iOS 7.1.

The work-around, for now, seems to involve avoiding the Reply All button.  If you instead limit yourself to choosing Reply, and then manually add the other recipients back, the message status seems to behave appropriately.  It’s an unfortunate extra bit of work, with the potential to stand in the way of wider S/MIME use in iOS-centric enterprises.

This information has been submitted to Apple on case number 593916475.

Old Exchange Flaw Persists in iOS 7

Exchange ActiveSync Connections From One iPhone 5 Running iOS 7.

Exchange ActiveSync Connections From One iPhone 5 Running iOS 7.


 
Starting last December, and continuing in March of this year, we talked about a series of symptoms that often arrive hand in hand, sporadically, on Apple devices running various revisions of iOS 4, 5 and 6, up through 6.1.3.  Those symptoms include devices running warm to the touch or even hot, a battery that may drain significantly faster than normal, and spikes in cellular data use of up to ten times the user’s normal pattern.  While this trio of symptoms may well have more than one culprit, the many instances that I’ve personally witnessed have since been reduced to a single common cause.  One with a quick solution.

If you’d like to read the years-long chain of events in order, including documented interactions with Apple along the way, you’re welcome to follow these links to part 1 and part 2 of the story.  Today’s entry is the third – but not the final – installment.  In the interest of time, we’ll try to get right to the point.

For All Of Us
If your iPhone, iPad or iPod touch ever begins running warmer than normal, or the battery drains twice as fast, or you get sticker shock on your next cellular bill, you’ll obviously want to quickly determine the cause.  Fortunately, with iOS 7, this is easier than ever before.  Begin by navigating to Settings > Cellular.  Scroll down, and you’ll see data usage for native and 3rd-party apps directly under each application’s names.  But don’t stop there.  Also navigate into > System Services, and observe your usage here too.  If your device connects to your company’s Microsoft Exchange e-mail environment, don’t be surprised to see a high number next to Exchange Accounts.  And if you do, read on.
 

Cellular use stats are a good way to identify any application working overtime.

Cellular use stats are a good way to identify any application working overtime.


 
For Microsoft Exchange Users
As we alluded to earlier (after giving it away in the title, lead graphic and caption), virtually every instance of heat + battery drain + runaway data use that I’ve personally witnessed has been the result of a sudden-onset problem syncing a Microsoft Exchange calendar.  When an iOS device encounters an error syncing an Exchange calendar, it simply retries.  In fact, it retries every couple of seconds or so, nonstop, 24 hours a day, forever if you let it.  Unfortunately this is nothing new.

This past weekend, an executive’s iPhone 5 (on Verizon) and his iPad 2 (Wi-Fi only), both running iOS 7, began exhibiting runaway connections to my employer’s Microsoft Exchange ActiveSync server.  The user upgraded his iPhone 5 to iOS 7.0.2 over the weekend, but the problem persisted.  In one 24-hour period, his iPhone checked in with our server 45,009 times, while his iPad connected 55,547 times.  Normally we’d expect to see a single device connect a few hundred times per day rather than tens of thousands.  After notifying the executive this morning, and asking him to perform the following fix, his problem went away for the time being.

If you think this may be happening to you, but aren’t sure, you might consider contacting your company’s IT Department or Microsoft Exchange Administrator.  We’ll talk about what he or she can do in the next section.  Having said that, the potential fix is easy, non-destructive, and you can try it out to see if it solves your problem.  As illustrated below, you’ll simply navigate to your Exchange account settings, turn your Calendars off, and then turn them back on.  While one step, “Delete from My iPhone”, sounds ominous, you’ll get your calendar entries back when you re-sync with the server.  Further instructions follow in the next caption box.  Please read and re-read them.  And use them at your own risk.
 

On your device, select Settings > Mail, Contacts, Calendars > (your Exchange account). Turn off ‘Calendars’ and then ‘Delete from My iPhone.’ Wait thirty seconds, and turn Calendars back on.

On your device, select Settings > Mail, Contacts, Calendars > (your Exchange account). Turn off ‘Calendars’ and then ‘Delete from My iPhone.’ Wait thirty seconds, and turn Calendars back on.


 
For Microsoft Exchange Administrators
Keep an eye on the IIS log files on your Exchange ActiveSync server on a regular basis.  By doing so, you may be able to identify a runaway iOS device before the users even know what’s going on.  In larger environments, you’ll likely use automation and alerting tools to bring runaway devices to your attention very quickly.

For Apple
The fact that this runaway connection problem has persisted now across four generations of iOS is a bit ridiculous.  I’ve seen no Android devices exhibiting similar behavior in our environment, leading me to believe that it’s technically possible to engineer something that doesn’t do it.  Common sense suggests setting some sort of timeout; a maximum number of retries before abandoning a particular calendar entry update.  Last Spring I hoped that Apple would fix this situation with the next incremental release.  We now know that they’ve failed to address it in their next major release, iOS 7.  And that leaves all of us to live with the problem, monitor it, and execute this fix whenever necessary.

Problems Persist in iOS 6.1.2

In late December, 2012, I posted the saga of narrowing down a set of iPhone / iPad symptoms that periodically manifest themselves and usually arrive hand in hand.  Those symptoms include noticeably diminished battery life, surging 3G/4G data consumption, and devices that run warmer to the touch than normal.  If you’d like my history with this going all the way back to iOS 4.x, click here and then follow a link back to this post when finished with the first.  Today’s post is chapter two of what I hope is only a trilogy.

Quick Recap
When we left off in December, we’d narrowed our iPhone / iPad problems down to runaway interaction between problematic iDevices and my employer’s corporate e-mail server running Microsoft Exchange 2003 Service Pack 2.  These interactions are documented in the Internet Information Server (IIS) logs on our server running Exchange ActiveSync, and are stored by default in our case at c:\WINDOWS\system32\LogFiles\W3SVC1.  While a properly-functioning iPhone may connect to our Exchange server a few hundred times per day, a runaway device will connect up to tens of thousands of times per day.  This excess traffic will continue unabated on an offending device until manual intervention is taken.  If too many devices in an organization are doing this at once, it creates a sort of denial-of-service attack against the Exchange ActiveSync server.

It’s important to note that this issue may affect more than just the Exchange portion of the iOS e-mail client.  I’ve received and observed feedback regarding the client-side symptoms – battery drain, 3G/4G data surge and warm devices – from people connecting to other push e-mail services including Hotmail and iCloud as well.  Of course end-users and business network administrators like myself aren’t privy to what’s happening at the other end of those cloud services.

Since Then
Subsequent to my December post, this iOS / Exchange issue finally reached mainstream consciousness following the release of iOS 6.1.  Apple went as far as issuing a rare acknowledgement that an issue was known to occur when connected to Microsoft Exchange 2010 SP1 or later, and that it is triggered by responding to an exception to a recurring calendar event sent to a Microsoft Exchange account.  Apple said nothing of Exchange 2003 that I am aware of.

Apple Inc.
I talked about and documented several of my interactions with Apple in the December post. I shared my mild frustration in getting past their basic support to the point that they believed that I had a legitimate iOS issue.  On January 9th, 2013, my issue was escalated yet again to a person that I’ve been in fairly regular contact with since.  I provided raw log files at Apple’s request to be forwarded to their engineering team.  And I’ve had nothing but positive interaction with Apple since.  I know from Google Analytics that Apple is familiar with my original blog post.  As I’m writing this follow-up, my little blog has received 39 visits from a network labeled, ‘apple inc.’, another 8 visits from ‘apple inc. – 10g ashburn ide’, and 1 visit from ‘apple computer’ since the original post went live.

iOS 6.1.2
Apple released iOS 6.1.2 on February 19th, 2013.  The update description read in full, “Fixes an Exchange calendar bug that could result in increased network activity and reduced battery life.”  I received a few e-mails from friends as far away as China pointing out that our issue might now be fixed.  Three days later I sent out a memo to our iOS users asking any who had not already done so to upgrade to iOS 6.1.2.

Not Fixed
On Sunday, February 24th, a single CDMA iPhone 5 running iOS 6.1.2, noted in our IIS logs as ‘Apple-iPhone5C2/1002.146’, contacted our Microsoft Exchange ActiveSync server 69,878 times that day.  Keep in mind that there are only 86,400 seconds in a 24-hour period.  By way of comparison, my iPhone 4 checked in 336 times during the same span of time.  Upon discovery, I notified my contact at Apple and sent him the log at his request.

What To Do With Your Runaway iPhone
Since the December post, we’ve learned that fixing runaway iDevices is much simpler than our original course of action, which consisted of wiping them out and setting them up as if they were new.  Neither that action, nor simply deleting and re-adding an Exchange account, seems to be necessary.  In fact, resolving our latest runaway iPhone proved to be as simple as turning off the iPhone’s calendar sync on the Exchange account momentarily, and then turning it back on.
 

On your device, select Settings > Mail, Contacts, Calendars > (your account).  Turn off Calendars and 'Delete from My iPhone.'  Wait a moment, and turn Calendars back on.

On your device, select Settings > Mail, Contacts, Calendars > (your account). Turn off ‘Calendars’ and then ‘Delete from My iPhone.’ Wait a moment, and turn Calendars back on.


 
For Exchange Administrators
Some organizations are taking technical means to bar iPhones running iOS 6.1 through 6.1.2 from contacting their Exchange servers.  If you have a great many iPhones, this step may be absolutely necessary in order to keep your e-mail environment up for everyone else.  At the very least, you should consider alerting all users to stop accepting calendar invitations and updates via their iPhones and iPads.  For those of us with far fewer devices to manage, simply keeping abreast of the server logs and working with affected users may be enough.  As I write this, our IIS log for Saturday is already several times larger than it should be.  It wouldn’t be that difficult to automatically BULK INSERT each day’s log file into a SQL table and then query for the number of connection attempts by each user’s iPhone or iPad per day.  I work with a great DBA who may be called upon to do that for us if Apple doesn’t come out with a fix real soon.

Final Thoughts
While iPhones are wonderful pieces of technology that can do a great many things, there are exactly two functions that every smartphone must do reliably, bar none.  One is to make phone calls.  The other is to handle mobile e-mail, calendaring and contacts.  The fact that the premier device from one of the most well-regarded companies on earth has problems with one of these basic necessities is fairly disconcerting.  One wonders how hard it could possibly be to program in an upper limit to the number of attempts to update a single calendar invitation!?  I’m not yet at the point that I’m going to steer anyone away from the iPhone and iPad.  But I really hope that Apple can get this right in iOS 6.1.3 or soon thereafter.  Before I start giving BlackBerry a second look.

[While I hoped that this issue would ultimately be resolved by iOS 7, we’ve now seen this behavior in iOS 7 and 7.0.2 as well.  Follow this link to the next post.]