Mailspring: A fork of Nylas Mail by one of the original authors | Hacker News Reader

Mailspring: A fork of Nylas Mail by one of the original authors

github.com

155 pointsOperyl89 comments

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.

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.

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.

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.

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?

Seems a bug.

Doesn't work on Win 10 either.

Worked fine in Nylas Mail.

EDIT: macOS version doesn't have this issue.

Hey! This is a bug—should be fixed in 1.0.2 later today: https://github.com/Foundry376/Mailspring/issues/17

Why the fork/split - or rather what happened to the rest of the team?

I see the code is gpl3 - but am I correct that you can't really run it without access to a closed third-party server?

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

> idles with almost zero "CPU Wakes" thanks to new C++11 features

Out of curiosity, what features helped here?

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.

Also, where can I look at the sync engine?

Does it support the Exchange protocol?

Could you please eliminate all the calls for webservers for fonts etc, I don't need those parties to know when I launch apps.

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.

Can you tell me what is wrong with gmail? It seems to check all your boxes.

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.

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.

> It's also missing some key features

I'm curious, such as what?

I think I'm not sure what you mean by "snoozing emails" ? Isn't it just muting for a few minutes the alerts you'd get ? Just to clarify for me.

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.

Thank you. And why does it seem to require a third party server ?

> - 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.

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.

> 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.

Fair enough. It was just an idle thought.

Why is it regarded as weird to use IMAP for this? It seems like an obvious use for IMAP.

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)?

Using a header works fine - making up your own is legal. I've been known to add headers for entertainment purposes.

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'm aware of that. Not saying it is the right method, just that it is the best general method we have.

And I'm also thankful that I trade mail with far fewer designers these days.

As I remember IMAP allows to add freeform flags to every message.

IIRC that's how gmail implements its labels.

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 meant that that's how they implemented labels for their IMAP support, but you may be right, they may be folders instead.

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.

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?

This might be good for you. I haven’t been following along very closely but I believe the concept of a Nylas ID is gone.

https://github.com/nylas-mail-lives/nylas-mail

It's gone for IMAP. Gmail and other instances still contact the Nylas cloud servers, though there are plans to remove those calls.

> At least, every implementation of email snoozing I've seen had relied on a third party server.

At least on Mac there are some client side only ones:

- https://sparkmailapp.com/

- https://canarymail.canny.io/

- MailTags for Mail.app has a “tickle” feature that meets all the requirements

That is from a few minutes searching.

I was under the impression that one of the dings on Spark was that it did use their servers for some of their functionality.

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.

This sounds great - if you're interested in folks implementing the extension in third party clients, let me know!

Which other parties are currently backing JMAP?

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.

That would be awesome. I'm trying transition off of Google services and this would help me a bunch. I love your product by the way <3

I gave it a shot. The app is pretty but has some weird things that will keep me on Thunderbird.

* No plaintext support.

* No "Simple HTML View"—my favorite Thunderbird feature.

* No plaintext view.

* Sets a "Sent from Mailspring" signature that isn't straightforward to remove.

* I don't want to track others reading my mail. It's creepy and I'd rather that functionality not exist in my client. It's enabled by default.

* UI is slow enough for me to notice elements pop-in when I open new windows.

> * No plaintext support.

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.

You're probably mistaking Mailspring for Mailpile (https://www.mailpile.is/)

I was, thanks.

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:

https://updates.getmailspring.com/download?platform=linuxDeb and https://updates.getmailspring.com/download?platform=linuxRpm

Maybe Ben or someone will see this and comment why the links aren't there, since it looks like the github repo has issues filed for this.

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!

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.

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.

I'll definitely be checking out Mailspring.

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'.

I normally suggest reading in plain text, as the default. This may not work for everyone, but I find no use for rich format emails.

It's much better today, but there used to be quite a few vulnerabilities via rich formatted emails.

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!)

> 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?]

afaik atm it doesn't allow to send a plain text email (but it can display them), the only "output" format supported is HTML.

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.

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.

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.

(Edit):

There's a GitHub issue related to it - https://github.com/Foundry376/Mailspring/issues/33

The dev is very clear about it

--- 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. ---

So no, not an email client I would like to use.

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.

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!

Thanks for replying here.

My bad. I somehow missed it.

Since you are here:

- 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.

What makes this better than Apple's Mail? Not familiar at all, just asking.

read receipts + link tracking. if you use it for work, it's incredible. all the other solutions are heavy-handed CRM style plugins for gmail.

canned responses + simple mail-merge style things

downside:

because it's not gmail, search is...not as good as gmail. nothing is.

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.

1: https://github.com/MailCore/mailcore2/blob/f708ce74e23b61ec6...

EDIT: added reference.

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

The syncing is done locally, no credentials are sent to Mailspring for your email accounts.

But you are still reliant on your server for some other reason?

Really happy to hear it ! I try nylas when they get out, but i'm not fine to let them keep their email.

I tried then to use their engine but they deliberately let it die/non working, so I did go back to thunderbird.

It's amazing guys, I was waiting for it since a long time, I have no problem to pay for the app but not for lose my email hosting !

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.

I wish the license was MIT. The author could then have simply made some sort of an open core model instead of resorting to this ID business.

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.

Open core is generally a base free (as in speech and beer) version, and extended version/plugins that aren't. See Sidekiq and Hashicorp's products.

It's about selling non-free software on top of some free base.

MailSpring is looking great, I've heard great things from one of my coworkers about Nylas Mail so I'll have to give this a try ;)

I've been waiting for this! Very exciting!

Couple of things I'm seeing:

- The Markdown composer isn't working.

- I can't install plugins.

Wants me to create an account on their service. Why would that be necessary for a MUA?

What's mailspring ID? Why do I need such a thing?

https://github.com/Foundry376/Mailspring/issues/33#issuecomm...

> Linux Snap Coming soon!

Soon™

Reply on news.ycombinator.com