What Thunderbird Learned at FOSDEM(blog.mozilla.org)
blog.mozilla.org
What Thunderbird Learned at FOSDEM
https://blog.mozilla.org/thunderbird/2018/02/what-thunderbird-learned-at-fosdem/
154 comments
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.
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).
https://f-droid.org/app/com.fsck.k9
https://f-droid.org/app/com.fsck.k9
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.
and K9 on Android is not a bad client. It seems like people are not aware of it much.
It's the best mobile client I've used, but thats not saying much.
It doesn't make me sad, which is the best I can say about it
It doesn't make me sad, which is the best I can say about it
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.
It's not a /good/ client, either. It's adequate, but has a long way to go to clean up it's UX and normal reading flow.
No argument here. But is it any worse than Thunderbird?
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.
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.
Additionally, AquaMail can handle nested folders, which K9 doesn't and never will, according to its developers.
It's not free software, unfortunately, so that is a showstopper for me. Thanks for suggestion, though.
Does it allow plain text composing/viewing yet?
Good question, this is also mandatory for me.
> search that actually works
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.
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.
That's a bit overkill for a phone.
I recommend enabling server side search in Account Settings, much easier on resources.
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.
Thanks a lot for the suggestion! It was set to 100… that's a terrible default for a phone with 64 GiB onboard storage…
with a polished UI it could be better, the protocol and options support are fine.
> 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?
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?
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.
It's confusing that people keep saying Thunderbird is separate from Mozilla but here we have a blog post posted on Mozilla's blog.
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.
> 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 :)
Welcome to present day FOSS.
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.
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.
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!
One more? Short but sweet-- Thunderbird Vista!
Really, the possibilities are endless.
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.
Thunderbird would look really bad if it was for mobile. It would just be a generic mail app due to the limited screen real estate.
Former Thunderbird user here.
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'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.
https://www.kde.org/applications/office/kontact/
http://sylpheed.sraoss.jp/en/
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.
https://www.kde.org/applications/office/kontact/
http://sylpheed.sraoss.jp/en/
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.
I'm surprised you see Evolution as a solution
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Versit_Consortium [2] https://tools.ietf.org/html/rfc2425
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.
[1] https://en.wikipedia.org/wiki/Versit_Consortium [2] https://tools.ietf.org/html/rfc2425
Because meeting invitations are typically using mail as a transport format.
Now, I don't really think that is a good solution to the problem, but it is the way it is.
Now, I don't really think that is a good solution to the problem, but it is the way it is.
> If I need to look at a calendar, I'd typically open a, you know ... calendar application.
Years ago, Mozilla created a calendar application called Sunbird [1].
[1] https://www-archive.mozilla.org/projects/calendar/sunbird/
Years ago, Mozilla created a calendar application called Sunbird [1].
[1] https://www-archive.mozilla.org/projects/calendar/sunbird/
> I'd typically open a, you know ... calendar application.
such as..
such as..
Such as there might have been plenty of, had most of them not folded into various email apps a long time ago.
For daily schedulings, I use Osmo. My plans and reminders and appointments do not belong on a server.
For daily schedulings, I use Osmo. My plans and reminders and appointments do not belong on a server.
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.
[1] http://www.clayo.org/osmo/
[1] http://www.clayo.org/osmo/
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.
Integration with Google's calendars just works though, has done so for years — use the Lightning add-on and the Provider for Google Calendar add-on.
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.
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
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
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 :-(
There's lots of outstanding bugs unfortunately.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1314185 - earliest dependent bug is 8 years old.
There's lots of outstanding bugs unfortunately.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1314185 - earliest dependent bug is 8 years old.
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.
Used to use these in work until our internal security team banned all desktop clients. "Just works" is incredibly charitable.
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.
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..
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.
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 :)
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 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.
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.
I run a Radicale (CardDav/CalDav) server for Calendar and Contacts:
http://radicale.org/
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.
http://radicale.org/
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.
Calender, contacts, and mail are separate apps on almost all mobile devices, so I think that's what people expect more and more.
But the key is that they should be able to seamlessly interact with one another.
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.
> There is not a really good, open source, Email client on mobile.
I know that mobile is more than Android, but I find K-9 mail to be a really good, open source, mobile mail client.
https://k9mail.github.io/
I know that mobile is more than Android, but I find K-9 mail to be a really good, open source, mobile mail client.
https://k9mail.github.io/
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.
If I can wish for something, fix this bug from 2009 https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/3... (but originally from 2007)
If I can wish for something, fix this bug from 2009 https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/3... (but originally from 2007)
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.
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.
A big problem with K-9 (and open-source clients in general), is detailed in this thread: https://github.com/k9mail/k-9/issues/655
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.
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.
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.
Which is different from XOAUTH2. The "less secure apps" listed in google still list ones using app-specific passwords.
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.
[0] https://www.fastmail.com/help/clients/apppassword.html?u=069...
[0] https://www.fastmail.com/help/clients/apppassword.html?u=069...
Replying to cvwright:
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).
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).
From the Github issue linked above, apparently Google supports something similar: https://support.google.com/accounts/answer/185833
> This is a feature, not a bug.
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.
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.
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.
Especially the settings, there are Global settings, account settings, folder settings but didn't always show up in the menu.
The ergnomics are terrible and the search engine is barely useful.
It's still the lesser of all evils on mobile though.
It's still the lesser of all evils on mobile though.
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?
Check out Termux. I'm running Emacs on both my phone and tablet on occasion.
https://wiki.termux.com/wiki/Main_Page
https://wiki.termux.com/wiki/Main_Page
Note: also works on new-ish Chromebooks (so you don't necessarily need to enable developer mode to work offline).
You must hook a real keyboard up, right?
I can't even imagine trying to run emacs on an on-screen touch keyboard.
I can't even imagine trying to run emacs on an on-screen touch keyboard.
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.
As for hook up, there's BT and USB OTG.
As for hook up, there's BT and USB OTG.
Blackberry ftw ;)
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]
[0] https://github.com/k9mail/k-9/issues/865
[0] https://github.com/k9mail/k-9/issues/865
K-9 mail is great, but just one part of the replacement.
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).
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).
For calendar on Android, have you tried Etar? https://f-droid.org/en/packages/ws.xsoh.etar/
Thanks for the hint! I wasn't aware of that package. I'll try it.
K9 is excellent, and has good PGP support as well. Been using it for the past two years without any trouble.
K-9 is slow and has an ancient UI. I hope that they will finish the rewrite to Material UI any time soon.
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.
BTW, Aquamail is free, just not open source. The free version has a few limitations, I think, like a non-changeable signature.
Non-free and thus irrelevant.
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.
+1 for K9. I wish it or something as good were available for iOS.
Mobile app? WTF.
Give me a calendar and/or calendar integration that doesn't suck and I'd be really happy.
Give me a calendar and/or calendar integration that doesn't suck and I'd be really happy.
For people who value it, consider donating specifically to support Thunderbird development https://donate.mozilla.org/en-US/thunderbird/
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.
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.
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.
Personally I'd like to see improved performence. I really don't see why a CPU core would have to be pegged at 100%.
JMAP support would be nice too.
JMAP support would be nice too.
Hell yes, especially during Calendar syncs. Also: startup time. Currently, to reach a fully usable state, on my Linux SSD machine,
- Firefox 59 needs 2s.
- Thunderbird 59 needs 8s.
- Firefox 59 needs 2s.
- Thunderbird 59 needs 8s.
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.
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.
150m. lol. Try using an electron based app and that will seem incredibly svelte
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.
Thanks, unfortunately I'm not using Gnome/Unity, but that looks like something to try if I do switch.
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.
Could you be more specific about what they don’t like?
Besides another layout for widescreen I’m happy with it.
Besides another layout for widescreen I’m happy with it.
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.
What benefits does thunderbird provide over mail.app apart from being open source?
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.
What about Elementary's mail app? It fits the description, of cloning Apple's Mail, at least superficially.
FWIW, it is part of Elementary's Pantheon DE, and it is a fork of Geary [1]. Code here [2]. The calendar client is called Maya, code here [3]
[1] https://wiki.gnome.org/Apps/Geary
[2] https://launchpad.net/pantheon-mail
[3] https://launchpad.net/maya
[1] https://wiki.gnome.org/Apps/Geary
[2] https://launchpad.net/pantheon-mail
[3] https://launchpad.net/maya
> 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.
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.
Interesting idea, I believe Thunderbird even has NNTP support of some kind, although haven't investigated it recently.
> 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).
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.
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.
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).
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.
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.
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.
> 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."
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.
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.
DavMail is a gateway that does exactly this, and can be run locally or as a server:
http://davmail.sourceforge.net
http://davmail.sourceforge.net
Have you looked at exchangecalendar (EWS) https://github.com/ExchangeCalendar/exchangecalendar?
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.
Ten years later, people don't know the project exists, it doesn't have a forum or community.
Of course people think it's dead, there isn't even a link to it on the Mozilla site.
Thunderbird is supposed to separate from Mozilla, which decided to focus almost exclusively on Firefox.
They are sharing resources at the moment, but that appears to be transitionary.
They are sharing resources at the moment, but that appears to be transitionary.
If the author reads this: I was part of the crowd commenting on the "is it dead?" state and thanks for answering my questions and giving me hope! :)
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 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.
Could Thunderbird be configured to open a web browser to display the message if it's not rendered properly?
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 ?).
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 ?).
It's been getting slower over time with noticeable stalls. Performance is a feature
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.
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.
[deleted]
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.
S/MIME is natively supported by Thunderbird, unlike PGP (which requires Enigmail).
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.
Edit:
Found the plugin we use:
https://addons.mozilla.org/en-US/thunderbird/addon/exquilla-...
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.
Edit:
Found the plugin we use:
https://addons.mozilla.org/en-US/thunderbird/addon/exquilla-...
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.
> S/MIME works just fine in Thunderbird
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.
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.
Is there anything planned for adopting the UI (visible and technical) changes of Firefox?
I really, really hope not. That'd be the one sure way for me to stop using Thunderbird (like I have stopped using FF).
The visible changes meaning "all extensions stop working for no apparent reason"? Great way to kill the project altogether.
I just updated to the latest beta (57). Thunderbird has now the Photon UI. Enigmail dies not work anymore. It's only supported until version 55.
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.