Sure, I'll run though these. You can also ping me at mg@inboxapp.com.
1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.
2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.
3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.
Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.
4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.
Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.
We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.
[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.
It might be simpler to just use a regular SMTP server and procmail or equivalent to deliver to Inbox, with fallback to local mailbox on failure to deliver, which Inbox could then sync. No need to reinvent the wheel here.
1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.
2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.
3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.
Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.
4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.
Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.
We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.
[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.
[1] https://github.com/mailgun/flanker
[2] https://groups.google.com/forum/#!forum/inbox-dev