I used and loved Nylas Mail (aka N1), so I'm going to be taking a close look at this.
For the record, my needs in a mail client are: GUI, very clean UI, pretty themes, good search, works with gmail, ideally supports snoozing emails (a key feature if you like to pursue Inbox Zero), if at all possible should be a desktop app for OS X and Windows, and I wouldn't be adverse to open notifications and such. Also, I'm explicitly fine with their being an extra server in the mix; this is more-or-less required for snoozing emails to work properly[1], and I'm not really concerned about privacy.
If that describes you, you might like Mailspring too. If not (and I suspect that'll be the case for the median HN visitor), then probably not. :)
Edit: Totally forgot, I also have a strong need for supporting multiple email accounts. A merged inbox view that will automatically use the correct email address/signature for replying to an email based on where the original email was sent is critical.
[1]: At least, every implementation of email snoozing I've seen had relied on a third party server. And once I got addicted to it with Dropbox's much-mourned Mailbox app, I've found it very hard to use a mail client without it.
At FastMail we’re hoping to implement snooze next year, as a first-party solution that doesn’t need the support of a client or third-party server.
There is no established convention or standard for representing snooze over IMAP. There’s not yet any consensus on how to represent it in JMAP, the emerging standard that we’re backing (and which our web UI will be using fairly soon), either. It’ll be a FastMail-specific JMAP extension at first, but it could well be standardised (though not in the core spec) after that. We’ll see how things go.
I haven’t been working on the JMAP stuff (I only started working there this year and I’ve been focusing on our new product Topicbox), so I’m not aware of all the details; but JMAP standardisation is going through the IETF, so you can see things that are happening with it at https://datatracker.ietf.org/wg/jmap/documents/ and https://github.com/jmapio/jmap/issues.
> I'm explicitly fine with their being an extra server in the mix; this is required for snoozing emails to work properly
Out of interest, why would this be so? On the face of it a single client can keep its own snoozing metadata and use a helper process to do the work. I suppose if you want to ensure snoozing works across clients, you'd need a slightly clumsy workaround for the metadata (eg. encoded somewhere in the snoozed mails in a special IMAP folder). But it looks doable from the perspective of a shallow moment's thought. Admittedly, pretty much everything generally does.
I'm really not sure to be honest. It does seem like you could do something weird with IMAP to make it work, but every implementation I know of uses a server.
If your client(s) handle the snoozing, copy "snoozed" messages to the "Snooze" folder (like "Draft", "Sent") - and check the date/time before copying it back to the "Inbox" as unread? If there's no meta-data readily availabile over IMAP (last modified...), maybe use "Snooze/deliver-at-1205-10102017" - a subfolder for each time slot?
I don't know IMAP beyond the very basics, but I presumed that it doesn't include facilities for adding metadata. Correct me if I'm wrong! So if you wanted to store snoozing info, you'd have to encode that oddly somewhere -- in a fake email item name? Or as an added mail header (if it's considered polite for clients to add them)?
You can't write headers to messages you receive.The only way is to download the message (including the three 78MB PDF attachments you got from that graphic designer), add the header field, upload everything and delete the first message.
But if your longish snoozes end at the same time, you can use a flag.
(IMAP's cache semantics say: If you download a part of the message it stays valid. Other people cannot change what you have downloaded.)
I don't think so, since gmail had labels before they added IMAP support. Also, when accessing gmail via IMAP, you see the labels as IMAP folders, which leads me to believe that they just bolted the IMAP interface on top of whatever backend they use to store messages internally.
I have used the subject for metadata as a way of storing backup files in IMAP. You can also use tags and as someone else mentioned you can do all sorts of things with headers.
I prefer desktop clients (even the horrible electron things that pass as such these days), and I'm not thrilled with gmails UI which I find a bit cluttered and frustrating. It also doesn't support email snoozing, which I love.
Google Inbox is a better UI, but goes too far the other way towards wasting too much space. It's also missing some key features, and is still not a desktop client.
Also, neither one of them supports showing emails from multiple gmail accounts in a single inbox (unless you just blindly forward emails from one to the other, which you can do, but I'd rather avoid).
I recognize I'm being very picky here; mostly what I just want is Dropbox's Mailbox app, but they killed that off long ago, much to my eternal disappointment.
Snoozing emails removes them from your inbox for a set amount of time.
Imagine you read emails in an unread folder, where read emails disappear. This basically would functionally mark them as read until a preset amount of time passes, then they show up as unread again. It's a bit like that, only in your inbox itself.
It's not actually a part of the email specifications, but some people seem to like it.
Obvious implementation: use IMAP to create a folder, snooze-$timestamp. Move messages there. Every so often, check the snooze-$timestamp folders and present every one where the timestampt has expired as part of the unread group. Delete empty folders.
> - It still has the same great pro features, like snoozing and send later, but doesn't send your email credentials to Mailspring servers. All of these features have been re-implemented to run locally on your computer.
It doesn't require a third-party server. Nylas did do it that way, but Mailspring aren't. It's local.
Yeah, it seems easy enough to do client side unless one wants it to be synchronized across devices. Then, I imagine it'd be easy for the email provider to do, though it'd need client support or to be in the browser.
Gmail has limited support for multiple email addresses. For people like me with a lot of inboxes it isn't sufficient. There is also a pretty significant delay on any non main account addresses.
For the record, my needs in a mail client are: GUI, very clean UI, pretty themes, good search, works with gmail, ideally supports snoozing emails (a key feature if you like to pursue Inbox Zero), if at all possible should be a desktop app for OS X and Windows, and I wouldn't be adverse to open notifications and such. Also, I'm explicitly fine with their being an extra server in the mix; this is more-or-less required for snoozing emails to work properly[1], and I'm not really concerned about privacy.
If that describes you, you might like Mailspring too. If not (and I suspect that'll be the case for the median HN visitor), then probably not. :)
Edit: Totally forgot, I also have a strong need for supporting multiple email accounts. A merged inbox view that will automatically use the correct email address/signature for replying to an email based on where the original email was sent is critical.
[1]: At least, every implementation of email snoozing I've seen had relied on a third party server. And once I got addicted to it with Dropbox's much-mourned Mailbox app, I've found it very hard to use a mail client without it.