Hacker News new | comments | show | ask | jobs | submit login
Proposal to start a new implementation of Thunderbird based on web technologies (mail.mozilla.org)
237 points by rxlim 10 months ago | hide | past | web | favorite | 233 comments

Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

The search is unusable -- wedding finds 'weds'. There is no way to do exact searching. I reported this 5 years ago, lots of other people have complained about the stemming, there has been no fix.

There is no support for outlook/exchange. Not saying it's trivial, but it's useful in the modern era.

IMAP folder support is very flakey, I reported some bugs but nothing got fixed.

There is a plugin for Exchange [0]. It works.

The search is really weird. I had to install an extension to always filter by date but even then it's broken to the point where I have to open webmail to do real searches.

[0]: https://addons.mozilla.org/en-us/thunderbird/addon/exquilla-...

I'm trying to keep an offline copy of my inbox using IMAP. I changed every setting I could find (like no cache limit, download the entire message instead of just the headers, ignore message age, don't delete any messages) and it still wants to download entire folders from time to time instead of just the changes. Maybe I did something wrong but that's my experience with IMAP support. It's also pretty slow but that might be some Gmail limitation.

It sounds like search needs a patch bounty, but it would be ridiculous to rewrite Thunderbird because search is naively implemented.

I've never had problems with IMAP, nor do I use Exchange, so I can't speak to those...

And thankfully, there's a Lucene-in-C (which I haven't personally had a need to use, but Lucene as a project is awesome), so the patch might not even be terribly large unless their current search implementation is splattered all over the app


The search is not unusable, I use it every day. It could be better though, and I get the feeling it could plan the query more efficiently too. I think it needs a better query syntax for those hard to find e-mails.

I agree about search, but I don't think that rewrite using web technologies is good solution to this particular problem.

Yeah, the search box is just ignored by me - I use the 'quick filter' box instead, because it's possible to understand how the results match the query.

>There is no support for outlook/exchange. Not saying it's trivial, but it's useful in the modern era.


It may not be an "ideal" solution in that it requires a second program running, but given that you're working with a closed, non-standard protocol, that's kinda par for the course.

I feel the same way personally. I feel like I see tons of people complaining about it, but it's just what I want out of a mail client. The UI is a great, the GPG integration is great with enigmail, it's a very polished product.

Not only that, but making one based on web technologies that moves away from the native look and feel it currently has would truly be a loss in my opinion. I'd probably give Claws Mail and alpine another go, maybe even desktop outlook before I'd go to something Electron-esque. I already have enough shitty electron apps - I'm currently dealing with a really weird font rendering issue arising from Electron use in VS Code.

It's an incredible product as-is, but I feel like they are stuck between a rock and a hard place with moving forward and forecasting beyond the immediate future.

I don't see why a new implementation couldn't maintain the current UI/native feel outside of poor decision making.

I could see it as a net positive, with cleaner easier to maintain code base built on more recent tech that is more accommodating to younger developers.

If they could pull off what Atom.io/Github did for the old ingrained IDE world in a mail client, that would be incredible, IMO.

> If they could pull off what Atom.io/Github did for the old ingrained IDE world in a mail client, that would be incredible, IMO.

You mean give hipster programmers an editor where one can literally see the delay between typing and something appearing on the screen?


We don't personally attack other users like this here.


Same. I did quite dirty stuff with Thunderbird and it always behave well and it never crash. Plus, it's quite ergonomic.

If you're on Linux uninstall mscorefonts.

A few years ago I thought it would be nice to be able to compose an email in a new tab instead of a separate window. I found a Bugzilla entry proposing adding this to Thunderbird that had been open for several years and had had a couple community members offer to address it, look into it for a while, and ultimately give up. The way Thunderbird's UI is implemented was just too intertwined with the code to let this happen without a major re-work. I feel like this kind of a change should be easy to do in a well-designed application and likely would be for something written with technologies.

I use Thunderbird every day and am generally happy with it, but often when I come across some feature that I wish were changed and start digging into Bugzilla it becomes apparent to me that the Thunderbird codebase is old, convoluted, and difficult to work with -- the result of growing organically over many years. I could see a lot of benefits to a re-write. On the other hand, trying to match feature parity with the current version would probably take a lot more work than the author of that proposal is accounting for.

Working with big folders tends to be a bit error prone to me. I would like to synchronize my filters/settings across different devices. On MacOs it randomly hangs for tens of seconds and eats batteries for some people (me included).

So yeah, it's mostly done, but better virtual folder support, and a streamlined UI would both be hugely appreciated by me.

But, because it's mostly done, I also will just happily keep using it as it is now for the next three years, waiting for the rewrite.

Is a rewrite necessary to improve on those aspects over modifying the existing codebase?

Yes. Because the Thunderbird and Firefox codebases are diverging so much that instead of just maintaining Thudnebird people will have to maintain a fork of Gecko too.

Maybe not, but from the sound of it, a rewrite is necessary just to keep the lights on and to keep Thunderbird compiling in the long run.

What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely?

Changing the UIs within this particular family of software products has often given questionable results, confusing or upsetting the core user base for little real benefit. Other UIs built on JS and HTML technologies have so far tended to be slow and buggy compared to using native technologies on the desktop and mobile platforms. If the exercise is expected to take as long as 3 years with the available resources and the hope of getting back to more of a community-supported culture, that seems like a huge amount of work to essentially stay where you already were.

> What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely?

Short answer: security bugs. Gecko has too high of a code churn to maintain long-term support branches, particularly for people who have little knowledge of the components in question (e.g., SpiderMonkey). Forking Gecko might be a viable short-term strategy, but it's not at all viable long-term.

That makes a lot of sense if we're talking about using Gecko to render the contents of arbitrary HTML emails. However, this proposal seems to be about problems supporting the UI itself and proposing a move to some other JS+HTML rendering system as an alternative. At first glance, that appears to be a separate issue, other than both types of functionality possibly relying on Gecko today and rendering engines being quite large so using two different ones not being desirable.

Gecko is actually quite difficult to embed (Mozilla more or less gave up on there existing non-Firefox/Thunderbird embeddings around 2011 or so).

There's a lot of low-level interfaces and design decisions that filter through Thunderbird, for example networking interfaces. Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Right, but isn't the argument quite a few people are making here that moving to a different UI rendering engine doesn't seem to be obviously justified, given the goals of the project and its current situation? If the architecture is as inter-dependent and non-modular as your comments suggest, wouldn't that make changing significant parts of it even less likely to be successful?

At that kind of level, you might be better putting the whole project into legacy mode with emergency updates only, and just letting it carry on for as long as it's useful and then die of natural causes when the time is right. For the other goals mentioned in the original proposal we were talking about, if there's sufficient interest to support doing that much work then an entirely new project with no baggage at all seems like a safer and more realistic bet.

As a result of this thread I have tried the Nylas mail client which has a javascript UI, and I am very pleasantly surprised by just how smooth the UI is.

Honestly, if I could use it without a Nylas account I would very seriously consider it as a Thunderbird replacement.

From reading the original email thread it also looks like the Thunderbird guys are paying attention to Nylas.

VSCode and Slack are two other Electron apps with snappy UIs. Though I commend the devs on their snappy UIs, both those apps churn the CPUs and consume crazy amounts of memory. They absolutely kill the battery on laptops and make other applications unusable.

I do not want my mail client or any other app that should be always running in the background to be written in Electron.

That's a pity. Given that they are exactly aiming for mobile applications though I really hope they will keep these issues in mind though and make informed decisions on this.

Not only are security bugs an issue, as mentioned, but what about maintaining compatibility with changing platforms? Who will fix the bugs when future versions of Windows, MacOS, and Linux introduce growing numbers of 'minor' incompatibilities, and maybe major ones? What about changes in protocols, such as IPv6 (though mail protocols are mostly mature)?

If Thunderbird isn't updated, it will slowly die of bit rot.

Calendaring is excellent for a one-person effort (mostly one person, anyway), but still has issues around the edges (e.g.CalDAV doesn't work as nicely as macOS Calendar.app). It probably doesn't help that the server I have to use it with is half broken too; overall the experience isn't as good as Outlook + Exchange. But that's not only because of Lightning.

Overall the main problem is probably that not enough people can spend enough time on it. Which makes me hypocritical given that I'm not currently helping…

I agree about Outlook + Exchange. Plugins exist for thunderbird to integrate but they just don't have the same quality of experience. Simply using outlook is less frustrating for me.

The meeting attendance functions need some work. And I'd throw cash at a bounty if an attendance "solver" could be added (ala heres who has to come, here's my standard list of rooms, find me a spot which is unbooked)

It needs end-to-end encryption. This isn't hard to do. Add a field in the header for your public key. When receiving mail, store the sender's public key in the address book.

Then, when sending mail, if there's a public key for the recipient, then encrypt it. No user interaction is required.

> This isn't hard to do

Yes it is. Or someone would have done it by now.

> When receiving mail, store the sender's public key

You mean "the public key associated with the inbound email". You don't know anything at this point about how it relates to the person you're intending to correspond with, because the key could be MITMd.

Also, this approach does nothing to solve the fact that most people would prefer webmail and mail synced across multiple devices, which is an even more painful key management problem.

> because the key could be MITMd.

That's true, and my paper mail envelope could be steamed open, read, and resealed as well. I'm not saying this would result in perfect security, and anyone would be foolish to treat it as good enough to direct their U-boat fleet. But it would be pretty good for routine email.

As for the key exchange, if a user is worried about it, they could exchange keys in another way. The point about the built-in key exchange is that it happens by default.

> more painful key management problem.

