TL;DR: Devs, please read below for my SSL concerns. Everyone else, give Inky a try; it's a surprisingly nice and full-featured email client hiding behind a deceptively simple UI.
I'll bite. I'm a sysadmin who gets gobs of email per day. Maybe I'm not part of your target market ("Simple! Just works!"), but I'll offer my thoughts in hopes that they're useful.
I've tried it for a bit. Here's what I like about Inky as a mail client:
- Vi default keyboard shortcuts :)
- The dialog for adding arbitrary IMAP servers is outstanding. Leagues better than Thunderbird. For those who haven't tried it, you type in your email address, then it looks up the servers in the MX records of the email's hostname. You click an "Allow" button next to the server that you actually intended to send your password to, and it starts using that server. Excellent.
- AUTOMATIC UNSUBSCRIBE BUTTON. Dude. Maybe this is common in other mail clients but I just spent like ten minutes unsubscribing myself from useless things. Click, click, click. It's catharsis in a box. This alone made my brief spin with Inky worth my time.
- Nice UI for viewing and editing settings. Surprisingly advanced options for eg. caching, displaying and downloading messages, keyboard shortcuts, and so on hidden in the settings.
- Didn't interfere with my other email clients, as promised.
Security issues that I don't like:
- You didn't even warn me when I added my mail server with a self-signed SSL certificate. Sure, the UI does imply that you're not sending my password to that server before I click the "Allow" button, but there's no way for me to even check the SSL certificate fingerprint before I do that.
- You also didn't let me know whether I'm using an SSL/TLS connection at all.
I expect any decent email client to loudly complain about security issues like these. Inky is a broken email client until it does so.
- Storing my IMAP password on your cloud server is not OK. I know my passwords are encrypted with my Inky password, but that's exactly what I'm sending you whenever I log into my Inky account. Thus, Inky employees can access my email if they watch me authenticate with your servers. I'm not convinced. You've ensured that adding new mail accounts is stupid easy, so why are you "helpfully" keeping a copy of my password for me? At least give me the option of storing passwords in my OS keyring. I'd like to know more about the security of this system and your motivations for doing this.
UI things that I don't like:
- Bug: I add a server, then I click on "Compose message," then I add another server, then click back to my message that I previously started to compose. You don't list the new second server in the "From:" dropdown menu, so I thought I didn't add the new outgoing server properly. I have to scrap that message and start composing a new one before both servers show up in the "From:" dropdown.
- You treat an email thread as a linear list of messages. Email threads have inherent hierarchy and structure. I can't see who's replying to who without expanding the quoted parts.
- You group emails together by subject. I have 1,000 nightly automated server emails per each server accumulated over the past five years. Please don't group them together like that.
- In mailing lists, it's conventional to have "Reply All" as the default action, not just "Reply." I'd love if you detected that.
- Please infer my address book from people in my inbox who sent me things. I don't want to type all that again, and it looks like there's no visible way for me to import contacts. Slurping up contact details when I send messages to people would also help with this.
- In threaded email lists, there's so much whitespace that I can't tell where a message ends and where the next one begins. For example, how many emails are visible on the right side of this screenshot? http://i.imgur.com/92cKQ.png
- There's also way too much whitespace in the message list. I could only see 10 messages in my screenshot, which really hurts when I'm scanning through search results. (EDIT: I accidentally clicked on the date header and it gives you more layout options to condense things down)
- This is currently a free product. How are you making money?
It doesn't work on Linux, so I can't use it day-to-day. That said, I really like what you're doing here, and it's certainly a great start. Until then, I'm headed back to Notmuch ( http://notmuchmail.org/ ) for the time being.
Im interested in this space as well so I am curious to poke your brain for a bit, if you dont mind:
> you type in your email address, then it looks up the servers in the MX records of the email's hostname
The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?
> AUTOMATIC UNSUBSCRIBE BUTTON
This sounds interesting, but how would this work? Often times there are forms that the unsubscribe link leads to, how would it be able to correctly populate and send it?
Furthermore, in my experience, these links dont usually work and the better solution is to forward all mail from that source directly to junk mail. Is your experience different?
> Nice UI for viewing and editing settings. Surprisingly advanced options for eg. caching ...
Do you actually use these? Do you really care how long a message is cached for? I feel like most of these confuse the average user (obviously not you) and provide little value for the more advanced users.
> Didn't interfere with my other email clients, as promised
Is this an issue? How does this happen?
> You didn't even warn me when...
What is the average users response to such a warning? Heck, would you know if there were a man in the middle given the warning? I think that this is one of the shortcomings of the PKI: most warnings are false alarms which lead to mistrusting the system.
> The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?
My IMAP and SMTP server happen to be hinding on the same IP, which is mentioned in the MX record. Inky seems to have detected this. Port scanning? Trying common names like smtp.$domain and imap.$domain ? I'm not sure how it does this, but someone got very frustrated when coding it :) and it works quite well as a result.
> In my experience, these [unsubscribe] links dont usually work and the better solution is to forward all mail from that source directly to junk mail. Is your experience different?
I'm not sure how Inky discoveres the presence of an unsubscribe link, but the experience is outstanding. Here's a quick walkthrough. Say I want to unsubscribe from this message:
This message happens to contain a "List-Unsubscribe: <http://.../>, <mailto:unsubscribe@...>" header, but lots of the ones in my mailbox do, so either it's common or Inky has other special sauce going on.
I don't know if this works just for messages with a List-Unsubscribe header or if it's scanning the body text of the email. For the record, that mail had "If you do not wish to receive further communications like this, please unsubscribe [here.]"
Other mail clients: Please copy this mercilessly!
> Do you actually use these? Do you really care how long a message is cached for?
Sure, they're confusing for average users; that's why they're in the settings. No average user ever opens the settings, but I like that they're there. They've thought about a lot: if I send mail to people who use terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert dashes to unicode characters" and "Convert emoticons to images as you type." Lots of people who use mailing lists will gladly appreciate the "Put new text below quoted text in replies (bottom-post)" setting. And I can turn off sounds and notifications so I don't get distracted by my mail client.
Yes, having these really does provide value for advanced users. (Erm well, for me anyway)
>> Didn't interfere with my other email clients, as promised
>Is this an issue? How does this happen?
I've tried mail clients that download all the mail, mark it all as read, and then promptly delete it from my server's inbox, either due to misconfiguration or poor design. Inky is a "thin" IMAP client, so there's no reason to add much client-side state. Everything you do to a message is immediately applied to that message as it exist in the server's copy -- marking it as read, moving it around, and so forth. This has the disadvantage that it probably won't work if I disconnect, but I like the uncompromising philosophy of not touching my mail unless I tell it to.
> What is the average users response to such a warning? Heck, would you know if there were a MITM?
It's the burden of the mail client to word the warning in such a way that it tells users what's happening without scaring them away. For example, I'd love if clients say something lighthearted in the warning message like "If you're at a coffee shop right now, please wait until you get home to check your mail; something phishy could be going on..." to give people an intuition of what they should do while encouraging them use their heads.
The reason why people trust PKI more than they should is because we teach them to click through scary certificate warnings. Thunderbird throws "UNTRUSTED CA" jargon at your users' face. They just want to check their mail, so before long, you've conditioned to treat the "Confirm security exception" button as a "Make my problem go away" button. It takes them to your inbox without any visible consequences, so they think to themselves that the scary certificate warning must not have been a big deal.
Still, though, any warning is better than nothing. At least if someone's account gets stolen because they clicked through a PKI warning, they might have some idea when it happened.
Right now, Inky does not warn me if I add a NEW server with a self-signed SSL cert. If an attacker can be there right when I'm setting Inky up, I've just given him my password. (Read dmbaggett's security clarifications elsewhere in the thread though; it's not as bad as I originally thought it was)
Wow, thanks for the insight and the effort in the response!
> terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert dashes to unicode characters" and "Convert emoticons to images as you type."
Emails are normally sent with a mime type of multipart/alternative with two subtypes of text/plain and text/html. Therefore, for your terminal using friend it would simply look at the text/plain version instead of the html version. Im sure you already know this, but what I am trying to illustrate here is that I believe that all of these details should be managed by the technology as in this case: the client which has a hard time displaying images etc should use the text/plain version.
> "Put new text below quoted text in replies (bottom-post)" setting.
This is interesting. I remember when I was in a corporate network I got about 300 emails/hour from one mailing list. Now, the client I was using then had a view that looked like a forum where you could see an email and its responses below and indented. When I wanted to follow a thread, having bottom posting was annoying because I'd have to scroll through the quote. On the other hand, If I were jumping between threads, then it was useful. I wonder if there might be a better approach which separated the quote from the response and allowed the client to display the quote when necessary.
Do you understand my line of thinking or am I entirely crazy? Are there any options that you feel cannot or should not be managed by the client? Do you believe in this idea that the client should do as much as possible?
As far as the security stuff, I'll try to break down my thinking.
Variables to account for: valid/invalid, same as known/different from known, self signed/trusted signer/untrusted signer/unsigned.
Errors in each variable mean different things and have a different chance to occur under normal conditions. For example, if the cert is plain invalid (e.g. the trusted signers signature is incorrect) this almost certainly indicates malice as opposed to the cert being different than what is currently known. This is opposed to having an untrusted signer or a self signed cert where it is possible (and almost likely) to have occurred either out of ignorance of the issuer or their simple denial to pay large sums of money for a valid cert. Furthermore, it isnt entirely uncommon for servers to switch their keys due to some security hole such as a problem in the key generation algorithm. Since the PKI provides no express way to state: this server is switching its keys, we simply take it on faith. You might think that this is unnecessary since we trust the signer, but CA's have been compromised before.
The problem of no visible consequences I feel is also mishandled. If you get the initial warning at a cafe and you click through and then later at home, you get a trusted signer different from what you had at the cafe, a warning should pop up that your information was probably stolen at the cafe so you can at least change your passwords.
There is a hidden problem here of dns hijacking. This is actually done commonly at "pay-for-your-wiki" places. They do not have the intention of stealing your information, but they will case security problems since they will pretend to be google.com or whomever else until you pay for the internet. I suppose that the browser should check the entity of the cert and if different from the requested entity, treat it as a redirect. This whole situation, however, requires more thought.
All in all, I feel like technology is burdening the user by trying to make the user understand the technology and not the situation. Sorry if I rambled too much, but what do you think?
> The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?
It's useful information to guess what the mail servers may be before displaying options to the user.
For example, doing an MX lookup against the domain of email@example.com would show that the domain is hosted on GMail.
Doing an MX lookup against inky.com returns smtp.arcode.com. Now if you do DNS lookups against mail.arcode.com and imap.arcode.com you'll find they both have A records. imap.arcode.com is listening on port 993 (IMAPS) whilst mail.arcode.com isn't listening on any imap port. So you might want to display imap.arcode.com as a possible option.
Automatic unsubscribe can work for example via the RFC 2369 List-Unsubscribe header. For example Gmail uses that to show a unsubscribe dialog when you mark a message as spam. Of course you need to use your own judgment on which messages to trust enough to even try unsubscribing from.
Thanks; this is great feedback. A couple responses:
- See security comments elsewhere. Inky does not send our servers your Inky password.
- Grouping emails by subject: email threading information is pretty broken in practice; many clients don't populate References: properly, and Outlook uses its own thing called Thread-Id. So we have to use heuristics in many cases.
- Email thread structure: you're the only person who's ever asked us for this. GMail's pretty much killed real threading as a design.