How exactly are you supposed to keep a secret on a mobile device anyway? Most of us are too annoyed at having to enter a password to use a device every time you take it out of your pocket, but how does this interact with if you need to keep a secret on a mobile device? Take, for example, my Imap Pusher Service. If the user wants to save the password that will be used to log onto the destination IMAP server so that he doesn’t have to re-enter this each time, how can this be kept secret? Any encryption I put on the password is easily reverse engineerable (app is open source), so all I would be achieving is security via obfuscation, which has always unsettled me. The only way around this that I know of, it to have the OS guard the encryption key, or base the encryption key on a key that the user provides to establish a session with the device. And in both cases, this would require the user to enter some kind of password to establish a session with their device, hence rendering it less useful again. Can we just have fingerprint scanners on our phones already???
I’ve started to put together a program that will allow Pocket Outlook on a Windows Mobile device to accept push email from an IMAP server like Gmail (provided that IMAP server supports the IDLE command). The program is very rough around the edges, but functional enough that I thought I’d give everyone a peek, and find out what they thought.
I’ve put it up on CodePlex, at http://www.codeplex.com/ImapPusherService
I, like other Windows Mobile users, I’m sure, am simultaneously pleased and frustrated with my device. It enables many wonderful things, but sometimes brings you 95% of the way there, and leaves you wanting. Google, not that long ago, introduced IMAP support for Gmail. Not that exciting for those of us that are perfectly satisfied with the POP3 clients we have available to us, but hiding in this innocuous addition to the Gmail service was, believe it or not, support for push Gmail.
There is an extension to the IMAP spec which details an IDLE command, whereby IMAP clients can register for unsolicited notifications to be sent downstream from the server, over the open TCP connection, to signal that new mail has arrived.
In other words IMAP IDLE = Push email notifications. This is great!!!! Pocket Outlook supports IMAP, now I can have push Gmail on my phone! Not quite. Just like IMAP servers are not required to support the IDLE command, IMAP clients do not need to support this command either. Pocket Outlook does not.
I then went in search of a client for windows mobile that would allow me to have access to glorious push Gmail. Flexmail seems to do the trick, but is way to bloated for my liking, and I prefer to use Pocket Outlook to manage my messages on the handheld. It seems there used to be an “outlook plugin” to enable the IDLE support for outlook called vgsmail, but that seems to have become a for pay program that seems ill supported according to Internet word-of-mouth. Not very satisfying.
So how hard would it be to implement a program that talks IMAP to an IMAP server and subscribes for notifications based on this IDLE command? Well, it turns out that the IDLE command spec is pretty darn simple. So I decided to see if I could have a hack at this.
Turned out the hardest part of the project was the fact that .NET CF does NOT support the SSLStream class that his big brother benefits from. There does not even appear to be a way to use the managed socket wrapper to set up a secure socket. So this project currently contains unmanaged *shiver* code to set up the SSL connection required. Why is SSL required? Google, like with many of its services, doesn’t seem to bother with authentication schemes that are compatible with unsecured streams. They seem to like to send all creds in plain and just use SSL/TLS. So transport level security is a must for talking to their IMAP server.
Much to my chagrin .NET CF WCF does NOT support TCP or streaming mode for that matter. Seems my only option is to try and dig into some of the CE socket libraries.
There have been multiple times working with .NET CF where I have been balked by not being able to easily set up an SSL stream over TCP. I’m hoping that .NET CF’s WCF subset will help me put an end to this. From my knowledge of WCF (the full version), I believe I should be able to create a custom encoder so that I can just read and write strings over SSLed TCP. For the particular application I’m thinking of, I’m trying to talk to an IMAP server from Windows Mobile, so I really only need to send back and forth strings, with crlf representing the end of a message.
It seems pretty straightforward, but I’m not sure .NET CF’s WCF supports SSL for TCPTransport, or whether I have the same extensibility points as in the full WCF. So I’m curious as to whether I’ll hit a stumbling block. We’ll see.