It's only painful if you really need high security. I'd just like something better than postcard security.

Hmm. I can just about remember Jim Barksdale personally telling every employee that the new E2E encryption feature (PEM probably?) in Messenger had to be dog food tested. In 1997.

Unencrypted email is like mailing all your correspondence on postcards.

The Thunderbird codebase has nothing to do with the Netscape codebase you're referring to.

Interesting. Are you sure? I didn't remember a big re-write ever happening, and after poking around in the current codebase for a while I see lots of old code and familiar names. Are you referring to just the UI? The address book code (the part I had something to do with back then) looks very similar.

S/MIME works fine with Thunderbird.

I think the point is that to keep the project relevant the underling aging Gecko underpinnings may be going away. This would cause the maintainers to have to take on maintaining their dependencies as well as the core project. I can totally understand this as a motivating factor here, however, I use Thunderbird as a local offline mail client. Though I see these are out-of-fashion these days, it doesn't make the need for this kind of software go away. I only hope a web-stack version of thunderbird still stores settings and content locally and hopefully outside of the browser (not going to say electron here, but similar).

> I use Thunderbird as a local offline mail client.

I think that the intention is to keep it that way. They're proposing mostly a reimplementation of the UI, from Gecko+XUL to HTML+JS, but also a reworking of the interface between frontend and backend code (I guess between the model/controller and view parts of the code).

The filter is slow in regular-size mailbox and almost unusable on my bloated gmail. I don't mind getting results progressively as the messages are scanned, but it runs on the UI thread and UI is horribly slow while the filter is working.

The search is just broken. It gives messages that don't have anything of search string in them and misses the right ones.

I agree on the search, but are you referring to the filter search box? or gmail filters? the filter search box is the main reason I didn't switch to any of all the other alternatives like mailbird. It helps me to avoid using the TB search.

