Roadmap/devlog and general discussion

[notpushkin]

• [ ] CI/CD (#2)
• [ ] Run Wireshark on MailSync process and ensure it doesn't connect to id.
• [ ] Study MailSync <-> Mailspring internal RPC protocol for future replacement (#12)
• [ ] Implement package manager (#13)

Bring back

• [ ] Translate
  • Use Yandex.Translate directly (prompt user for the API key)
• [ ] Localization suggestions
• [ ] Crash reporting
• [ ] Update notifications
• [ ] Investigate: This share button
  • (I'm not sure what exactly does it share?)
• [ ] Thread sharing
  • Current implementation requires an external server
  • Perhaps we can offer to save thread as an .html (and .mbox) and let user host it somewhere?

Properly remove

• [ ] Newsletter
• [ ] API client

Won't fix:

• Link / open tracking: not possible without an external server and isn't ethically OK in my opinion

[alexanderadam]

Awesome work, @notpushkin.

I guess it would be good if this repository could add a GitHub action for automatic building the app for various platforms (for example with action-electron-builder [repo]).

[notpushkin]

@alexanderadam I'm actually planning to gradually move away from GitHub ecosystem but a CI would definitely be nice! There's config for testing on CircleCI already, perhaps we could extend it with a packaging task?

[alexanderadam]

There's config for testing on CircleCI already, perhaps we could extend it with a packaging task?

Sure, it seems that there are various possibilities to push releases automatically.

However, I just saw that CircleCI is just used for tests whereas there's already a task to build release artifacts with Travis

But I don't think there are pushed somewhere else than Travis itself. So I guess it would make sense to reactivate(?) Travis and then maybe just push the releases to GitHub in the end with as described in the CircleCI blogpost?

Are you currently actively using Mailspring Libre? Is everything working as expected?

[notpushkin]

Thank you for your insights! A few tweaks to Travis config should do the trick (it currently fails because of some missing secrets, but that shouldn't be hard to fix). → #2

Are you currently actively using Mailspring Libre? Is everything working as expected?

Apart from the few things outlined above, yeah! I was worried that MailSync would complain but apparently it's not that tightly coupled after all.

[alexanderadam]

I guess other points that should be added to the roadmap:

• [ ] get rid of the closed source Mailsync component and it's questionable license (see also the related issues 24 and 1303) - either you could ask whether Foundry376 will open the source under a free license or it should be replaced
• [ ] GPG/PGP support (see also the related issues 25, 28, 940 and 1240)

[notpushkin]

@alexanderadam I've had PGP in mind too! Re: Mailsync – from my earlier studies it just passes JSONs back and forth, so it shouldn't be too hard to analyze and reimplement. (Thanks for your PRs by the way – I'll take a more thorough look this evening!)

We can also tweak the remove-tracking-pixels package into removing all tracking pixels altogether (it's not a panacea by any means but at least it's a bit of help in cases you want remote images).

[walterchris]

+1 for the PGP Support. So this Fork is for open-sourcing the remaining parts of mailspring and adding features on our own? I'd like to support implementing PGP.

[notpushkin]

Regarding PGP support, https://github.com/NgoHuy/mailspring-keybase might be a good starting point (although it didn't work for me IIRC). Anybody wanna pick it up?

open-sourcing the remaining parts of mailspring

Eventually, I hope so!

Feature-wise, I think what we need is a proper plugin store, so that everybody can setup their client according to their needs. It's in Mailspring's roadmap but apparently it's not coming anytime soon.

[notpushkin]

For those interested, you can grab a stable version with telemetry-removing patches applied here (Linux only for now).

P. S. Nightly builds are now available too! Only for Linux again, PRs welcome for Windows / macOS or (for the brave souls who fear not death) FreeBSD. To grab one, go to Travis, open latest master build and in the end of the log you'll see it in the “Deploying application” section (alright, I know, this could have been easier).

[RaitoBezarius]

First of all, insane and awesome work.

I'll try to watch this repository and contribute whatever I can, don't hesitate to mention me if you want some help for triaging issue or reproducing stuff, testing stuff (I'm an Arch Linux user on amd64 FWIW, I can maintain some upstream AUR package if you want).

@alexanderadam I've had PGP in mind too! Re: Mailsync – from my earlier studies it just passes JSONs back and forth, so it shouldn't be too hard to analyze and reimplement. (Thanks for your PRs by the way – I'll take a more thorough look this evening!)

FWIW, the killing feature of Mailspring is MailSync, as long as MailSync can be reimplemented while thinking about battery life & performance, that'd be terrific.

[notpushkin]

Quick update: master has been updated with some commits from the upstream :sparkles:

[lefred]

If you want to remove all mentions to Mailspring Pro, would you just remove it in the main code or create a plugin that will override the rendering (if possible) ? For example on the sidebar.

[notpushkin]

@lefred Good question! Overriding in plugin would be tricky I guess, but we can simulate Pro subscription by just setting the respective option in our identity JSON — this should remove most of the mentions. Going further, we'd probably want to remove them altogether, but this is not the priority right now.

[notpushkin]

Status update: I have translation working locally, but yet need to expose the API key field in the UI.

I also want to release this as a separate package, but it uses cld which can't be compiled into the js code and isn't exposed so it can't be easily used outside of the main codebase. Investigating.

[notpushkin]

Since this fork focuses on privacy, should we replace some of the mail hosts with privacy-focused ones?

spoiler

No, I won't actually include cock.li (because of their domain names) but their privacy policy is pretty good. OvO

Alternatively, I was also thinking about integrating with Thunderbird's Autoconfiguration standard – this way, we can skip this screen altogeher and just let users type in their email and password and we can pick it up from there. Thoughts?

[RaitoBezarius]

Thanks for not including cock.li ; I was pretty shocked to see this domain again. :(

On Wed, Feb 26, 2020, 21:39 Alexander Pushkov [email protected] wrote:

Since this fork focuses on privacy, should we replace some of the mail hosts with privacy-focused ones?

[image: image] https://user-images.githubusercontent.com/1298948/75385087-2edf4180-58f0-11ea-919a-4949d9201d09.png spoiler No, I won't actually include cock.li (because of their domain names) but their privacy policy https://cock.li/privacy is pretty good. OvO

Alternatively, I was also thinking about integrating with Thunderbird's ISP database https://github.com/mozilla/ispdb – this way, we can skip this screen altogeher and just let users type in their email and password and we can pick it up from there. Thoughts?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/notpushkin/Mailspring-Libre/issues/1?email_source=notifications&email_token=AACMZRB4GUUCHLOIB52NSU3RE3HR3A5CNFSM4KL6FV4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENBZNWA#issuecomment-591632088, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMZRCOULEERDQFVEPWZQ3RE3HR3ANCNFSM4KL6FV4A .

[notpushkin]

Sorry for that :( Not the best joke idea, yeah.

[RaitoBezarius]

No worries :) We can go for ProtonMail, some classical stuff I believe :)

[louis-lau]

I thought it was quite funny 😁

[RaitoBezarius]

Supporting cock.li is akin to supporting rape.lol or hitler.rocks ; it's difficult :(

On Feb 26 2020, at 10:47 pm, Louis Laureys [email protected] wrote:

I thought it was quite funny 😁

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/notpushkin/Mailspring-Libre/issues/1?email_source=notifications\u0026email_token=AACMZRHD2ZR53LDWPTJS4WTRE3PO7A5CNFSM4KL6FV4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCARFI#issuecomment-591661205", "url": "https://github.com/notpushkin/Mailspring-Libre/issues/1?email_source=notifications\u0026email_token=AACMZRHD2ZR53LDWPTJS4WTRE3PO7A5CNFSM4KL6FV4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCARFI#issuecomment-591661205", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[notpushkin]

Personally, I really dislike ProtonMail for its proprietary encryption standard and business practices: even if you wanted to use custom client, you'll have to pay for their IMAP bridge – which is another reason it doesn't make sense to add it :(

A few providers I've had in mind:

• Disroot
• Riseup (currently invite-only)
• ~~Tutanota~~ open-source but doesn't support IMAP for the same “encryption” reasons as ProtonMail, sad
• Migadu (starting at 4 €/mo, Switzerland-based)

Now that I've thought about it, it would make sense to invite users to sign up for those instead, for existing users the Thunderbird-based “enter email/password” flow should be easier:

[RaitoBezarius]

I didn't know about this, actually. This is super relevant. I totally agree!

On Feb 27 2020, at 12:02 am, Alexander Pushkov [email protected] wrote:

Personally, I really dislike ProtonMail for its proprietary encryption standard and business practices: even if you wanted to use custom client, you'll have to pay for their IMAP bridge – which is another reason it doesn't make sense to add it :(

A few providers I've had in mind:

Disroot Riseup (currently invite-only) Tutanota Migadu (starting at 4 €/mo, Switzerland-based) Now that I've thought about it, it would make sense to invite users to sign up for those instead, for existing users the Thunderbird-based “enter email/password” flow should be easier:

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/notpushkin/Mailspring-Libre/issues/1?email_source=notifications\u0026email_token=AACMZRH5XI3LTBRUKCTC4ITRE3YJ7A5CNFSM4KL6FV4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHMBY#issuecomment-591689223", "url": "https://github.com/notpushkin/Mailspring-Libre/issues/1?email_source=notifications\u0026email_token=AACMZRH5XI3LTBRUKCTC4ITRE3YJ7A5CNFSM4KL6FV4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHMBY#issuecomment-591689223", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[notpushkin]

Implemented in 39ec192. Feel free to check it out once it builds!

[lefred]

Nice, where can I download the draft rpm build ? Btw, do you plan to rebase or cherry-pick from upstream for bug fixes ? Cheers

[alexanderadam]

Personally, I really dislike ProtonMail for its proprietary encryption standard

Can you elaborate on that? Because I thought they are using openpgpjs for encryption? Also their client and most (or all?) of their view components seem to be open. The same is true for Tutanota.

Or do you mean that they don't expose IMAP for fetching emails (which IMHO isn't related to encryption)?

[notpushkin]

@lefred The packages are built for each push to master! You can find them on the build page under Deploying application section. Here are the most recent ones: rpm, deb

@alexanderadam They do, just in an incompatible with other clients way :') To encrypt to outside clients, they had to invent some kind of an intermediary page. The same is true for Tutanota. And yeah, ProtonMail indeed is open source too – didn't know about that!

Anyhow, they both state some good reasons, like PGP not being resistant to quantum attacks, but in my opinion this doesn't outweigh the fact that you can't easily encrypt an email to somebody on another host.

[alexanderadam]

they had to invent some kind of an intermediary page

This is not the regular mail encryption support though. This is just if a ProtonMail user sends a message to someone without GPG/PGP. It will use PGP if the PGP key of the recipient is known.

You are right for Tutanota, though. They don't support PGP.

Anyhow, they both state some good reasons, like PGP not being resistant to quantum attacks, but in my opinion this doesn't outweigh the fact that you can't easily encrypt an email to somebody on another host.

Thank you for answering. I absolutely agree with that. :+1: I one wrote about my opinion about email security in another comment.

[notpushkin]

Looked into PGP implementation and it seems that it proper PGP/MIME signatures won't be possible without changes to mailsync :thinking: (https://github.com/NgoHuy/mailspring-keybase seems to do PGP Inline, which is OK but undesirable). PGP/MIME encryption could work though.

Explanation: mailsync (I believe) treats multipart/encrypted and multipart/signed just like standard emails with attachments (which is reasonable). Encrypted emails have no text/* part so Mailspring renders no body at all and writes everything (encrypted.asc and another part without filename, PGP/MIME version identification) as attachments to disk, so we can just read and parse it. For unencrypted messages however this isn't possible – they have a body part and the signature (application/pgp-signature, called signature.asc). The problem is that we can only get body as a sanitized string and not as raw bytes, so we can't check the signature. Bummer.

On the bright side, I believe there are some PGP-related developments in the upstream repo, so we might as well see it included after all!

[Panzki]

Hi, I stumbled upon this project a few days ago, when checking once again if mailspring allows usage without creating an account. This is my main pain point with mailspring, I don't want send my data to some third party service. What's the current state of this project regarding the removal of the third party service from the client?

[notpushkin]

@Panzki Right now it works without the Mailspring account and tracking calls should have been removed, although we still need to do more thorough testing of the Mailsync part. Some functionality is lost – mainly the things that depended on the Mailspring servers.

If you're on Linux, you can try out the latest master build (deb, rpm). For other platforms you'll have to build from source right now (PRs welcome!)