4 ms·

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 serv

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.

mike-cardwell 14y ago
> 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 postmaster@ycombinator.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.
- dmbaggett 14y ago
  Sorry; hit down arrow when I meant to hit up. You are absolutely right.
jsnell 14y ago
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.
gcr 14y ago
Sure! I don't mind. > 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: http://i.imgur.com/XlB3X.png http://i.imgur.com/XlB3X.png This message happens to contain a "List-Unsubscribe: <http://.../> 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. After clicking the unsubscribe button, it offers to unsubscribe via "automated email" or "via the web": http://i.imgur.com/c7KXj.png http://i.imgur.com/c7KXj.png If I click the first, it offers to send this message for me: http://i.imgur.com/c63fY.png http://i.imgur.com/c63fY.png If I click the second, Chrome pops up with the unsubscribe link: http://i.imgur.com/DUGGk.png http://i.imgur.com/DUGGk.png 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)

mike-cardwell 14y ago

> 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 postmaster@ycombinator.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.

dmbaggett 14y ago
Sorry; hit down arrow when I meant to hit up. You are absolutely right.

jsnell 14y ago

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.

gcr 14y ago

Sure! I don't mind. > 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: http://i.imgur.com/XlB3X.png http://i.imgur.com/XlB3X.png This message happens to contain a "List-Unsubscribe: <http://.../> 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. After clicking the unsubscribe button, it offers to unsubscribe via "automated email" or "via the web": http://i.imgur.com/c7KXj.png http://i.imgur.com/c7KXj.png If I click the first, it offers to send this message for me: http://i.imgur.com/c63fY.png http://i.imgur.com/c63fY.png If I click the second, Chrome pops up with the unsubscribe link: http://i.imgur.com/DUGGk.png http://i.imgur.com/DUGGk.png 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)