What I want is a GMail client on premise. An open source clone of the GMail Android app or webapp running in Electro or Servo. GMail has a perfect conversation-style UI. Even today Outlook, Windows Mail, Thunderbird have no equivalent conversation view (just hacked together additions that don't work). Also GMail introduced the concept of tags instead of lame folders (an email can be tagged with several tags). Also GMail syncs notes and calender with CalDAV and other open protocols. It works fine out of the box with iOS. Even the notes app syncs data to GMail IMAP out of the box.

The old Opera 12 browser featured such a similar HTML based email client. Vivaldi promised such a email client, but no news for years.

Thunderbird is like Outlook Express aka Windows Mail (Windows Vista/7/8) (both deprecated), Outlook's little brother.

On my OSX box (mbp) the context menus and popups are horridly misplaced and popup in random locations on the screen. For the popups the pointer is also often completely misaligned with the menu items requiring item selection to be clicked dozens of pixels away. I've also long given up throwing TB to a different display - text, UI sizing and menus explode and it becomes unusable on any other monitor.

Having said that it's still the best email client software I can find - UI issues aside.

It looks sort of retro 90s on the iMac but I grew frustrated with the Mail.app in Yosemite and switched to TB, which works flawlessly. The Mail.app in Snow Lion was very reliable.

Haven't used it in years. Some questions:

1. Can I tag messages? If not, it is unusable for me. Once you get used to notmuch/sup type workflows, everything else sucks.

2. How good are its searches? Can I say I want all messages after a certain date, with a certain word, with no attachments (or with attachments > 100 KB, or with attachments whose name includes "xxxx")?

3. Does it support virtual folders, which essentially are saved searches?

1. Yes, tagging is supported in-client only. Tags are not propagated outside of the client.

2. Search filtering options are all there, however the actual search algorithm is mediocre as fuck. You'll probably eventually find the email you are looking for.

3. Yes, virtual folders are supported.

Overall it's a great, however clunky piece of software. I didn't realize the code base was ~20 years old, so I fully support them doing a new implementation. Thunderbird has been a great client for me for 5+ years but imagining it powered with fresh, up-to-date tech excites me even more.

I haven't used Thunderbird for a long long time, but the feature I was missing the most when I moved to Gmail ages ago was some sort of automatic categorization (machine learning) based on content of the emails. One application would be spam filtering, but I would actually appreciate if it could be applied more broadly to classify other emails.

Is something like that now available in Thunderbird?

Spam filtering has been in Thunderbird for a decade now (based on a Bayesian classifier, although it's not quite naïve Bayes). There is a capability to extend the classifier to problems beyond spam/ham classification for extensions.

Interestingly, scam detection (rather than spam filtering) is a simple hardcoded rule, which looks at whether the send headers match up. I've received more than a few genuine emails marked as potential scams because they were sent from a rebranded mail provider.

It's either done or it isn't.

If it's done, it isn't going away, just keep using the same binary forever.

If it isn't done—i.e. if it needs porting to new platforms, security patches, bug fixes, etc.—then there needs to be people who interested and invested in the codebase, both at Mozilla and the OSS community. Which means having a path into the future.

Very hitchy and slow with large folders, particularly in search. I find the search usability very poor. Some dumb defaults like the quick filter searching on Sender for a folder that's a Sent folder, instead of Recipient. Gigantic memory leaks for me under Linux. (If I leave it open for a few days it'll go > 10 gigs of RAM, that bug's been unresolved for me for over a decade.) Buggy network probing when setting up a new account aimed at an IMAP/SMTP server. Doesn't autofit images to the window size when I'm pasting them into a new email, so with big pictures it's a big hassle to scroll around and manipulate the document. And those are just off the top of my head.

I do. I'm only using it with about 7 mailboxes, none of which are terribly huge. It frequently stalls for an entire minute or two, has bizarre behavior and interactions with gmail when I'm writing long emails which gunk up conversations, configuration of mailboxes and SMTP servers are fractured all over the place, and search is only slightly more useless than reddit's search.

Based on some chatter here recently, I just recently switched to trying out Claw, it hasn't been too long yet, so I don't know all of the issues yet, but at least it was easy to setup and is really really snappy and uses about 1/3 of the RAM.

delete panacea.dat (google before hand; I'm evil as far as you know). I had the same experience as you, eventually traced it down to a borked panacea file, deleted it, and everything is perfect again.

Since this thread is (probably predictably) "what I don't like about Thunderbird", I don't have the problems that others are having with the search algorithm per se; but, after finding mails, it refuses to show them to me. It correctly shows me snippets from the mails that it finds, but, when I try to access those mails, it just shows me a blank window.

(It also refuses to acknowledge deleted and created folders on my work account, but, not knowing the actual cause, I am very happy to suppose that the blame lies on some administrator at work making some hostile-to-non-Outlook-users change in OWA setting.)

I like it, and it is usable. But I don't use it because I want to be able to have the same email interface wherever I go (my Android, laptop, TV, and PC). I think it would be a good idea to have a portable / web version. It could be one more thing that keeps Mozilla alive / ahead (speaking as an outsider / user).

Hum, it would be interesting to know how you use it (with respect, I'd suggest you have very basic email needs). For me Thunderbird is badly broken. This is not the place to list bugs, issues, limitations etc. in any detail but there are very many indeed (so I'll only provide a skeletal outline of them here).

Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy of Eudora Mail, or Outlook or other packages to get the job done (it's just about the most idiosyncratic software package I know).

Briefly, the key issues for me are:

1. The editor sucks, big time, to call it a HTML editor at all is stretching the truth beyond reasonable recognition it is so broken. (a) It's bug-ridden in the extreme (long emails with formatting are better edited outside TB and then cut-and-pasted back in when finished but this is only a partial solution for the obvious reason that the underlying editor will then screw up perfectly good HTML). (b) Bugs develop/manifest over time whilst actually editing a single email/email reply (seems to have memory leaks). The formatting is very limited—superscripts etc., etc. require add-ons, to be implemented. Today, HTML formatting is a trivial matter (or it ought to be) so why after decades hasn't Mozilla implemented such basic formatting within Thunderbird by default. (Moreover, heaven help us when we need to add proper math formulae to the mix—just forget the notion!) (c) Global typeface change(s) is so broken it's better to save one's work before attempting them, alternatively one has to cut them into a plaintext editor (notepad etc.) to all kill formatting and start again preferably in another decent HTML editor such as BlueGriffon (which, incidentally is also based on Firefox). (d) Text size and text spacing is likewise hopeless and also has to be edited outside Thunderbird then cut-and-pasted back in. (e) There is no Format Painter! (f) Nor is there an Add/Remove quotes level facility (AND THUNDERBIRD ACTUALLY CALLS ITSELF AN EMAIL CLIENT?)—not having proper quotes handling is like buying a vehicle without wheels! It's sheer crazy stuff.

I could keep going on about editor problems and mention the issues with inserting images etc. but that's enough for here.

Finally, summarizing the matter of the Thunderbird editor issues, I again mention the BlueGriffon HTML editor by comparison, specifically because it is based on the same Firefox code as TB is. This proves that the limitations within the Thunderbird editor ARE NOT in any way limited by the underlying Firefox code. It seems to me that as BlueGriffon is open-source, the simplest immediate correction Mozilla could do to Thunderbird to fix its horrible editor would be use this BlueGriffon code as is, as it actually works!

2. The Thunderbird UI is confusing for both new and older users alike. The issue of the UI is too involved to discuss here in any detailed way except to say TB's designers should look at one of the all-time great classic email client designs for guidance: Eudora Email. (Many of us would still be using Eudora in preference to Thunderbird if Qualcomm hadn't killed it off over a decade ago—even then, many still do use it). Why reinvent the wheel if you're going to break it in the process? For starters, you cannot even dock the windows in Thunderbird. Why on earth not? (One wonders whatever went on in the minds of the original TB developers.)

3. Thunderbird's implementation of MBOX mail format is severely broken (it is dead easy to lose mail permanently from crashed indexes, compacting mail etc. The fact that Thunderbird's MBOXes are essentially incompatible with other email packages that also use MBOX is a serious issue when it comes to large site usage, maintenance etc. The MBOX problem is one of the main reasons why Outlook is often preferred to Thunderbird in corporate environments (Microsoft may be proprietary but every man and his dog either knows about its PST mail files or has a utility to maintain or fix them—not so with Thunderbird MBOXes. Moreover, Thunderbird MBOX mail files almost invariably crash when they reach the 4GB size threshold (it's a very risky business and you'd better have a decent backup strategy if you want to risk it).

4. Thunderbird even [still] has bugs in the mail addressing department (the text goes red for some reason if one does editing on the email entry). This alarms users. Furthermore, even the method of entry of CCs, BCCs is unnecessarily different to other email clients. Why unnecessarily confuse users with a redesign just for the sake of it (for heaven's sake, it seems to me the only way this could ever have happened is that TB's original developer's had never used an email package before starting on the project). Talk about this as being peculiar is a gross understatement, unfortunately such inane thinking underpins much of the basic design (Thunderbird is a quintessential, truly wonderful, example of Rube Goldberg/Heath Robinson design principles!)

5. At various times, I have tried to fix Thunderbird's limitations by applying various add-ons, and after installing sometimes up to about 35 I've just given up. Some things were fixed, others not, and there were inevitable interactions between these various add-ons. I could write a lengthy article about what is (still) not fixable with any number of add-ons; essentially though, the underlying code is so broken and haphazard that no add-on is able to fix some problems. ONE SHOULD NOT HAVE TO RELY ON ADD-ONS JUST TO OVERCOME FUNDAMENTAL DESIGN LIMITATIONS.

6. Thunderbird is slow in almost every aspect of its operation—truly unbelievably slow when compared to other packages of similar design.

From what I've read in this Thunderbird Mozilla post, I have little faith that the end product will ever satisfy serious email users (especially if lesser used features are dropped) which seems to be the proposal. Likely we'll end up with another mishmash similar to the confounded MS Office ribbon (that'll alienate most of its traditional user base—after all, Mozilla has been a past master at incompatibility for many years (every new version of Firefox has at least broken some my favourite add-ons, then there's the horrid Australis interface, and so on). Unfortunately, at Mozilla, developer culture has always taken precedent over user requirements; it would be foolhardy to think current Mozilla culture will change with a new Thunderbird design (corporate culture is always too ingrained to change that quickly).

Finally, it seems to me, that if Thunderbird's developers are actually serious about producing a better design for the majority of users (other than their own pet design) then they should open a web site to that effect and allow ordinary users to discuss and thrash out exactly what features they want within the new design. Perhaps they should include existing forks in such discussions, FossaMail for instance.

In the meantime, I reckon developers of other email clients have very little to worry about.

Re the editor, the Gecko editor component has long been plagued with the issue that the module owner didn't really want to hold that position. For a time, the owner was completely hostile to anything Thunderbird, despite the fact that Thunderbird was the heaviest and most notable implementation of the editor.

I will also point out that there is actually some fairly deep integration code within the Mozilla editor with Thunderbird's compose backend (particularly in regards to the need to generate inline embedded images). There have been attempts to replace the editor with a more functional one in the past, but they all came to naught.

Thanks for that reply. That makes sense. My comments about the editor were deliberately made from the perspective of the end user. Whilst I used hyperbole to emphasize the fact that the editor was the main culprit, I agree things usually are not that simple.

However, the key point I was trying to make still stands which is that irrespective of the state of the underlying code/Gecko editor components etc., etc., for some reason third party developers (here BlueGriffon's developers) have managed to tame the code in a much more successful way than Mozilla itself has done. The implication being that as principal developer Mozilla should have been able to do a better job than third party developers should. Thus, it amply demonstrates Mozilla's lack of commitment to the Thunderbird project per se (and that this has been so for a very long time (ipso facto, so have the bugs/problems) without Mozilla bothering to attend to them).

I am not a Thunderbird add-ons developer/TB code expert so there's little point me attempting it, but it would be very informative to find out why the BG editor works and the TB one is so brain-dead. As I see it, it's important to cut to the core of these problems if for no other reason than to show the skeptics or those who've simple requirements and find little or no problem with TB that there are real longstanding problems with Thunderbird and that some of us are not just being argumentative for the sake of it.

I guess we all have our opinions but if you are composing long emails with intricate formatting I'd suggest you're doing it wrong. Email messages should be short, and preferably plain text. You have a little more leeway than in a tweet, but more than a paragraph or so and you lose the reader. I see this so often -- people will send me a treatise in email and I simply cannot comprehend that much text on a computer screen. So it's either print it, or skip it. Guess what happens most often?

If you need to write something lengthy and heavily formatted, do it in a Google Doc or blog post and put a link in your email.

With respect, it is some time since I've read the various email RFCs (822/2822/1123 etc.), but I cannot recall any of these email standards saying that emails (a) have to be short and (b) that formatting doesn't matter. In fact, there are numbers of RFC standards that actually specify the standards for text formatting, for example, the Multipurpose Internet Mail Extensions (MIME) standards have allowed 'rich text' formatting in emails for years now.

Thus, to be compliant, email clients should comply with these email standards—this means their editors should also format text to those standards. I contend that there is indisputable evidence that Thunderbird does not fully comply with these internet standards by a considerable margin (nor has it ever done so). Moreover, in parts, Thunderbird is so bad/non-compliant that it is essentially not fit for purpose.

This has absolutely nothing whatsoever to do with the fact that some users will only ever use a subset of those features [standards] when composing emails.

As long as users comply with the email standards, they are entitled to use any formatting they so desire. Whilst many emails are short, the fact is that there are those who often send highly formatted emails of many pages in length.

As fauigerzigerk says, in many instances, attachments are often not suitable so they must be sent in-line. This then requires the editor to handle in-line text/images etc. correctly (Thunderbird does not do this without fault).

It's exactly the other way around for me. Any text that isn't directly in the email will either get ignored or I won't reply in as much detail as I would have. It's much more difficult to quote selectively from attached files so I don't do it.

And printing is about the most horrible thing ever invented. I only do it under threat of financial loss (return labels, letters to tax authorities). There's nothing as broken as printing. It never works flawlessly and I can't focus on printed text anyway.

Printed text has no search, no copy and paste, no changing font sizes or brightness, no hands free reading, no place to put paper without it getting fatty or full of coffee stains.

So I guess the conclusion has to be that there is no general right or wrong when it comes to the length of text in email. I depends on who you are sending it to. I pity whoever has to correspond with the both of us :-)

A paragraph or so these days is best sent in chat. We use email more for reference stuff in our setup (because searching for references in chat is terrible...)

Chat is for when there is someone on the other side listening, it's like a conversation but in text. Email is for when there is more asymmetry, the other person may or may not be there and an immediate response is not expected (shouldn't be anyway).

Could you explain how using the features of a product is "doing it wrong"? The only thing wrong would be the bugs in the features themselves.

It works great for me. :-)

Search could be smarter (and faster). Also I remember I had to do something tricky to make search default to "date" sorting instead of "relevance", and that should really just be in the preferences dialog somewhere.

But basically I have no complaints!

Sending mail in the background seems to be broken. You can enable it behind about:config, but then, at least on two of my machines, it doesn't work.

I consider this almost a deal-breaker. It's such a simple theory that just about every other GUI MUA gets right.

Filters are weird and inconsistent. Some messages don't show as filtered, or some filters won't run, until I close and restart the program.

Overall, it's a certain bare minimum of acceptable. It's not a great application.

Search is a generation behind Mail.app's search. It's pretty heavyweight and goes into the weeds wrt performance after a few weeks of uptime. It needs emacs key bindings.

Search is complete garbage, basically unusable.

It doesn't perform that well with some of my folders which are >300,000 messages.

(protip don't subscribe to LKML)

GMane.org [1] provides an NNTP (newsgroup) interface [2]. You can more easily set the automatic expiry rules for a newsgroup.

Careful configuration of the sending/reply address should let you reply to the mailing list by email as normal, or there may be a way using NNTP -- the documentation on the GMane website is missing, as they're rewriting the service.

[1] http://dir.gmane.org/gmane.linux.kernel

[2] nntp://news.gmane.org/gmane.linux.kernel

Not a one. Have run it for years and years and years, overloaded with extensions. It has never failed me.

But this! The post outlines a three year timeframe. I do not believe it. I believe Mozilla will be gone before three years, and Thunderbird with it, one way or the other.

> I believe Mozilla will be gone before three years, and Thunderbird with it, one way or the other.

That's a dramatic prediction! Why do you believe it?

They are rewriting Firefox out of any relevance. They had a distinct product with unique features. It has been loosing uniqueness, usability and mindshare ever since they began shadowing everything the Google guys did. Now they're going all in, turning the thing into a functional Chrome clone. Once the user base drops below a certain percentage, there will be no point for anyone in sponsoring the show any longer.

Me, I was a loyal user since the Phoenix days. I have recently Firefox. It is not unusable yet, but it will be in about half a year.

I also started with Phoenix, and I share your dissatisfaction with the direction of Firefox; but its transformation into a Chrome clone, while regrettable, is not a new thing. Is there some recent change that you think makes the dissolution of Mozilla (not just the Firefox project!) particularly likely?

For what it's worth, I like the proposal, in large part because it is a rewrite with an aim to implement a full-featured cross-platform mail client. Something fresh but with the spirit of Thunderbird and consistent with the Mozilla credo appeals to me.

But to answer your question, I and several others I know whom use Thunderbird consider it a "least awful" choice. It's less complicated, opinionated, and buggy that Outlook. It's cross-platform unlike some of the other top-tier options. And it's less centralized, surveilled, and inverse-productized than third-party web-based email such as Gmail. It supports multiple accounts, through add-ons it supports GPG, it blocks bad HTML in messages, and for the most part it works well enough.

However, yes, I do have a lot of problems with Thunrderbird, ranging from daily annoyances to minor pet peeves. Reviewing my Bugzilla votes would be exhausting, but some highlights:

As others have pointed out, the search functionality is poor. It's slower than alternative clients (e.g., Opera Mail) and less accurate. It also opens to a low-value "search results" view rather than a list view. ( See https://bugzilla.mozilla.org/show_bug.cgi?id=580252 ) It's not easy to quickly execute a search on the current folder only. The full search is so frustrating that I am in the habit of using the quick-filter bar (control-shift-K) because it works as I feel an e-mail search should work, but woe to the user who has "Body" selected in that UI control since the filter function does not use the search index. Also, why does ESC hide the quick-filter bar?

Addressing is slow even on extremely fast workstations, to the point of routinely causing me to need to correct addressing errors. However, they recently fixed bug 1012397 so that resolution will occur after a blur of an addressing field. Yay! ( See https://bugzilla.mozilla.org/show_bug.cgi?id=1012397 ) Though other composition / addressing quirks such an improper initial focus on the composition pane still remain. ( See https://bugzilla.mozilla.org/show_bug.cgi?id=329482 )

The email composition window is often slowed by activity occurring elsewhere within Thunderbird. If Thunderbird is working on moving a bunch of messages, for example, it can sometimes struggle to keep pace with typing in a composition window, on workstations with 8 or 16 modern CPU cores and NVMe SSDs.

All told, I would also be more or less happy with ongoing improvement to the existing product. But I understand that may not be viable if the underlying technologies start fading away.

" <...> [Thunderbird] consider it a "least awful" choice. It's less complicated, opinionated, and buggy that Outlook. It's cross-platform unlike some of the other top-tier options. <...>"

Absolutely correct, it's why we have to put up a strong clear-cut case now to ensure the developers know exactly what we users want. To do just that will, on occasions, require us to be very specific.

We should not be the slightest bit shy about complaining.

"JavaScript is the best choice."

(Citation Needed).

This proposal identifies serious legitimate concerns with Thunderbird development going forward, but the proposed solution looks more like a hammer seeking a nail than a thoughtful approach to addressing the concerns.

Yeah, I cringed at the JS thing. Why not do it in Rust and start with some of the Servo code as a base? That would give the developers an intermediate application to work with that doesn't require the full capability of a web browser.

The whole tirade read like a thinly veiled "building an Electron-based MUA is just easier by now", which is a thing I've been contemplating toying with because, to paraphrase another well-known MUA, all those desktop email clients† flat out suck and the best ones are barely above the tolerable threshold.

> Why not do it in Rust and start with some of the Servo code as a base?

Thought about it, but I think Servo might just not be that ready yet given the expected timeframe. Could be of a great synergy and a nice real-life testbed for Servo though.

† I've extensively used a lot on various OSes, from Claws to Gmail (web) to mutt to Mail.app to Eudora to Fastmail (web) to Outlook to AirMail. For none of them could I ever say "nailed it" and while some do have their pluses they're all broken one way or another which brings the whole package down.

You say that desktop email clients all suck. Is there a web-based client that, in your opinion, doesn't?

Well, the author seems thoughtful, but I'm sure he's seeking replies on the mailing list. You could propose something else!

They've already neglected Thunderbird for years, and now they want to start from scratch? Doesn't sound like a good idea. Sounds more like another project they will shut down after a while.

I used to use both Thunderbird and Firefox a few years ago as my main mail client and browser. Since then, Mozilla started spreading between too many projects, chasing the failed phone thing, and both Firefox and even worse Thunderbird are nowhere near where their competitors are.

I now use Google Chrome and Google Inbox (via Electron app Wavebox, formerly WMail), and they actually look from this century. I downloaded Thunderbird a few months ago out of nostalgia, and everything looks the same as 5 years ago. Pretty sad.

I think Thunderbird is fine how it is. I think a lot of the projects Mozilla takes on are stupid (Rust being a giant exception, I love Rust).

You know what I want? NWJS/Electron but using Firefox/Spidermonkey. I want to package desktop apps with Firefox. They almost had this with xulrunner but killed it for some reason. And I want them to build crosswalk (https://crosswalk-project.org/) for mobile, but with Firefox. The only real reason is that I don't trust Google or anything they touch, and I've never actually been able to build Chromium/NWJS from source (such a complicated build), which worries me.

Call me paranoid, but the monoculture around Chromium creeps me out and I'd really like a viable alternative from Mozilla. Seems like they jumped ship from the packaged HTML5 desktop/mobile app paradigm right when it started getting popular.

There actually was a fork of node.js that used SpiderMonkey.

IMHO, one of Mozilla's greatest failures was its decision to more or less give up on embedding (for both SpiderMonkey and Gecko). They effectively killed off embedding in the process of moving to the train model back in 2011, 2012, but back then, the expectation was that they would have their 2 years of "let's kill our broken architecture." Instead, it sort of ended up dragging on how long it would take them to stabilize some APIs for embedding, and they certainly never bothered to try to maintain any documentation (I briefly attempted to maintain some client application that used SpiderMonkey in 2011, and it was a headache trying to find any sort of documentation on how to fix each incremental bustage, since everything that was found on MDN was woefully out of date).

First, there was to be some sort of IPC-based embedding mechanism in Gecko. Then that idea was nixed in favor of just XULRunner. Then Mozilla decided it didn't want to maintain XULRunner anymore. For a period of time, they had a XULRunner-like setup called something like webapprt (which was basically a Firefox sans normal Firefox UI), but that too was killed off within a few years.

https://github.com/mozilla/positron is a thing, though not under active development right now.

> They've already neglected Thunderbird for years, and now they want to start from scratch?

If by "they" you are referring to Mozilla: they will not be involved in the rewrite.

Thunderbird, like Firefox, can be themed, and many are available. Well, until they finish killing XUL... what an awful decision. Point being that it's a mail client for power users, and generally requires a little customization.

It's deeper than the theme.

It's the paradigm, the absence of automatic sorting of emails (priority/promo, etc.), failure of prioritizing common actions in the UI (everything is the same, the spam folder and the inbox folder are given the same importance, "compose" is not prominent, etc.). I could go on forever.

IMO, it's kind of how good software was made 10 years ago, but now we're used to much better.

Compose is C-n, and the "Write" button in the default toolbar.

Not sure what priority/promo is, but Thunderbird certainly can sort by any field by default. It sounds like you want a client that is tightly coupled with Gmail's features, and you're not going to get that with a non-Google client.

Note that some customizations, like Firefox, require accessing about:config. Also, as with Firefox, most Thunderbird users will benefit from perusing extensions. I wouldn't be surprised if there are some extensions that offer the more Gmail-centric experience you want.

I don't have time right now to explain myself better, it's the minimalism and some features like snoozing emails, quickly marking them as done/low-priority and similar things, which is definitely not something that is connected to Google technology.

> It sounds like you want a client that is tightly coupled with Gmail's features

I actually don't like Gmail that much.

> you're not going to get that with a non-Google client.

Google Inbox used be called Sparrow (https://en.wikipedia.org/wiki/Sparrow_(email_client)), which was a regular app that Google acquired. I used it since the beginning. It was a new paradigm back in 2011, which is now the standard in modern clients.

Thunderbird needs to rethink their approach. They need less buttons and more focus on important features over other ones you barely use. In Thunderbird, everything is given the same importance in the UI. There's a toolbar with 100 buttons of the same size: "Write, Chat, Reply, Reply all, Archive, Address book, Get email, Tag, Quick filter". Why is "Chat" the same size as "Write", and right next to it like it's the most common feature in an email client? Why is "Address book" even there, given the same importance as "Write"? Who browses his address book randomly? Why can't they just show suggestions when I'm in the compose window and I type the first few letters of the person's name or email?

I could go on forever.

There's a toolbar with 100 buttons of the same size: "Write, Chat, Reply, Reply all, Archive, Address book, Get email, Tag, Quick filter".

My main Thunderbird toolbar has get mail, write new message and quick filtering. It took me perhaps 10 seconds back when I first installed it on this computer to hide a couple of other buttons like chat that I don't use myself.

The second toolbar when I have a message open has just 5 buttons (reply, reply all, forward, mark as junk, delete) and I use all of them frequently.

I agree with your general point that clean UIs that prioritise more important features tend to be nicer to use, but I think you're dramatically overstating the problem here.

Why can't they just show suggestions when I'm in the compose window and I type the first few letters of the person's name or email?

That's exactly what it does, and has for as long as I can remember.

> My main Thunderbird toolbar has get mail, write new message and quick filtering. It took me perhaps 10 seconds back when I first installed it on this computer to hide a couple of other buttons like chat that I don't use myself.

That's not how it works. The authors have to take the time to study the situation, talk about it, make hard decisions and cut out features that are useless or barely useful, and have the balls to ship a product with just the right features instead of all the features in an attempt to please everyone. Not the user.

It shouldn't be the user who has to waste time and energy trying to figure out how to clean up the UI. That's exactly why people like myself are abandoning software like Thunderbird and moving to simpler, more thought-out stuff.

I don't know how much Mozilla cares about people using their product, but that I doubt that's how you get people to use your product.

The authors have to take the time to study the situation, talk about it, make hard decisions and cut out features that are useless or barely useful, and have the balls to ship a product with just the right features instead of all the features in an attempt to please everyone. Not the user.

You're perfectly entitled to that view, and for someone who holds that view a product like Thunderbird is obviously not a good fit.

There are, however, other views, and for someone who doesn't want simple UIs with no flexibility or configurability and doesn't have a problem with spending a few seconds customising something to get a result they are happier with, a product more like Thunderbird is a better fit.

I've talked to you before about pretty much the same kind of stuff.

We have opposite views.

Of course I only talk about personal preference, I'm aware that not everyone sees things the same way I do.

How many new email clients do you install per decade? If you chose a client based on a couple minutes of customization effort then you're almost certainly making an irrational decision.

Not to excuse bad UIs that slow down every single navigation, which adds up. But picking toolbar buttons is a one time cost.

> Google Inbox used be called Sparrow (https://en.wikipedia.org/wiki/Sparrow_(email_client)), which was a regular app that Google acquired. I used it since the beginning. It was a new paradigm back in 2011, which is now the standard in modern clients.

Could you name a few apps that have the Inbox/Sparrow features like snoozing an email until some time in the future?

I would love to have that, I looked for Thunderbird plugin for that but failed to find one.

Lots of them, on what OS are you? Apple Mail has it.

I'm on Linux and use Thunderbird (sometimes with Exchange integration, but that's not required).

Outlook has it. At least on iOS.

Is Firefox that far from Chrome? I thought it was ahead in some ways.

Maybe with web standards (maybe, I'm not sure), but not the rest.

Just the fact that the address bar font is the same size as the rest of the UI gives me the impression that they didn't think it through. Downloading files has the same problem, it's relegated in a small button, while it's one of the main features.

The whole interface is one of the most unintuitive things I've ever used, considering how simple a browser can be in terms of functionality the user must access. I'll also never forget they they thought tabs on top didn't make sense (it's actually still an option you can change).

Chrome had search integrated in the address bar from version 1, every time I opened Firefox year after year and I saw that little separate input for searching I felt like using grandma's browser.

In terms of how pretty the UI is, Firefox 53—which just got released—looks better, but it took them years to get to where Chrome was back at version 1.

Syncing of bookmarks, settings, addons, passwords, tabs across devices etc. on Firefox is a lot less efficient.

From a technological point of view, it took them years to implement sandboxing, and they're still not done. If a tab misbehaves in Firefox it can take down the whole thing. Chrome had it right away.

I briefly tried switching to Firefox again a few months ago. Initially I tried fixing it via changing the interface via XUL, but the problems were too deep. I got very frustrated and went back to Chrome.

It seems you prefer the more "modern" style of relying on Google's online services and Chrome's frequent updates. That's fine, but it's not an objective standard.

For example, some of us consider a UI that doesn't keep moving around every few weeks to be a feature, not a bug. I have absolutely no problem with a practical tool like Thunderbird still using the same layout it had 5 years ago, if that layout works well.

Likewise, some of us consider the separate search box of Firefox to be a plus point. I don't want or need everything I type in a URL bar being sent to Google's mothership, and my screen has ample space for both bars.

Meanwhile, I'm getting awfully bored of dealing with customer support issues that come down to someone using Google for their mail and not receiving legitimate messages because of whatever Google have broken, deemed spam, or unilaterally declared not to be acceptable this week. I shudder to think how much time and effort are being wasted like this around the world if everyone else's experience is as negative as ours has been lately.

I find the opposite to be true.

Apple Mail and Thunderbird give me a lot of false positives, and usually leave spam right in my inbox. Google—whom I'd assume look at what other users do with an email to figure out what's spam—always manage to filter out unwanted mail and keep legit emails in my inbox.

Both Apple Mail and Thunderbird are so dumb that they can't figure out I don't speak Chinese, and even after I mark 100 emails in Chinese as spam and have written 0 emails in Chinese since I've installed the apps, they happily fail to recognise emails in Chinese as spam and let them through.

Google—whom I'd assume look at what other users do with an email to figure out what's spam—always manage to filter out unwanted mail and keep legit emails in my inbox.

Unfortunately, your personal experience doesn't change the fact that Google do classify significant amounts of legitimate mail as spam. It appears that at some point in the somewhat recent past, they may have decided that literally anything new sent from a domain without SPF set up is spam, for example. That is simply broken, but they appear to have excessive spam filtering in other respects as well. We even see things like payment confirmation emails, which we are legally required to send and our customers might actually need, and which are basically factual plain text and a very lightly styled HTML version, getting rejected at times.

Personally, I'd rather a few false negatives hit my inbox and click the junk icon for a moment to deal with them than actually important things get lost in junk and opportunities missed as a result. I honestly have lost count of how many times I've seen that happen recently, but it's a lot, and it's almost invariably been a result of excessive spam controls by Google and one or two other big mail services.

> Unfortunately, your personal experience doesn't change the fact that Google do classify significant amounts of legitimate mail as spam.

I don't know, it's not happening to me using Google Inbox (not Gmail, have no idea about Gmail).

In gmail right now I have 50 emails in the spam folder. About 3 are actual spam. The rest are from automated mailing lists where most of the mails go into the inbox, but it rejects some at random. That's a terrible way for a spam filter to behave.

Several of these I specifically have incoming mail filters for, and they still go to spam at random.

I don't know about Gmail, I only use Google Inbox and I get 0 false positives.

Surely they wouldn't have different spam filters?

>Chrome had search integrated in the address bar from version 1, every time I opened Firefox year after year and I saw that little separate input for searching I felt like using grandma's browser.

As did Firefox, kinda, and they keep flip flopping on it. It used to be that if you type any string, it does a "I'm Feeling Lucky" search. Now, on my FF, it does a Google search. So it still works...

>From a technological point of view, it took them years to implement sandboxing, and they're still not done. If a tab misbehaves in Firefox it can take down the whole thing. Chrome had it right away.

I keep hearing this. Yet, Chrome still crashes for me. And at this point, FF is very stable.

I know every time I looked, FF + extensions still had much that I could not do in Chrome (including extensions). But it's been a few years - I wonder if Chrome has caught up in functionality?

> As did Firefox, kinda, and they keep flip flopping on it. It used to be that if you type any string, it does a "I'm Feeling Lucky" search. Now, on my FF, it does a Google search. So it still works...

The mozilla suite had it long before firefox too. This kept me on it for years after firefox was released.

>Just the fact that the address bar font is the same size as the rest of the UI gives me the impression that they didn't think it through. >.. >Chrome had search integrated in the address bar from version 1, every time I opened Firefox year after year and I saw that little separate input for searching I felt like using grandma's browser.

Most of these seem like opinion of aesthetics and fashion? Syncing and sandboxing seem to be the ones that are about actual functionalities.

Regarding those: I don't have many devices (actually only desktops), but syncing seems to work ok. Lack of sandboxing is actually valid point, but I don't remember any crashes in recent times. On the other hand, I block most of the JS, so there's less opportunities for things to crash.

The web standards and avoiding Chrome/Google Search-based monoculture are also important things for me, so I'm sticking with FF as long as it is OK.

> Syncing of bookmarks, settings, addons, passwords, tabs across devices etc. on Firefox is a lot less efficient.

Anything to back that up? I'm pretty happy with Firefox syncing.

I tried to switch to Chrome but it used a lot more memory than Firefox (and it was in days when Firefox was know for using much memory, Chrome somehow was able to get ahead on that also).

I'm only speaking from experience.

One thing would be that with Chrome I can login with my username and password, and I get all my extensions synced the first time I install it or I'm on a friend's computer, while with Firefox I have to wait for their confirmation email, click on it, then wait for it to sync.

You might argue that Firefox's approach is more secure, but every single website in existence is fine with my username and password—including online banking—and I think Firefox is the only software that make me do that extra step.

It's the little things, Firefox just seems to not care about my time. Too many buttons that I'm supposed to hide myself while they should've known no one uses them, too many steps to get to that setting, etc. etc.

FireFox extensions are more powerful than Chrome's, but FF is killing that off this November...

Hmm, I thought Mozilla had pulled financial support from Thunderbird? This would be an exciting new chapter for the product, but the article doesn't address whether it makes financial sense for Mozilla to invest this much in Thunderbird's future.

For most of the last three years I've worked on Nylas Mail (https://github.com/Nylas/Nylas-mail), and it hit 2.0 yesterday with Mac/Win/Linux support. It's entirely open source (GPL), written in JavaScript, syncs mail locally, etc. It essentially -is- what the author of the post is looking to build, except it doesn't look like Thunderbird. Nylas put at least $2M+ worth of engineering time into it, and I imagine ThunderbirdJS would take at least a similar commitment of time and effort. Heck, maybe they could just skin Nylas Mail and call it Thunderbird ;-)

Is the "open source" label still comically misleading? [0]

I tried it out, didn't read the fine print, filed an issue, never looked at it again.

Because "It keeps user data local and private." is kind of one of the main benefits.

[0]: https://github.com/nylas/nylas-mail/issues/860

Ahh thanks I need to update that!

Originally Nylas Mail was OSS, but tied to the Nylas Cloud APIs (which did the actual mail processing.)

The cloud strategy was too expensive, and in version 2.0 the entire mail-sync system was moved into the client and open sourced. (https://github.com/nylas/nylas-mail/tree/master/packages/cli...). It's now much more like Thunderbird. There's a bit of cloud processing for snoozing / send later, etc., but it no longer syncs all your email through the cloud.

Is there a way to configure it so it makes zero requests to your servers?

If not (yet), would it at least be technically feasible, and would supporting this be an option for you?

Definitely feasible but it's not our product focus right now. Most of the features that help differentiate Nylas Mail require some cloud component. (snoozing, send later, reminders, open tracking, etc.)

We totally encourage folks to fork the project and take it in whatever direction they want. If you want to chat with other devs in the community, you should join our Slack room: http://slack-invite.nylas.com/

(I work at Nylas)

> (snoozing, send later, reminders, open tracking, etc.)

None of that has any appeal to me, I'd much rather a mail system which doesn't require using someone else's server.

Maybe this isn't a priority for other people, but just putting it out there. This is what's making me not use Nylas today.

He's already given you a good alternative – fork and collaborate with other devs on a version that doesn't touch their server.

Seems sufficient.

I would consider forking a last option, instead of "a good alternative".

A good alternative in my opinion would be just to make some parts optional. Does not sound too hard, to implement (if the codebase is well done)

I remember the last time I looked at Nylas, it was a fancy gmail frontend. Now it appears to require a "Nylas ID" which is not something I need. I don't want my mail being synced to someone else's computer. Where's the "host your own sync system" package?

Honestly when I was reading this post, I was thinking "Why don't they just use Nylas? Nylas has already done this" – it just seems like a perfect case of not-invented-here.

I really don't see the point of Thunderbird reinventing the wheel to essentially build another Nylas.

That was honestly my thoughts too.

I used Thunderbird years ago; now I'm a very happy Nylas user. I don't doubt that the Thunderbird team could spend the next 3 years building a very polished desktop mail app using web technologies, but uh...

...do we need another? And if so, wouldn't it be better to fork Nylas as a base? I mean, they could probably get most of the way their with a couple pull requests to make themes more powerful and a custom theme...

Congrats on your work on Nylas -- 2.0 is shaping up great and is already my primary email client on Linux.

Question: Will the revenue from the Pro product really support development and maintenance of the free product? The free product is perfect for my needs, none of the Pro features are that useful for me (and its too expensive - email accounts from Google or Fastmail are $5/month, Nylas Pro is $12/month on top of that just for the client). The free product, as is today, is easily worth $20-30, IMO.

Additional Comment: https://www.nylas.com/pricing needs to be updated. A lot of the Pro features are now available in the Free 2.0 version.

I suppose they want to use their own UI and maybe link to some services or tools from Mozilla. But they should contact you to unite their effort with your: development time reduced from 3 years to 3 months (that is an approximation)...

At the very least I don't need a "Nylas ID" and Nylas cloud stuff with Thunderbird. Just a client and (my own) IMAP server.

> Heck, maybe they could just skin Nylas Mail and call it Thunderbird ;-)

Skin it or Fork and Skin ;)

That look really good.

Great job.

If it becomes yet another Electron package it is time to look elsewhere.

Perhaps the idea to implement it as web technology is to leverage NPM so that millions of plugins can be made available to an email client.

Now you have 100,000 problems.

I wonder, if they want to use JS, why not QtQuick? I'm a heavy Thunderbird user but I would move to pretty much anything else if it were to switch to Electron.

I think the reason QtQuick hasn't taken over this space, is that you still need to deal with C++ and cross-compiling. If QT had an option that made it clear you could develop and distribute in JavaScript only, that would be a hit.

You can write QML apps in like every popular language, there are well supported bindings everywhere.

I dont get the C++ hate though. C++11 and up is a totally new language and much more productive than its reputation gives it.

It would be neat if TB would be rebased on top of Servo (and Rust) as a flagship application for using Servo as an GUI foundation, the same way as TB previously was for Gecko/XUL.

Sadly I doubt TB has the resources to make that happen, but still, it would be neat...

I wonder if basing a desktop application on top of Servo would be any more painful than on any of the existing self contained HTML/JS delivery mechanism. It probably would be annoying until Servo reaches parity not to be able to use the web technologies to their fullest extent, but at least you have one (admittedly moving) target.

People have done this, not just for desktop applications but also for Android apps, using Servo to display a web UI on mobile.

And there's some work in progress to put a WebView-compatible API on top of Servo, making it trivial to substitute it in an arbitrary application.

Before we start thinking about working on Thunderbird or its replacement there is a fundamental question that needs answering. Is there a future for email? Email is/was a function of the personal computer era. But as PC sales decline and smart phone sales grow do people still use email to the same extent? Is its place in field of personal communications being replaced by SMS, etc. In the business arena I am seeing some companies where internal email is not allowed. The reasoning is that email has become a way of procrastinating (send and forget). On the customer facing side of things email is being replaced by web based customer service apps that use AI (or similar) to answer the customers query ASAP, and if that is not possible get the info and pass on to a human if and only if needed (people cost money). So back to the question is email and by extension Thunderbird obsolescent. Would effort in redeveloping TB be futile as it would wind up give us wonderful app just as email disappears.

"JavaScript, if used diligently and with good design, is a very efficient language. Both in execution time, but more importantly for developers. Personally, I wrote apps in many languages, including C++, Java and JavaScript. Of those, JavaScript is by far the most productive - I am personally 4-10 times as productive as with C++."

Not trying to start a this language is better flame war, but is this true? I still find JS to be a strange and incomplete feeling language, but I've not really done much outside of front end work with it. Is it really that productive?

Also I've disliked every interaction with NPM. You end up with a huge chain of decencies for even simple applications. Is this something that's workable with production software?

I suspect it is true that among Java, C++ and JavaScript, disciplined well designed JavaScript is easier for developers, and reasonably efficient in execution (given e.g. v8). Especially compared to C++, the memory safety and speed of the compile->run->debug cycle tend to give JavaScript an edge for more programmers (x4 to x10 is of course subjective).

But that doesn't mean JavaScript is a good language. e.g., you have to be extremely careful to not get bitten by the floating point-only math. It was the source of catastrophic bugs for many Twitter clients (in the sense that they stopped working) -- I would hate to find such a bug ate my local mail store.

Not sure what I'd recommend, though - JavaScript is technically bad, but socially excellent for such a project. Python is not fast enough for it (PyPy not withstanding), D/Rust/Nim/Ocaml/Scala are not mainstream enough.

I work for a company that uses mostly Node.js for their production microservices. It works very well. Joyent wrote their entire private / public cloud in Node.js. https://github.com/joyent/

It is definitely production workable. It's "LTS" cycle is insane, but it's workable.

Sounds like a terrible idea, please no. I for one probably will stop using thunderbird if it gets rewritten in JS.

What is it written in now? If I remember correctly it's mostly JS with a few native extensions in the chrome.

The backend is mostly in pure C++ (~500KLOC or so). The frontend is in JS (~200KLOC or so).

Looks like a combination of JS and C++, see for example https://dxr.mozilla.org/comm-central/source/db/mork/src

I'd rather see projects like Cyberfox, Thunderbird, Palemoon and Evolus Pencil (which, sadly, has been rewritten by now) taking up xulrunner, fork it and continue developing it.

I have yet to find a better system for rapid application development. XUL is wonderful, extentable, everybody know CSS and Javascript these days, XML is very well suited for such tasks. It's one of the best technologies for power-users I ever came around!

All that was ever needed would habe been a Mozilla, that creates an XUL IDE, rather than taking up on a lot of stupid projects (Persona Light Themes, Hello Chat, FirefoxOS, removing XPFE (how coding with XUL is actually called) and whatever (the only real good thing to mention would be Ubiquity, but they killed that off as well), oh, and let's not start talking about Firefoxy mugs, t-shirts, community barbecues, community videos... But hey, that's what happened.

Now, if some people would just fork xulrunner and mirrror the addons.mozilla.org stuff...

As for Thunderbird, I am also pretty satisfied as it is. It may be nice, if one could set certain To: email-addresses per folder (mailing-list folders would greatly benefit from that, along with subscribe/unsubscribe configured per such folder), alternate views onto mails and have, maybe, a modernized foldering-system.

> I have yet to find a better system for rapid application development. XUL is wonderful, extentable, everybody know CSS and Javascript these days, XML is very well suited for such tasks. It's one of the best technologies for power-users I ever came around!

It also looks awful and ignores desktop themeing. Or is that just firefox?

I'm just gonna say I oppose this proposal because I'm really tired of seeing developers shy away from utilizing or learning C/C++ only to admit much later in a project's life cycle that those languages and their associated libraries are the best for the job. I'm all ears on utilizing JS for front end to even a desktop application but if the entire thing gets written to be ran on Servo or whatever browser engine they choose then I oppose it categorically. JS might be fine for some things but as a general programming language on a substandard runtime is just asking for trouble. Learn to write in C/C++ for native applications or go home.

Why do you oppose things being run on something like Servo categorically?

Because there's existing libraries which solve many of the same problems which they inevitably run into and then re-implement them in JS. The "not invented here" mentality has to stop. Unless there's a significant reason to not utilize a library then it shouldn't be avoided. There's no good reason to replicate that functionality.

The "not invented here" mentality has to stop.

This is true, but the track record of bugs and poor security inherent in using relatively low-level languages like C and C++ for everyday Internet-connected applications also has to stop.

That doesn't really help you when the platform you run on be it a browser or a virtual machine is written in C/C++ which by implication can be exposed to the same security flaws if/when they utilize unsafe design patterns or idioms. So, all you've done is pass the buck onto Servo/Gecko/Safari. The reality is that you can't make an argument that's ironclad in favor of forcing JS to become the new C. Let JS do it's wonders for the web and let C/C++ and other languages that have great native application tools do their wonders for the desktop?

I didn't say anything about using JS as the alternative. I happen to think it's a rather poor language and that using it for anything other than running front-end code on a web site until we have better alternatives is usually a mistake. But there are a lot more languages out there than C, C++ and JS, and I don't think any of those is a particularly good choice for this sort of task.

Oh no doubt there's better languages in terms of general purpose programming. I'm biased towards OCaml myself since it has nice syntax but there's plenty of options to choose from. I'm just pointing to C/C++ languages since they're the most mature and widely available in terms of documentation, IDEs, etc.

Note that this is from the end of March, and the thread continues at https://mail.mozilla.org/pipermail/tb-planning/2017-April/th...

> We need 2 persons for the framework, 3 for backend modules, 4 for frontend UI, and 1 for theming.

Doesn't 4 people dedicated to front-end UI seem excessive/unnecessary? At least, at the beginning? I would dedicate almost all work to the framework and backend modules; UI with web technologies is far from complicated compared to everything else the client would require.

The mockups look very promising. I was never a TB user because it never looked the part in Gnome, but it's something I've kept an eye on and recommended to other people.


I skimmed through this and saw no management of PGP, encryption, key storage, or key exhange. Is that not going to be one of the main focuses of this? I wish that PGP/encrypted mail would be a main feature post Snowden.

The one thing i'd like to see is some kind of integration of the Signal protocol-- preferably in a way that supports federation as (1) having OpenWhisper Systems as a single point of failure for all email is not a good idea and (2) having to tie one's email to a phone number is sheer insanity. It's bad enough with messaging.

Why not rewrite it in Graphene, which is the Servo's foundation for browser.html?


title should be the one of the submitted e-mail: "Proposal to start a new implementation of Thunderbird based on web technologies", especially since "is in the works" doesn't seem to be the case yet. (Lots of discussion, continuing into April, but unless I missed it no actual decision made and work begun yet.)

The thread is worth a read, interesting arguments regarding rewrite/refactor/approaches to transition.

According to Cambridge Dictionary "in the works" has the following meaning:

  in the process of being planned or done
Thunderbird replacement is currently being planned, so I think it's correct.

I think it's that "in the works" seems to imply an agreement/commitment, but this appears to be a proposal.

This is a post[0] from one of the project leaders:

However, I think we all agree we want the Thunderbird replacement to be a desktop client (plus other platforms like mobile), and based on web technologies, most importantly written in JavaScript.

But the title has now been changed and that is fine with me.


The only point I could argue with is the choice of JavaScript, all the others seem inevitable. As a Thunderbird user I'm happy to know that I might be using it for another 20 years.

Even JavaScript is not that bad. I not familiar with Electron: do those apps run from a directory with the source code or are a binary file? Running from source code would make it easy to hack with the code, which is good.

Yep! Electron essentially just launches a web app from a directory on disk in an included copy of Chromium, with NodeJS's JavaScript bindings as well as the usual ones. The web app has an index.html, CSS, all the standard stuff. It's usually packaged into a .asar file so things can be loaded faster, but it's great for hackability.

Thunderbird already uses a lot of JS. The only difference I think is that Thunderbird works on the XUL instead of the HTML DOM.

> We must pay attention to also keep technical qualities that many of our users rely on. An obvious one is that the new implementation must be able to quickly scroll through a list of up to 100000 messages.

Does any cross-platform GUI toolkit have a widget that can handle this with sane defaults?

Qt, as long as you back the view with a model with O(1) lookup, can handle up to INT_MAX rows perfectly fast. I expect other cross-platform GUI toolkits work similarly. Most native table/list views work on an assumption of uniform row height and thus handle huge lists with no trouble.

The problem browser based apps run into is rendering the entire list into the DOM and thus the browser has to lay out the whole thing in order to compute scroll bars and scroll positions.

You can work around this using requestAnimationFrame, large empty padding divs, and inspecting the scroll position to create DOM elements for only things that you compute are visible. At my last job I implemented a web based table that could do 60fps scrolling on 100,000 items that were all dynamically updating using js_of_ocaml and https://github.com/janestreet/incr_dom.

There's also toolkits like React-Virtualized: https://github.com/bvaughn/react-virtualized .

> quickly scroll through a list of up to 100000 messages.

You can do this with JS and HTML. There are some popular small JS libs that do just that.

It works like this: it creates a div with a very big "height" value to get the scrollbar look like there is a long list, and JS just loads in the visible area plus a few items above and below, and reloads data as you scroll. It works very good in Chrome and Firefox, and even okay in IE11.

Does it still work well if I click-drag the scrollbar very quickly from the top to the middle or bottom of the list? Or if I use a keyboard shortcut to jump immediately to beginning or end?

They actually talk about this a little way deeper into the thread. Here is a prototype they made


Yes, that's the point. The div is a normal HTML element with a normal scrollbar.

Does any human have a brain which can skim read 100,000 email subjects?

10/second for 2.5 hours, no pause, no breaks.

You read those emails? You acted on them? You remember what's in them? Archived data is a hoarding disorder, a garbage heap.

That is awesome! I actually toyed with the same idea a couple of months ago and started a prototype, but in the end it was too much work for a single developer (having to implement IMAP/POP backends, etc. in addition to the UI).

Using web technologies for desktop apps is not ideal, but at the same time it's probably the easiest way these days to build cross-platform apps because of the lack of a good cross-platform UI toolkit.

A big benefit I see is that it will make it very hackable as a lot of developers are familiar with web technologies. That should be a good way to get a lot of contributors to implement features and innovate (See for example the community / contributions around Visual Studio Code).

Mozilla already has a mail client written in Javascript and HTML 5 - the one shipping in Firefox OS.

And it worked decently.

Start by tidying it up for Android and then port it to desktop. One code base - for mobile, tablet and desktop.

I am a bit extreme here as I think Mozilla shall reduce efforts on firefox and make thunderbird a great product instead, one reason is that chrome is too powerful to beat already, and thunderbird could become the universal email client for all, not much contender there yet.

after using slack for a while i feel we can use one slack-channel for each email contact, a bit like google wave probably, and thunderbird can merge email+slack experience into one.

If Mozilla manages to build a product based on Servo that kicks Electron's ass (safer, faster, cheaper to distribute, etc.), then I am not sure that Chrome cannot be beat (or be seriously challenged).

This Electron competitor would become very popular, and it could become the "entry drug" into Rust development (you would be able to do everything in HTML/CSS/JS but you would also have the option to code some parts in Rust, for more power), which would also grow the number of Servo contributors. With a large enough community, Servo-based Firefox could fight for a place at being the best browser (safest, fastest, full-featured).

Whatever you do, make it render emails in a sane way. I still prefer mutt text-only rendering of emails (content) than any email rendering software, but if you're going to render and digest html, actually do it. The total time involved in and barbarity with which web atrocities have been committed to make emails render correctly in Outlook or even Gmail cannot be understated.

I wish I could freeze the program Thunderbird in time to keep it precisely how it is right now for the next couple of decades. I literally want not change. I know, I know. It's a pipe dream, the surrounding environment changes, breaking the program as the OS and libraries evolve. But this constant resolving of perfectly solved problems annoys me.

  git clone <thunderbird-url>
  <build from source and sudo make install>
^ there you go. A stable thunderbird branch that will work mostly forever. Every time an API changes just shove it in another iteration of a virtual machine :P

Thank you, I know all of that. I like native though. So, both VM and HTML5+JS are things I try to avoid for convenience messaging tools I use many times every day.

It's maintenance. Sometimes it has to be somewhat radical.

I hope for two things.

1) Drag attachments to folders finally works on Linux.

2) Message filters keep working exactly as they are now or it's going to be a huge pain to migrate them. And a showstopper with no filters.

I like the idea of using web technologies for desktop application. The only major problem right now is that each application uses at least 1.5-2g of RAM each since it basically launches a full web browser under it (and chromium loves ram). We will need enormous amount of RAM soon if all applications starts to go that way...

Thunderbird has browser engine to display html emails anyway. And probably most of Thunderbird's code is already in javascript, but using XUL instead of HTML DOM.

So it'll be a self-hosted webmail service with a custom web server that runs locally?

That doesn't seem to be what they're aiming for here. The goal is supposed to be a new UI that looks and functions very similar to today's.

That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Obviously there are some relevant standards here and you could set something like this up with enough technical knowledge using other tools that already exist. However, that reduces the potential market by a few orders of magnitude to those who are sufficiently expert with those tools, and then probably by a few orders more for those who have the time to actually do it.

> That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Uh, that's exactly what an email server does. Thunderbird is just the client used to access it from any device.

Assuming by "email server" you mean an SMTP server, that's not quite what I'm talking about. What I'm looking for is more akin to a mail store, an IMAP server, and functionality for sending and receiving via actual SMTP server(s). That's a separate set of responsibilities to reading or composing messages, which would just need something like an IMAP-compatible client. And all of those are separate responsibilities to a full SMTP server with all the administrative overheads that comes with.

You could do the back office part of what I'm talking about with tools like Dovecot and fetchmail today, running on a Linux server with a standard Maildir backing store, and then you could run Thunderbird purely for its IMAP client capabilities as a front-end, but setting it all up and maintaining it is a horrendous hassle and it's far too technically demanding for most users anyway.

However, separating the receive/store/send responsibilities from the read/write responsibilities would mean you could have a single store on any server with relatively straightforward set-up to actually send and receive mail, which you could then access from any device on your network (or over a VPN or the Internet if it's running on a remotely accessible box), without the risks and overheads of both running your own SMTP server and trying to get mail from it actually accepted anywhere else these days.

Now that everyone's got PCs, laptops, tablets, phones, and who knows what else, I think this is probably the single most limiting problem with traditional offline email clients compared to all the hosted webmail services, but it shouldn't be necessary to incur all the downsides of those hosted webmail services just to access your mail from different devices.

IMAP is that single store. Setting up a server just for that would be just as impossible for most users as settings up a mail server would be.

An IMAP server alone typically doesn't include the equivalents of fetchmail and the like. It just provides a protocol for remotely accessing the mail store.

However, I don't see why you think it would be impossible for most users to set up what I'm describing. If they can install Thunderbird and configure it to retrieve mail from their ISP or GMail or whatever, they could install a two-part system and configure the store part to do the same using exactly the same information.

In particular, just installing both parts on a single PC would work fine and provide equivalent functionality to current standalone mail clients like Thunderbird. You just have the flexibility to connect other devices to the same store and safely access your mail from those as well, or to install the store part on some other place on the network like an office server or maybe a NAS at home if you want to.

> However, I don't see why you think it would be impossible for most users to set up what I'm describing. If they can install Thunderbird and configure it to retrieve mail from their ISP or GMail or whatever, they could install a two-part system and configure the store part to do the same using exactly the same information.

Then to connect from their mobile they have to open ports on their home networks, get a static IP, know what their IP is to enter it on their phone, worry about a whole host of new security issues.

At that point you may as well run a full mail server.

Many ISPs offer a static IP. This is applicable for small businesses as well, and they almost certainly have one. Anyone with VPN on their router to access anything remotely has a way in.

There are difficulties in running a full mail server far beyond this. For example, many ISPs won't let you run one on anything below a high-level business plan without just blocking port 25 and friends at a firewall. Even if you can, many other mail servers will flag anything you send as likely junk mail if you're not running a well-known mail server yourself. For incoming mail, you need something that's going to be up 24/7/365 if you're going to give it as the MX for your domain, and you need to be constantly monitoring for security issues in real time, because if you're even a few hours late with the patch then you're probably running an open relay already and you just made every blacklist on the Internet.

Basically, if you're not big enough to have your own full time IT department, there are huge practical advantages to sending and receiving your mail via a dedicated SMTP server run by someone who does. These are completely unrelated to the usefulness of having a centralised mail store that can be used from anywhere on your network, or beyond if you provide a way in for remote access.

Was going to reply with the same - it is called IMAP

The backstory here is that Thunderbird devs would like to be faster but have a hard time working against the Gecko changes that breaks their build.

Sure Thunderbird kind-of works, as in it's "done", but people find Security bugs in the Firefox base and it's not sure how they apply to Thunderbird to Thunderbird has to take the update and then they have to deal with the breakage and the incompatibility. You can't just stop and be on Firefox 45 forever. That's just asking for trouble.

If it's scoped for 3 years, does that mean it'll take 9? =P

I really like my hosted email because it's not on my computer. I love offline software, but it all sucks for security. Dropbox, Evernote, Outlook, etc. They all just dump my data in a folder anyone with physical access to my very stealable laptop can get at. Email is especially terrifying because there's just so much personal info in there. I have evernote and dropbox sitting in a bitlocker, so that's okay-ish, but the email thing is just too much.

You have heard of this awesome new thing called "Complete System encription"?

A couple of days ago I reached out to users to give a morale booster to the devs as they try to figure this rewrite business out: https://www.reddit.com/r/linux/comments/65upot/show_some_lov...

I like the gpg integration using enigmail in Thunderbird. So I can send encrypted messages to my friends and people I write code with.

You'll be happy to learn that the P=P folks are most likely going to be handling full end to end encryption integration for Thunderbird, for the current version, and the new one (if it happens):


> JavaScript

Nylas all over again... Why complicate and bloat things as if it's the obvious sensible choice?

The time to finally learn how to configure mutt is that much close...

The sieve plugin is still broken :-( What's the alternative when using Thunderbird?

After many years waiting, maybe we will have a compose new email on a tab.

God no, unless there is a way to disable it. I hate tabs in Thunderbird.

Please no. Im very happy with current state of Thunderbird.

Interesting that mithril.js gets a mention. I really like it.

Was that mentioned in one of the replies? I don't see any specific libraries mentioned in the linked message, or the other replies I searched through.

edit: Scratch that, it was in this reply: https://mail.mozilla.org/pipermail/tb-planning/2017-March/00... . "I'd suggest using TypeScript, Mithril.js, Tachyons, and Node.js for the base technologies -- probably with Mocha/Chai for testing. Later we can make a more stand-alone desktop version with Electron or such. We could use socket.io to push notifications for changes in real or virtual folders and then use Mithril.js (a vdom library) to quickly rerender changed data the client UI requests (or is pushed)."

Worth noting that reply looks more like a wishlist of stuff than a meaningful viable proposal.

FWIW that reply appears to be someone who's serious about this proposal: https://github.com/pdfernhout/Twirlip2

Mozilla just doesn't get the message.... We don't want your features, fixes, refreshes, rebranding, or re-imagining. We want a browser that is fast, stable, secure, minimal, and that DOES NOT FIGHT US. Let me load my old SSL certs (a warning is fine). Let me keep my preferences (why does https:// disappear from my address bar every update, and my search bar keep switching back to case sensitive).

Stop making your problems worse and get your $#!% together! I'm a sysadmin, dangit, I need this tool to work!

So Thunderbird is moving away from legacy technology that was built to make Mozilla/Firefox more than just a browser. They are doing this to be free to improve Firefox to make it more stable, fast, secure and minimal.

This leads to a completely independent Mozilla project, Thunderbird, that relied on this technology to get the axe.

That project thus is discussing taking the difficult technical step to start from scratch while keeping the user experience the same its been for 10 years.

This, in turn, leads to you criticising Mozilla for not focusing on making their browser fast, stable and secure. Because you are hitting some configuration/update/UI bugs that seem entirely unrelated to the core browsing experience. Thunderbird, BTW, has 25 million users. So even if you don't need it, some people do.

They allegedly made the browser fast when they split the Mozilla suite into Firefox and Thunderbird. I am using both of them as my main browser, mail client and web dev platform, they both work fine although a bit sluggish. Opera feels a lot faster for instance and the debugger is pretty clean and usable, in fact is the cleanest of the whole bunch with Chrome dev tools being the most clutteted.

The resource allocation decisions mozilla has been making is driving me away from their products. Throwing resources at recreating thunderbird with a new framework is a poor use of their time.

You are still not paying attention. Mozilla has decided to _not_ throw resources at Thunderbird anymore. The outcome of that is that the _community_ is debating to move away from the to be deprecated XUL platform.

Well, the web is evolving.

If you're a sysadmin and you test everything in an ancient version of Firefox that doesn't display SSL errors, you're not getting an accurate picture of what the product's users will see. The latest browsers might entirely block people from visiting your site, display a huge warning, etc. and you wouldn't know. Maybe being a sysadmin requires getting the fixes, refreshes, rebranding as they come down the pipe? I'm also not a fan of the recent changes, just take a more defeatist attitude I guess!

No no no you missed what I am saying. I use horrible hardware appliances with built in md5 ssl certs for remote administration. I am not a web developer. I need to be able to access them to secure them and to work on hardware problems. This isn't even on the internet, this is on a local lan serving a small business. We're not going to buy new hardware because my browser updated, so I'm stuck having to boot up a mint 7 livecd vm to run firefox 4 every now and then. It's horrible.

Ahh I see! Sorry, I totally misread your message. Wow, that's a rough situation... If things get really bad, I think you could use a HTTPS proxy like Charles (https://www.charlesproxy.com/) to decrypt the traffic and re-encrypt it with a newer SSL cert before viewing it in Firefox. I'm not sure about Firefox, but you can run Chrome from the command line with `--allow-running-insecure-content --ignore-certificate-errors` and it'll load anything and everything. Maybe there's a similar mode for Firefox that will disable everything.

I've been working on a proxy for my retrocomputers, using it at work would be a pretty sad solutions. :( No one builds things to last more than 2 years anymore...

> I need to be able to access them to secure them

If they are using md5 ssl certs, it's unlikely securing them is possible. I wouldn't be surprised if there are a dozen or more security vulns in such outdated devices.

You secure them by firewalling them off after you change the default passwords. Old school but solid.

That's the problem of the hardware appliance, and the company who makes it has basically abandoned their customer if they have no updates that let you manage it with a modern browser. Who makes this product? They shouldn't be supported.

The trouble is, from the point of view of basically everyone producing those devices, the current "what will every browser do this week" situation is not a viable platform to support in the traditional way. They can tell you their box works with certain browsers that are available at the time you buy it, but why is -- or should -- it be their problem if they supply a working product and then someone they have no control over updates a browser they didn't know you were using and something breaks?

If admins don't like this, they need to expect to pay a huge amount of money for ongoing support contracts that actively update to support new versions of browsers, or they need to stop demanding web-based config interfaces and get used to installing native software that uses proprietary protocols that will reliably still work next week as well.

The idea that vendors of devices that often have working lifetimes of 5-10 years or more should be responsible for keeping up with every little browser update for every "evergreen" browser throughout that lifetime as part of routine support is just not commercially viable, and that's why approximately no-one offers it.

supermicro, F5, lantronix, cisco, netgear (in cisco pants), APC, and dell.

Completely agree. "You don't need to see any of this, you can't go there for your own good" is frustrating and unhelpful.

I keep FireFox portable 3.x around for sites (intranet devices) like that.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact