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.
I'm going to chime in and say I want Thunderbird on Android. Preferably with the ability to sync settings and data from and to my desktop and laptop.
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.
Don't think you can go more than two scrolls in these comments without having it smacked into your face repeatedly, but K-9 Mail is that. It's open-source and by a long shot the most popular open-source client (except maybe the AOSP client, but that one's not exactly good).
A little late in replying, but the fact I had never heard of K-9 until this HN post kinda proves my point about name recognition. Last year I actually tried 5 or more different Android clients. I didn't try K-9, if it I even saw it. I must have judged it as untrustworthy or not worth trying for some reason.
> please, Mozilla, do not build mobile Thunderbird apps
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?
I mean, I don't know about you, but that seems to be the fate of any mail client. "Doesn't make me sad" is the highest rating that any mail client, web-based or not, has ever gotten from me.
My own take on this point: for my neither trivial nor very advanced needs, K9 at least lacks:
- hierarchical display of email threads;
- search that actually works.
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.
You should try AquaMail. The search works. Threads aren't shows as a tree, sadly, but they are grouped into a folder - not ideal but you can at least follow simple conversations. Still not something for mailing lists.
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.
It doesn't work well either in my experience. Not sure if K9 is really the one to blame, or the IMAP server (Gmail, in my case). As Thunderbird indeed does search locally, it isn't impacted by poor server side search anyway. Thanks for the suggestion, though.
Thunderbird is not maintained by Mozilla, and those new hires are not by Mozilla, so it should not affect Firefox. It might affect desktop Thunderbird, of course.
And their job posting was on mozilla.org. As is their bug tracking. And their conference team was stationed at the Mozilla booth. According to Wikipedia, even what they intent to be is hard to call independent from an outside perspective:
> 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.
I don't mean to be a weenie about it. I really truly appreciate what the Thunderbird team and Mozilla team are up to and have donated in the past. I also understand that the Thunderbird team is super small, as well. As an outsider, I guess I just don't understand how they are separate :)
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.
I'll add to the mix - there needs to be an equivalent of Thunderbird on Android.
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.
Splitting focus to create a mobile client while the desktop client all their remaining loyal users actually care about lies moribund is a great idea!
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!
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.
I've spent a lot of time looking into this and am as frustrated as you. I'm building out a small consulting company based on Linux, and the basis of it all - email, contacts, calendars - is a fiasco. I went to Evolution as a client, which handles all of the above. Thunderbird does mail but its contact solutions require LDAP, not CardDav and its calendar solutions are bolted on, not integral. Linux devs spent a lot of time working on the "replacement for Outlook" in the early 2000s before giving up and spending their energy blowing up Gnome2's otherwise-perfectly functioning DE instead. My two go-to solutions on Linux desktops are Evolution, as mentioned, and the web client for Fastmail, which offers email, calendaring and contact sharing. Thunderbird is behind. There's a recent new add-on that purports to deal with carddav and caldav in Thunderbird, but it's still got a rough edge or two, and annoyingly, remains an "add-on" which aesthetically sends the wrong signal. On KDE, Kontact (encompassing Kmail, Korganizer for calendars and Kontact) works very well for my techie colleagues but is a bit weird for non-technical staff. I've also looked at Zimbra and the former Zarafa (now Kopano) and Kolab and some others, and Fastmail's web client remains the easiest and friendliest solution, while Evolution remains the best desktop client capable of handling IMAP/CALDAV/CARDDAV. It's annoying though. On Windows I'd just install emClient and call it a day (and would avoid Outlook, which I desperately dislike).
KDE's Kontact PIM has been best-of-breed general office communications on Linux in my experience.
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.
Thanks for these suggestions. I, at least, am going to try them. I've used Thunderbird for years, then recently switched to Evolution and Gnome. But whilst gnome looks pretty I'm not really finding it a good fit for me.
This gives me a final shove to try KDE so thanks for that.
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.
> 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.
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.
Can someone explain? Honestly, because I have never fathomed: Why has calendaring and associated PIM-stuff been grafted onto email specifically? Is it a spill-over from the strange land of Outlook/Exchange? My Thunderbird does really decent service handling my mail. If I need to look at a calendar, I'd typically open a, you know ... calendar application.
It's a spillover from the strange (but comprehensive) land of enterprise communication and productivity software like of Lotus Notes, Exchange, and GroupWise, but also influenced by the web browser "suites" of the late 1990s.
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 [1], 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 [2] 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.
This Osmo [1]? Well, good for you. But this software is not capacitive/finger friendly. Its for resistive/pen usage. The rest of us need a mobile e-mail and PIM client which works with a capacitive touch screen (and fingers). Also, many do want online synchronization so that their desktop, laptop, and mobile phone are synced. You can even self-host with Nextcloud as an individual or company.
Lots of good answers already, but one fundamental answer is simply that the first vaguely interoperable spec for events with attendees offered email as a transport mechanism (iMIP). Everything since has fallen back to that.
It kind of works, most of the time. On other occasions you'll get meeting reminders you can't dismiss, event cancellations which stack a new crossed out date on the list for every "update" click, events where you can't set attendance, and the annoying "you clicked dismiss, would you like to submit the modified event to the server" dialog. And that's on a good day :-(
It's never worked well for me, e.g., when responding to third party calendar invitations, when moving meetings with others, when using two-factor authentication, when adding contacts on multiple devices.
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.
The entire email client froze up the very first time I tried to sync my Google calendar via Lightning. On subsequent syncs the UI only became unresponsive for several seconds. I dunno why sync was running on the UI thread, but it made Thunderbird nearly unusable until I disabled it.
The biggest problem, IMO, with the contacts system is how limited it is. You get two email addresses and two phone numbers per contact, that are pre-labeled "work" and "home", and that's it. It absolutely must have the ability to add arbitrary numbers of physical addresses, email addresses, and phone numbers to a contact, as well as give each field an arbitrary name. I cannot comprehend how it can't do this. Every other address book on the planet allows this. I have some contacts with 8 email addresses, 4-5 phone numbers, multiple physical addresses, all with custom names for what each of them are. So the fact that thunderbird can't handle this makes it unusable for me.
Only Apple and Google seem to allow this. I've made the same request to every other email/cal/contact provider I've used but they never do it.
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.
I've never understood why contacts can't be stored inside a mail folder, so that every computer you setup thunderbird on gets its address book synced..
We do have a standard for this. RFC 6186 "Use of SRV Records for Locating Email Submission/Access Services" and RFC 6764 "Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)" should be sufficient.
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 :)
That actually doesn't sound like a terrible idea. Structured markup in the email could be parsed by a client that knew what it was, and other clients would just have a folder of emails with contact info in them.
> 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.
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.
As it is, though, I bet that they'd integrate email, calendaring and their password sync, and there's no way I'll ever store passwords on a service which is able to snarf my password-encryption password simply my feeding me some malicious JavaScript.
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.
Synchronization with calendars? A friend of mine wrote BirdieSync (http://birdiesync.com) for that purpose, and it was quite successful. Yes, it's not free, but some developers have rent to pay.
I also came here to write about K9. It's open source, it works well, it supports encryption (with the OpenKeychain app). I don't have much more to ask to it. I don't think it's worth investing on a mobile Thunderbird but to be fair, I'm pretty happy with desktop Thunderbird too. They could stay in maintenance mode and make sure that it keeps running on any new OS version it's released.
I have a similar sentiment towards Thunderbird. Every once in a while I try using other Linux desktop clients but I always go back to Thunderbird. Feature-wise I don't miss anything. My biggest problem are various long-standing bugs and occasional crashes. Each time it crashes I wonder whether that is something that might be exploitable by a specially-crafted email.
For me, Mailspring (successor of Nylas N1) works, but it does use Electron... (Therefore IMO not suitable for mobile, but I wasn't suggesting that either way.)
+1 k9 is really good, I think it would be a pity to split thunderbird resource on mobile front, maybe they can share resource (low level protocol libraries?)/public relation (i.e mutual refering) so that they core developers can focus on what they're good at.
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.
This is a feature, not a bug.
Google comes up with ideas, sure, that doesn't mean all projects have to support it. There is nothing wrong with SSL IMAP auth.
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.
SSL IMAP auth prevents bystanders from watching the password. Google's auth goes further, the IMAP client doesn't have to store your password at all. Instead client stores an app-specific password-like string instead, one with limited rights), which is a big improvement IMNSHO.
If you look at how, e.g. Fastmail solves this[0] (and other services do the same or similar), it's a nice example of something that's both secure and supports any client without requiring the client to do anything specific to their service.
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).
I had been using K9 since 2010 or so, since there were only few mail clients supporting multiple accounts, but I always found it rather confusing to navigate around.
Especially the settings, there are Global settings, account settings, folder settings but didn't always show up in the menu.
I'm the sort of person who lives on the cli, I've been considering trying to port some of my emacs/gnus setup to my android device. I wonder how well it would work?
Hacker Keyboard will allow you to achieve a lot. All, with all CLI programs? That I do not know. There is a learning curve either way. You can also SSH out of your machine with a terminal app (recommend to look into Mosh) if you got a good internet connection such as 4G/LTE or WiFi. Then you can run e.g. Mutt remotely. Use with tmux and never close it.
Since we're listing issues with K9: It's pretty easy to setup if you know what you're doing, but the lack of any sort of autoconfig for non-Gmail mail servers make it very difficult to give it to a normal user and have it just work. Thunderbird has a standard autoconfig file to do this, and there is an open issue on K9 to add support for the same format, but it's been open and stagnant for years[0]
You've gotten a lot of recommendations for K9, which I also like. But I went with Aquamail on Android, which has worked really well for me and I'm very happy with it. Actively developed and maintained, and very slick interface.
I'm a big supporter of open source software. However, I pay for a copy of Aquamail. I also paid for a version of K9, in order to support the developer. Aquamail is a good product and the developer is continuously improving it. I would hate to live in a world where your only options for email would be to use one of the big providers (gmail, office 365, etc).
BTW, Aquamail is free, just not open source. The free version has a few limitations, I think, like a non-changeable signature.
It's good, some options are placed at very counter intuitive places and it would be nice if they'd slap some material design on top of it. Other than that it's pretty nice indeed.
Mozilla has plenty of money. If they truly cared about an open internet as they claim, they would be taking better care of Thundebird. It is by far the most popular open source mail client, and email is something that needs to be saved from the evil clutches of FB messenger and the like.
That may be, but Mozilla has decided not to pay for development on Thunderbird any more. If we don't contribute to keep it alive, and the project whithers and dies, I guess we can console ourselves with the satisfaction that we proved a point to those bean-counters at Mozilla.
Hell yes, especially during Calendar syncs. Also: startup time.
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.
The only item on my wishlist is a tiny 100KB daemon with a status bar icon to watch for mail so I don't need to keep a 150MB behemoth open in the background all day. Otherwise Thunderbird is already more than I'll ever want from an email client. Calendars, contact managers, and other nonsense should really be independent programs cooperating via IPC.
I use https://github.com/pulb/mailnag for "simple mail watching", does the job and features a discrete icon and/or a sound notification. Frontends available for Shell or Unity.
It's a Messaging Menu indicator front-end, not something Unity-specific, so it works on Ubuntu MATE and Xubuntu, for example (and Elementary OS AIUI). There's also a third-party Cinnamon frontend.
Tinymail/Modest? Not sure if its still developed or has a spiritual successor. Modest used GTK back in the days. What does Sailfish use for this purpose? KDE Mobile?
I train users all the time on Thunderbird and to be honest, many people really dislike the UI/UX. Even though I'm primarily getting them to use it for security reasons, unfortunately so many of them really hate the transition from Mac Mail or Outlook. Working on that, rather than duplicate K9 Mail, would be my suggestion.
Essentially people get used to a more modern, fresh approach that they feel they get with Mail.app etc and look for something similar with Thunderbird.
There is a UI/UX update in the pipeline, hopefully cleaning things up, but at the very least it'll give Thunderbird a UI with a more modern style, similar to Firefox Photon's.
> They pointed out that they were Thunderbird users, but weren’t really into mailing lists.
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.
They could set up a NNTP server to serve as a forum. The problem with mailing lists is that there's no good way to search past messages from before you subscribed (the web based ones don't cut it). A newsgroup does not have that problem.
> I believe Thunderbird even has NNTP support of some kind, although haven't investigated it recently.
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).
On the subject of encryption, S/MIME has broad client support (e.g. the clients shipped in all major desktop & mobile operating systems) and the security model is easier for most people to understand (WoT sadly often means “accept everything without checking” in practice).
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.
> WoT sadly often means “accept everything without checking” in practice
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.
Details:
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.
S/MIME is extremely well suited for this, because it's already supported in many clients natively. You could make it possible to obtain a validated identity (e-mail validation) from a CA. Many of today's clients would natively be able to verify and trust this identity without previous key exchange.
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).
> What's missing is a LetsEncrypt-style effort to make it easy for people in non-managed environments to get and renew certificates.
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.
> 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.
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.
> 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.
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.
> It's not exactly obvious how this situation is significantly different from the web side of things.
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."
The biggest barrier I see to making a forum a core part of the community effort is getting buy-in from MOST of the contributors to the project currently. So, over the next week I’m going to try and get an idea of who is interested in participating and who is opposed.
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.
I would love for Thunderbird to support Exchange 365. I use Linux at work but sadly we've got office 365 and use a lot the calendar built in. I have to use Evolution as its the only mail client that supports, and didn't really want to try ExQuilla.
Ten years ago I interviewed for the head QA and Community Manager position. I flew out, did interviews, got back, even received an offer for the job, but then I was told the offer was rescinded because they felt they didn't need to fill that position.
Ten years later, people don't know the project exists, it doesn't have a forum or community.
The biggest problem I have with thunderbird is that it fails to render some html mails properly. Above all, they should fix this problem first. Instead of creating a mobile app or whatever, they should get their existing client right. As of today, the 2 things that keep me from switching fully to evolution are (1) evolution's unfriendly keyboard shortcuts that, for whatever reason, I cannot change, and (2) nostalgy.
Have you filed bugs about this, with the example emails attached?
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.
Thunderbird uses Gecko, the same engine as Firefox, to render emails. This means it's actually generally the most-compliant HTML rendering email of any email client: you can even use MathML and <video> if you want to (assuming that the bug about <video> controls requiring JS has been fixed).
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 ?).
My biggest bug bear atm is damned tnef or the dreaded winmail.dat attachments.
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.
I hope hey don't only support enigmail for encryption but also S/MIME which is supported by both the native macOS Mail client and Outlook. We have to pay for a plugin at my job for Thunderbird that if I remember correctly lets us read encrypted mail, but not write it, unless I'm miss remembering.
Oh I must've mixed up in my head Exchange support for S/MIME then. It's been a while since I had to use Thunderbird at work (using Windows recently) so I forgot the reason. I do remember someone mentioning it can only read those emails though, not really write / encrypt them.
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.
S/MIME works just fine in Thunderbird, although the UI is pretty poor. I will believe that composing S/MIME doesn't work in Exquilla: Exchange uses a different format for representing messages than MIME, and the hook that it uses to build messages happens before S/MIME gets introduced, and the S/MIME code itself pretty heavily bakes in the fact that it's emitting MIME.
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.
The UI for adding certificates is, as I recall, a massive clusterfuck. That's due in large part to this traditionally being the domain of the certificate manager folks from Firefox, where a) the necessary components are extremely low-usage (when was the last time you used a SSL client certificate?), and b) some of those people don't give a fuck about Thunderbird.
On the forum thing. Best i can tell, mailing lists are nice for when you want to be involved day to day, but forums allows you to search the history of discussions (yes there are third party sites that offer list searches, but i have found them noisy at best).
I really hope that they will build a Thunderbird version for the browser. Something like Horde or RoundCube isn't exactly a joy to use and most people are heading towards GMail and the like just because it is the simplest option.
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.