Hey folks! Mailspring maintainer here — glad to see this on Hacker News. For anyone just catching up, here's the tldr on Mailspring:
- It's a fork of Nylas Mail with the entire mailsync codebase
(~40k lines of JavaScript) replaced with a new C++ core based on Mailcore2. It uses roughly half the RAM and CPU of Nylas Mail and idles with almost zero "CPU Wakes" thanks to new C++11 features, which translates to great battery life. You might not even notice it's an Electron app.
- 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.
- The pro features still cost money ($8/mo). The goal is to use revenue from subscriptions to pay maintainers (myself, possibly other folks!) to maintain Mailspring indefinitely and/or put bounties on popular feature requests.
- The roadmap and website are still being assembled, but there's some really cool stuff in the works. Launching it and polishing the new C++ sync codebase is just step 1.
Current Airmail user here. Have given Nylas a look in the past and will definitely check out Mailspring. Friendly advice: I am all for paying reasonable prices for quality software, but I think you may run into trouble pricing the pro version as a subscription, or at least as an $8/mo subscription.
Going by Nylas' blog post last month, they say new development of the Nylas mail client is sunset, and the team was reallocated to the API product, which is doing better commercially? https://www.nylas.com/blog/sunsetting-nylas-mail-development
Really like it so far, but there is one nitpick that is bugging the hell out of me.
I can't "snap" or maximise the window on Windows (Win7). Because I have a decent sized screen I often just maximise to half screen for most applications, but not having the standard resize tools is frustrating. Edit: This only happens if I have the Reading Pane enabled.
Running version 1.0.1-ba1d6734.
Is this something being worked on? Or just a bug hitting me? Or just not something other people have asked about?
The RAM and CPU usage is interesting, I think most of the people hate electron apps for their thirst of resources.
Just by looking at the activity monitor I'm curious what's the emptyWindow process.
Have you gotten in touch with the Nylas-mail-lives crowd? Their fork seems less goal-oriented than Mailspring. I’m sure if you invited them on board they’d be happy to join forces.
I'm someone who usually works in C/C++ and more system level things. A roadmap, and a set of already run benchmarks, for the different pieces of the codebase would be very useful to point someone like me to where we can be useful. A roadmap is also nice too.
The Social|Promotions|Notifications|Forums tabs (and its automatic classification) is something I can't seem to live without. There is a way to replicate that (automatically in Mailspring). I think this is my main and only blocker to think on a permanent move! Congratulations on the work.
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.
Strange, wasn't this one of those security focused clients? or am I mistaking it for something else? This is a big oversight as I find it's the ideal format for PGP emails and I find it forces me to keep things simple and minimal.
There are no Linux download links. The download page just shows image placeholders.
But if you send an invalid download request like ".../download?platform=foo" then you get back a handy JSON error string indicating that the Linux downloads are:
Hey folks! bengotow here—the linux version is /almost/ ready, though the debian and rpm packages above should work. I'm working with some folks at Canonical to get the app packaged as a Snap (Snapcraft.io) so that Linux users will finally get autoupdates and I can ship a single format to everyone. Back when I worked on Nylas Mail, we had a ton of trouble with Linux because users would download a .deb or .rpm and then never update it, so I was hoping to stop distributing those entirely.
Feel free to grab the version from the link above, just come back and switch to the auto-updating snap when it's ready!
Just wanted to express thanks for continuing to support Linux reasonably well. I regularly use all 3 major platforms and hated that webmail was one of the only ways to get a somewhat-consistent interface across them; this is one of the things that drew me to Nylas in the first place before issues with a self-hosted sync engine pushed me away.
The right approach is to include your own package repository in the deb file so that it gets automatically added to the system when people install the application.
Do a favour folks for your non-technical friends. Show them how to turn off image loading by default in their mail client. And how to check link destinations in emails before clicking on them.
People need to know how to protect themselves from abominations like 'Open tracking' and 'link tracking'.
Can this so plaintext and operate without contacting a third party? There are a few "features" in this that worry me. One being the Open Tracking.
The client looks great and I'd like to use it but I frankly don't know what I'm getting. With Thunderbird other solutions you know what it's doing and how. Some of the features of this are a little strange for someone like me.
Hey! Mailspring maintainer here—the app doesn't support plaintext emails (at least not out of the box), but it's likely we'll add support in the future.
A lot of the features in the app, like read receipts and link tracking, are targeted at sales and business folks that send a lot of email and care about it being read. You can use the app without using them though! Unlike Nylas Mail, Mailspring implements all mail sync on your computer - your email credentials are not sent to the cloud and things like "unsnoozing" happen on your machine, not on a server. (Note that for many people, this is actually a /bad/ thing - if enough folks complain we might add the cloud sync stuff as an opt-in!)
Plaintext is a must for many users. So is encryption. I really hope you implement that. If you do I'll switch to this client and I think many others will as well.
My spit, bubble gum, and duct tape mess of an email client (Thunderbird with one too many plugins) needs to be replaced.
> the app doesn't support plaintext emails (at least not out of the box)
What does that mean - only support gpg/smime encrypted email, or only support the html-part of a multipart message, with no option to edit/send or view the plain/text part? (ie: you can't communicate with any sane mailinglist using this)?
[ed: and does it work with text/plain at all - or does it effect not support email, sending empty text/plain parts?]
It's awesome that you've implemented unsnoozing on the client side. That's a major plus and I'm hoping to recommend mailspring to my team after giving it a try.
Nylas (like other apps e.g. Airmail) kept the password on their servers (Nylas ID, now it's Mailspring ID) so basically they had (could have) access to all my data even when it's not lying on my computer.
I asked them about it and they never replied. I wish it was just a native (or not) IMAP client and I definitely want out of those Link and Open Tracking features.
---
but for now Mailspring needs to target paying customers with great pro features so I can continue working on it full-time. The Mailspring ID is a core component of these Pro features and a lot of exciting stuff on the roadmap, like team templates, read receipt analytics and shared folders. Unfortunately, it doesn't make sense to remove the Mailspring ID and make the mail client better for you, because it pulls us further away from doing a great job on the pro features for paying users that will ultimately make this a long-lasting open source project.
Hope that helps! I'm going to flag this as a wontfix for now, but I welcome everyone's thoughts and feedback here.
---
Hey folks! Just to be clear, Mailspring does /not/ send your email credentials to the cloud - all the mail sync is done locally, and your passwords are stored in your system keychain / keyring. I spent a good chunk of time re-implementing things like snooze and send later to work without a backend server.
That's actually mentioned a few sentences before the quote above in that GitHub issue ;-) The Mailspring ID stores metadata for things like read receipts and link tracking, but that's pretty much it!
- What if I am sending an email to a person who doesn’t use Mailspring? Can the tracking still be achieved? I am don’t know the technical details of how email works but I believe it can’t be done unless the mail client adds something to the mail being sent. Right? So how does it work with Mailspring IDs?
- Can I opt to not track my mails/activities and not be tracked too?
- What all the meta data leavea my local system and goes to Mailspring? Is there a complete list somewhere? Also how are they stored on your serves?
Apologies again for posting incorrect info about your OSS.
I see there that the actual IMAP sync is done in the client, with the Mailspring ID relegated only to extra 'features' like spying on recipients. So it might be possible to fork it and just pull out the Mailspring ID stuff? It's a big codebase though, so much depends.
Not something I'd be interested in as I don't need another Electron app (I think it is?) on my machine, but if someone had a particular liking for this it might be doable.
Browsing through mailcore2 [1], it looks like this would not support arbitrary IMAP flags. So far I have found only a handful of mail clients that can support them: MailMate, MailTags (brittle extension for Mail.app), and support for flags through folders if you happen to use Gmail as a server.
I like the UI and some features of Nylas, and thus Mailspring. But the fact I need a third party server worry me.
I would love an open source native mail client that do all the syncing locally
Is it just me or is the "onboarding" process too stupid to understand being run on a computer behind a proxy? I can't find any settings so I just get a fairly pointless failure message.
SMTP authentication may be buggy. I can't connect to an AppRiver account via IMAP and SMTP, but am able to connect to a more traditional Linux-based IMAP/SMTP setup.
Yeah—something is definitely up with SMTP auth on Linux. I have a few test accounts it seems I can connect on Mac which are not working on Linux... stay tuned.
I've installed a few updates, but it still doesn't work. Now mail fails to sync with the accounts I had setup, particularly with my NAS sitting right across my desk on a direct LAN connection.
Too bad, I've been wanting to replace Thunderbird for awhile and Mailspring looks promising, but doesn't seem quite ready yet.
Hey! Mailspring maintainer here—could you elaborate on the "open core model"? I'm not sure I follow. If it'd generate more than $~10k/mo in revenue and would allow me and others at F376 to sustainably work on Mailspring indefinitely, it might be a great alternative to the Mailspring ID and pro features.
- It's a fork of Nylas Mail with the entire mailsync codebase (~40k lines of JavaScript) replaced with a new C++ core based on Mailcore2. It uses roughly half the RAM and CPU of Nylas Mail and idles with almost zero "CPU Wakes" thanks to new C++11 features, which translates to great battery life. You might not even notice it's an Electron app.
- 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.
- The pro features still cost money ($8/mo). The goal is to use revenue from subscriptions to pay maintainers (myself, possibly other folks!) to maintain Mailspring indefinitely and/or put bounties on popular feature requests.
- The roadmap and website are still being assembled, but there's some really cool stuff in the works. Launching it and polishing the new C++ sync codebase is just step 1.