Betterbird Blog

We've shipped Betterbird 140.8.0esr-bb19 today. Please refer to the Release Notes for full details.

This new release offers four new functions and a fix for an annoying issue. Here are some details:

The add-on Send Later to schedule sending of messages has many users. Its author doesn't test his add-on in Betterbird, instead he publishes this disclaimer (quote):

Send Later is known to have issues with Betterbird
The Send Later add-on is not regularly tested with the Thunderbird fork called Betterbird, and there are known, unresolved issues which may prevent the add-on from functioning as intended. Using Send Later with Betterbird is therefore not recommended.

We're not aware of any issues, other than the ~55 issues the add-on has anyway. But the good news is, delayed sending in the background is now supported in Betterbird, if you set the following two preferences:

mailnews.sendInBackground set to true and mailnews.sendInBackground.DelayMinutes set to the desired delay in minutes. Be aware that if you close Betterbird before all messages are sent, there is currently no warning.

This is not aimed at replacing the add-on completely, it's aimed at providing a "send delay" that users of MS Outlook are used to.

As we detailed in previous posts like this one, we're now signing our Windows binaries with a code-signing certificate from a reputable source.

By popular demand, the 'Search PreferredSearchEngine for "..." ' option is now also available in the context menu in the compose window.

People who have used Thunderbird for a long time will know that for IMAP accounts, messages read on the server with a different client, like a mobile device, were not subjected to message filtering. That was later changed by introducing preference mail.imap.filter_on_new. However, the filter didn't work when it was run after the junk classification. This has now been fixed.

Thunderbird released version 140.7.2 yesterday to follow Firefox 140.7.1 which fixes a security issue, a heap buffer overflow in libvpx. That's a video codec. The Thunderbird folks wrote this in their advisory:

In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts.

So, only Betterbird users who use Betterbird as a web browser, or browsing news feeds with embedded videos may be affected. Since the security risk is extremely low and since Betterbird 140.8.0esr-bb19 will ship before the 24th of February 2026, we decided to skip this release.

The "colourful" picture shows the all the test failures that occurred in Thunderbird's release automation and are shown in the so-called "treeherder" (dashboard). Each orange box is a test failure, and it's not advisable to ship the product with so many test failures without investigating them.

In other words: Even if we had built Betterbird based on this Thunberbird release, it could be quite broken. BTW, this is not the first release chagrin, refer to these earlier articles [1] and [2] for more.

Update: Apologies to the Thunderbird folks for the incorrect statement above. We heard that the test failures were analysed and that they came to the conclusion that despite what was displayed on the dashboard, the product showed no functional failures and was safe to ship. That was confirmed by their QA team, in fact, we also tested that Thunderbird release and didn't see failures.

Our article was overreacting to the fact that in the past, test failures were ignored and the product did get shipped with minor functional issues.

Finally no encoding issues with the re-issued certificate. See our previous post for details.

Three days ago we noticed a number of 1 € payments via our Revolut payment link using a credit card. We were wondering what this was about.

Today we received this message from Revolut: It is with regret that we must inform you of our decision to discontinue the support for your freelance activity. [...] in an effort to mitigate potential risks associated with providing you with our acquiring services, we have temporarily restricted fund withdrawals from your account for the next 90 days.

Wow! AI sprang to help to explain that our payment link had become the targe of a so-called credit card testing attack, where the link was used by fraudsters to test stolen credit cards. AI went on to say:

What Stripe actually does (and Revolut doesn’t)

• aggressively rate-limits payment attempts
• runs real-time card testing detection
• blocks suspicious patterns before they hit the merchant
• absorbs the fraud risk by default
• does not punish merchants for being targeted

That’s why Stripe payment links are safe to publish publicly.

What Revolut does instead

• exposes a public card entry page
• performs basic checks
• then pushes all residual risk downstream to the merchant
• treats anomalous traffic as merchant risk

So yes — they look the same on the surface, but they are not in the same category operationally. This is not something a normal user can or should infer.

Update: Revolut chat isn't very helpful, mostly pre-canned and/or AI replies. They say that blocking the account is based on their Payment Processing Service Agreement which also includes these Business Terms, but none of the documents specify a block for 90 days. Neither do any of the ten reasons for suspension in section 7 apply.

So this looks like a Goodbye to Revolut. Adding to this is the poor quality of the data they provide: For some donors, name and e-mail address are supplied, for others, only the e-mail, and for quite a few, only the name, so we can never contact the donors to thank them. Furthermore, there is zero reporting, we have to "scrape" the textual data off the Android screen (using this Copy app).

As outlined in our previous post, a self-signed certificate cannot be used to build Windows SmartScreen reputation. So we obtained a code-signing certificate from Certum, a recognised provider.

We re-issued Betterbird 140.7.1-bb18 signed with the certificate, but as you can see, even in the 3rd millennium, processing of non-ASCII data is still not working everywhere. The umlaut in our CEO's name "Jörg" is shown as replacement character �. However, if a system locale with UTF-8 support is selected

the SmartScreen displays the correct information:

We'll take the issue up with the certificate provider.

Update: Looks like Certificate Authorities are a pretty bureaucratic bunch. We had to revoke the certificate and go through the entire process again. As a result with ended up with a certificate without umlaut and encoding issue.