Opposite stance: please, Mozilla, do not build mobile Thunderbird apps. That's tremendous effort, and IMHO too much for what you can do with the priority on Firefox, even with these new Thunderbird hires.
Focus on polishing and maintaining the existing Thunderbird the best you can with the limited resources you have for the project. You have a large existing userbase that will be extremely thankful for that.
Also, frankly, there are so many email clients out there for Android, that it's a pain trying to finding something trustworthy. Thunderbird would be something I can trust.
It doesn't make me sad, which is the best I can say about it
That being said, I'm rather happy with K9, and I'd certainly prefer to see energy spent in making it even better than in making a “Mobile Thunderbird” from scratch.
Additionally, AquaMail can handle nested folders, which K9 doesn't and never will, according to its developers.
If search works fast on Thunderbird is because it keeps all emails in your local hdd. To be fair you should also set the option account settings > fetching mail > local folder size to 'all' in K9.
100% agreed. Thunderbird for many years was (or was perceived as) moribund and now that it's showing more signs of life people are pushing to add mobile clients as well as desktop? Are those people trying to kill it off?
> On May 9, 2017, Philipp Kewisch announced that the Mozilla Foundation will continue to serve as the legal and fiscal home for the Thunderbird project, but that Thunderbird will migrate off Mozilla Corporation infrastructure, separating the operational aspects of the project.
Just watch the number of supposed independent projects that are created and/or maintained by a small handful of corporations.
And they maintain control what may well be a variant of embrace extend extinguish. Meaning that they churn the code so much with changes that a would be fork has to have the backing of a similarly resourceful organization.
Aquamail is the most feature complete service there was, and now it's been acquired.
A major Thunderbird and Firefox distraction was their shared codebase.
If the new Firefox can do what it can, maybe there could be another codebase that compiles well to multiple platforms, maybe even the first mainstream webassembly app.
But it just isn't thinking far enough outside the box. What they really should do is create an entire Thunderbird OS based on web technologies and XUL, and sell it to mobile phone manufacturers! It could be huge!
I'm full of great ideas. Have they considered that email client interfaces are hard to understand for your grandparents? Maybe they could make it look like your living room, with each piece of email a book on a shelf. And they could have a cute little animatronic talking bluebird that you could ask for help-- call it, I dunno, want something non-threatening... Thunderbird Bob!
One more? Short but sweet-- Thunderbird Vista!
Really, the possibilities are endless.
I'm shocked that there's no mention of the need for reliable out-of-the-box synchronization with online calendars and contacts. (At one point, I tried all the available Thunderbird add-ons for syncing with Google's apps; none worked well for me.)
Even better than synchronization, I would love to have an alternative to existing online email/calendar/contact services.
If Mozilla were ever to offer its own paid email, calendar, and contacts subscription service, powered by open-source code, and backed with strong customer/data/privacy protections, I would sign up in a heartbeat.
It doesn't suffer GNOME disease, it has mail, contacts, calendar, RSS, and if you want, a browser. It's reasonably stable and robust.
My principle preference remains console tools -- Mutt, lbdb, and a mash of other tools, or the Emacs world -- but that's not what the general end-user probably wants.
I've also found Sylpheed is an exceptionally good "just email and contacts" application. Fast, light, and simple.
Before I switched away from Gnome I had Evolution set up. It was slow, you couldn't make more than one operation at a time and notifications worked randomly. Even if you had new email, Evolution sometimes decided not to notify you for days. Reminders and synchronization of calendar and tasks were even worse.
Ditto. I use Apple products and accounts for this, but I recently set up both of my parents with Google accounts (buying them Chromebooks and integrating them with their existing Android phones and Gmail). I don't like having Google having so much of my parents' personal data, but the solution was cost effective and my parents are not on the front lines of the battles over internet privacy.
Apple is decent, but if I could choose an open-source, standards-based Mozilla offering for managing all this stuff I definitely would, for both myself and others.
Email naturally gives rise to contact management; in corporate settings most of this is derived from org-driven data, which can be laid out in a hierarchical directory. These often support LDAP.
For management of personal contacts, this is imperfect. In the mid-1990s, PDAs and web pages made a detached 'contact' datatype useful, so vCard was developed by the Versit Consortium , the makers of vCalendar. These efforts were later transferred to the Internet Mail Consortium, where vCalendar was renamed iCalendar, but vCard kept its name.
Right around this time IETF's RFC 2425  pondered ways to express and map vCard-like contact information in other protocols and applications, like Email and Directories. And work on WebDAV was spun up to bring more structure to distributed authoring with HTTP.
WebDAV was hardly a sweeping success, but it provided a reasonable alternative to proprietary protocols like those of Microsoft, so further work around bringing calendaring and contact management on top of WebDAV continued in the early 2000s. This brought about CalDAV, CardDAV, and GroupDAV, and enabled more of these applications to interoperate.
 https://en.wikipedia.org/wiki/Versit_Consortium  https://tools.ietf.org/html/rfc2425
Now, I don't really think that is a good solution to the problem, but it is the way it is.
Years ago, Mozilla created a calendar application called Sunbird .
For daily schedulings, I use Osmo. My plans and reminders and appointments do not belong on a server.
There's lots of outstanding bugs unfortunately.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1314185 - earliest dependent bug is 8 years old.
Both of those add-ons have always been clunky and brittle for me. They have caused me to miss appointments and have also occasionally messed up my contact data.
I would never, ever use these add-ons for work.
See viraptor's comment for links to reported bugs: https://news.ycombinator.com/item?id=16340039
Fastmail seemed interested for about 5 minutes but nothing came of it.
Trying to sync all this custom stuff across walled gardens (iOS and Android bi-directionl sync for instance) isn't the work of just a moment though. So i understand the reluctance.
Perhaps Thunderbird having its own built in flexible fields setup would be possible but you still really need to sync them to be fully useful.
Support these and it should be possible for any client email app to automatically configure both the email account and address book syncing using existing standard protocols. No need for a new one :)
If they'd fix the security of their sync system, I'd do the same, equally fast. I definitely trust them more than I trust Google, and I wouldn't mind supporting them.
Although, again knowing Mozilla, I guess that there's a chance they'd implement a whole different incompatible account system just for the lulz.
And I use DavDroid off of F-droid on my phone. Calendar sync and Contacts work great on my phone.
Calendar works great on Thunderbird .. contacts .. eh...last I checked there was a SOHO CardDav extension that was kinda garbage. Not sure if that's been improved yet.
I know that mobile is more than Android, but I find K-9 mail to be a really good, open source, mobile mail client.
If I can wish for something, fix this bug from 2009 https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/3... (but originally from 2007)
My opinion is that developing an app for mobile and one for desktop is really two different set of skills and it's not because you've made an awesome desktop app that you will produce an awesome mobile app, vice-versa.
Unfortunately, this is not so much a problem with the quality of the client, but rather with the strangle-hold of big providers over the email system, but users will inevitably complain to the client developers about it.
Fully agree. My point was that most users will disagree with you and I, or simply not really care to consider our argument. And that informs their choices.
Quote from the article:
> When I asked what that might look like the answers were uniformly along the lines of: “There is not a really good, open source, Email client on mobile...
People encountering issues with proprietary crap like Google's XOAUTH2 implementation could well be contributing to this view.
That feature is presented by Google as an alternative "for less secure apps". If you're using a client that Google considers to be "less secure", you also have to explicitly enable support for "less secure apps" in settings, in addition to that. This setting may not even be available to you if you're not on @gmail.com and your domain administrator has disabled it (which Google recommends they do).
Especially the settings, there are Global settings, account settings, folder settings but didn't always show up in the menu.
It's still the lesser of all evils on mobile though.
I can't even imagine trying to run emacs on an on-screen touch keyboard.
As for hook up, there's BT and USB OTG.
I've yet to find a very good contact list for Android.
... and a calendar that works remotely as good as the one of Thunderbird (Lightning).
BTW, Aquamail is free, just not open source. The free version has a few limitations, I think, like a non-changeable signature.
Give me a calendar and/or calendar integration that doesn't suck and I'd be really happy.
I'm making a regular monthly donation because I use this software every day, and I don't want it to go away.
My understanding is that normal donations to Mozilla don't go towards Thunderbird anymore.
JMAP support would be nice too.
- Firefox 59 needs 2s.
- Thunderbird 59 needs 8s.
I completely agree.
I have so many calendars that after launching Thunderbird, it takes around 3 minutes 30 seconds to become responsive to user input, pegging a CPU core the entire time.
And when calendars sync while the app is running (which happens all at once rather than being staggered,) it becomes unresponsive for about a solid minute, again pegging a CPU.
Besides another layout for widescreen I’m happy with it.
There's some kind of irony in people wanting an email client not being into mailing lists. I wonder if it's because Thunderbird ought to handle mailing lists better than it does somehow, perhaps coming up with some innovative UI rather than trying to copy more popular proprietary (and these days mostly web-based) email clients.
It definitely does. Before Thunderbird and Firefox were created, the Mozilla Application suite included a mail & news client (which is what Thunderbird is based on).
What's missing is a LetsEncrypt-style effort to make it easy for people in non-managed environments to get and renew certificates. It'd be really nice if Mozilla & the rest of the industry chose to invest in that infrastructure and some usability improvements to make it more manageable.
This would be especially useful if it extended to browser integration so a user could trivially prove to a remote website that they had a valid signing certificate for a given address.
I'd like to see Trust on First Use used automatically, combined with automatic key generation with no prompting. PGP is probably more suited to this. While it's not perfect, it is possible to retrospectively verify a key and on success consider it perfect. A well designed UI could expose this.
1. Generate a key automatically with no prompting.
2. Sign everything outbound automatically with no prompting (if necessary use the header or rely on a multiple email handshake if you're bothered that users will see an "attachment" they won't understand).
3. Expose "identities" in the UI with information about what incoming mail corresponds to what identities, and what trust has been assigned to individual identities.
4. Permit encrypted email to be sent to identities, whether they are trusted or not.
5. Allow retrospective assignment of trust to identities.
6. Allow users to publicly "join" their identities for when autogeneration has happened in multiple places (eg. separately on webmail, my phone and my tablet).
7. Allow import and export of keys and external key agents for users who want to go all the way.
You could still slap arbitrary additional verification on top of this - trust-on-first-use, WoT, whatever you feel like - but an attacker would first have to overcome the (relatively weak) CA validation and then the additional fancy thing, while it would be usable for normal users immediately.
The only open issue would be multiple identities and joining them. This could be fixed by sharing the key (i.e. if you generate a key on your phone, tablet and PC, you'd have to take each of the three keys and place a copy on the other two devices).
This is a far harder problem than it looks. Let's Encrypt basically relies on a demonstration of control of a web server, and the resulting certificate is only as strong as that validation. For email, the way you can demonstrate control is in being able to read and send emails originating from an address... but the point of S/MIME is to secure against other people who can also do that.
That's sort of the conundrum with email encryption. Your connections to and from the email server are encrypted (assuming you're not using an idiotic client, but if you care about encryption, this assumption is valid). Most traffic (~80%) between the major service providers at large is already encrypted. So the only people who can access your email in the first place are the people who can access your email account, namely you, anyone you give access to, and administrators on your email server. Any practical way of rolling out universal encryption is going to have to involve the latter party anyways, so there's little point to going for automatic universal encryption at the S/MIME-level: making the MX/MX links be SSL and banning non-SSL connections at the MUA level are much more effectual.
The situation's a bit more nuanced than that: S/MIME protects you in the case where traffic can be read but not altered (or it would incur far more risk to do so) and most users state changes over time so there's more of a window to attack every message than to attack the account ownership validation, especially if that protocol is hardened.
I see this as similar to the way many people are working to encourage end-to-end encryption because it reduces the amount of interesting data sitting around to be compromised on a server. Yes, at some point a hostile admin can do a lot but that doesn't mean that we can't harden against more realistic attacks.
It's not exactly obvious how this situation is significantly different from the web side of things.
> So the only people who can access your email in the first place are the people who can access your email account, namely you, anyone you give access to, and administrators on your email server
What I think you are going after here is that shared/managed hosting style setups have only limited security, but that is equally true for web as it is for email.
SSL protects against people who can casually monitor or intercept network connections. The attacker threat model is generally "coffee-shop wifi." In order to demonstrate control for Let's Encrypt, you need to ensure that some URL on your server delivers a specified byte content (the content given over a different channel). In essence, this kind of certificate says "I'm satisfied that the person who requested this certificate can arbitrarily modify the content on the website."
What I've seen work really well in the past is one contributor to lead 'interfacing' with the community via the forum; announce releases, and just generally be a voice for the developers. Maybe you have this person already. Otherwise, if the funds are available, hiring a community manager type person is always as option.
Ten years later, people don't know the project exists, it doesn't have a forum or community.
They are sharing resources at the moment, but that appears to be transitionary.
Thunderbird uses the same exact HTML/CSS renderer as Firefox. To the extent that it's not rendering mails "properly", those mails are clearly expecting to be rendered in a way different from what the HTML/CSS standards say...
It's possible to make this work, if needed, but the developers would need to at least know what standard-deviating behaviors are needed.
The three caveats to this statement that might apply:
1. Thunderbird loads the message in quirks mode.
2. cid: links in CSS aren't going to load properly (and other resource URLs are generally blocked by default).
3. Different HTML sections in a message can leak together, largely due to there lacking a good way to combine multiple HTML documents into a single scroll frame (if any Gecko layout folks are reading this, can you please fix https://bugzilla.mozilla.org/show_bug.cgi?id=80713 ?).
Too many people we work with have been upgrading their exchange servers and outlook upgraded without bothering to check to see if they are sending out usable emails.
Found the plugin we use:
Looks like the last comment is complaining about not being able to encrypt mail with the plugin working. I am not convinced S/MIME is fully working, or if it is, there's plenty of UX issues with it's current implementation.
Mostly, yes, once you jump through the hoops of getting a personal certificate (let's encrypt style automation as plugin would be great!).
But there appears to be some issues with adding recipient certificates that are structured in a specific way. Something about the Subject format being valid for s/mime but not recognized by mozilla's cerfificate store as an other-people certificate and as a server cert instead.
This was a certificate used by a local government agency. That made it quite difficult to communicate with them securely. This is one of the few times where I really needed secure email and that's when it failed me.