Betterbird Blog

If you read the article about discontinuing the Revolut payment link, you will already have heard of credit card testing attacks: Fraudsters effect (small) payments to "merchants" to test the validity of stolen/leaked credit card details. As you can see in the picture, nine attempts were made within less than 40 minutes. All Revolut did was to block our account, they don't offer any mitigation tools.

As of March 2026 our Stripe payment USD link also came under attack. It started with small payments between $0.50 and $2, which we blocked, but later they increased to $5 to $20, and even payments of $100 or $1000 were "tested".

To mitigate the issue the following measures were taken on top of Stripe's so-called Radar which has its own heuristic for fraud detection:

• Small donations blocked
• Donations from Algeria blocked, there seems to be a nest of fraudsters
• Now requiring 3D Secure payments (when available)
• Stricter address checking
• USD payment replaced twice and all payment links now obfuscated (supplied via JS on page load or user click)
• Proactive refund of suspicious payments, since every dispute carries a fee of $20
• Last not least: The Link payment method was disabled, a Stripe invention, which makes these attacks faster for the fraudsters.

Unfortunately, Stripe's own mitigation isn't very good, in on case there were at least 8 failed tests from the same IP address within 33 minutes, and Stripe still allowed a subsequent payment from that IP address, which of course we refunded immediately to avoid a costly dispute:

If your genuine donation in USD was declined, please get in touch and we'll find a different payment option. In a dialogue with a donor we found out that Bank of America generally allows outgoing ACH payments. For "regular" customers they charge a fee, it's free for customers with a "preferred status".

Strange what tasks arise in an open source project which aims at providing the world's best e-mail client.

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.

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).

Recently, it was brought to our attention by a user that the feed icon of "Charlie's Diary" (feed here) is displayed empty:

We looked into the issue and it turned out that Mozilla-base software has a problem displaying the icon, as also can be seen when opening it directly in Firefox, resulting in: "The image “http://www.antipope.org/favicon.ico” cannot be displayed because it contains errors."

However, Mozilla's "Places technology", also used in Thunderbird feeds, can display the icon:

So we contacted Charlie politely asking him to address this issue. We even supplied a repaired version of his icon, which is only 16 bytes bigger. Our first inquiry was ignored, but a friendly reminder, "Please address this issue", five days later received this reply:

No. Now fuck off.

Well, good luck, Charlie!

After a string of bad design decisions, like turning the default view to threaded and removing connecting thread lines, moving the main menu bar to underneath the unified toolbar, and the recent folder naming disaster, the new kids on the block are now moving to the implementation of a feature that allows filtering on untagged messages. This was requested in 2011.

Betterbird had an initial implementation in version 91 in 2021 with a second button, called the "two button solution": where a second button allowed selecting untagged messages additionally. This was replaced in version 115 by the ability to negate not only tags, but also the other filter buttons (unread, starred, in-address-book, etc.) as well as text filters:

Thunderbird's director bagged on this implementation, as reported in an earlier post.

Now watching the now Thunderbird kids trying to implement the feature is a real disaster. At first, the suggestion to add a third selector to Any of / All of is put forward:

When a reviewer voices objection (quote):

I don't think this is the way to implement this. "None" is totally a different thing from AND/OR, and totally mess with the mental data model of the filtering.

he is swiftly removed. The patch author, now impersonates the UX team and replies:

The UX team analyzed this and they agree that this is an acceptable first implementation to add a very simple feature..

And then a well-meaning clueless employee suggests:

But I have a second idea: A virtual "untagged" tag. This additional tag is shown alongside the others and its default state is "not", to match the current behavior when tags mode is enabled, but users can flip it to show only messages without tags.

Wow, wow, wow, such genius. Only that this very same solution was considered and rejected in 2016. And there is more brilliance:

What was that sentence? "Perfection is the enemy of good" 😄 That's a long-standing Thunderbird principle: Wait (forever) until the perfect solution comes alone.

And then, in reply to a comment, You are aware that exclusions work today via right-click and that the excluded tag(s) is/are struck out? we have:

I don't see a strike out when I use shift

Dazzling, for sure, from someone who has been on the project from 24 years.

What's up next?

In continuation of this post:

For decades, IMAP folder names were shown in Thunderbird with their name on the server, with the exception of localised versions, where standard IMAP folder names for special folders (Inbox, Sent, Drafts, Templates, Trash, Junk) were localised.

Every since the folder naming strategy has chancd in this ticket, users have been running a riot. The latest action is happening in this ticket. After Thunderbird's director lectured users why his way is the right way, and what was happening for more than two decades was wrong, users are getting increasingly frustrated. Here some quotes:

Director:

Regarding the folder names changing, that was a conscious decision and a wanted change to mitigate the problem of inconsistent naming from different servers.

Users:

Censorship already killed this comment: Like myself and my wife and my associates and we have have being doing it since email was invented. Many of us have multiple work, personal, family, etc, etc accounts and the braindead change just makes our lives a little bit more miserable. Thank-you for making decisions for us. It really helps. NOT!

When clicking that Spam folder, what I do see in the status bar is 'Opening folder Bulk'. Also, the Folder Properties for the folder now called 'Spam' show a 'Bulk' folder in the Location field. How is this consistent?

Not to mention the subscribe panel.

Sarcasm: Thanks for "mitigating" all my problems. Much improved user experience. 10/10 ⭐

I [...] hope this useless change will be reverted.

More sarcasm: what a mess! fantastic idea, really genius ...

This is an idiotic change, more dev-nanny assumptions about what users want. [...] This is not at all useful. Please fix this BACK!

Latest update: Now the proposal is to go back to the original state, see this ticket. Do they know what they're doing?

In this Bugzilla comment, Thunderbird's "Director, Desktop & Mobile Apps" Mr. Alessandro Castellani, writes (quote):

"Apologies for dropping the ball on this, we were working on a million other things 😅"

Let's see what other balls he or the project dropped in no particular order:

• Movemail support
• CardDAV categories
• Working Linux system tray support
• Complex search terms
• Compose Window background
• Thread connection lines
• Menu bar on top

just to name a few from the last few years.

He goes on to bad-mouth Betterbird features, like the advanced "Quick Filter" which allows not only to invert tags, but also other buttons (unread, starred, in-address-book, etc.) as well as text filters. He calls that (quote):

"weird hidden CTRL+click and ugly red bars UI".

Well, Alex, we will see how well your proposed solution will work when it arrives in 2037. Apparently you're dusting off the original solution from 2016, which was rejected back then. Have you realised that "weird hidden Ctrl+Click" UI is already present today when negating individual tags? And the strike-trough already exists, too.

As for his (quote): "I will also add a bunch of tests for this feature". Perfect, also, please instruct your release management to actually look at test results before shipping a release. Many time releases get shipped without analysing permanent test failures.

And what are the million things you've been working on? To the deliver the second rewrite of account creation, that was so bad that it had to be disabled in the ESR version? Or rewriting the calendar UI yet again? How about making sure that Thunderbird users will live long enough to see features that have been requested for 20+ years, some going back to the past millennium.

So funny that our project's CEO actually took part in hiring Alex for the project back in 2018.

Thunderbird Release channel version 146 brings fresh regressions directly to your desktop. Check them out, blank parts of the UI and inconsistent naming:

This bug was reported by Thunderbird's internal QA team, good on them, a volunteer developer fixed the issue, and Thunderbird's release manager refused to ship the fix in the Release version. It's a bit like in this Dilbert cartoon:

And the folder name saga continues, this was already covered here. Mileage varies depending on mail provider and localisation. Here shown for a Gmail account. On the left, the folder tree, on the right, the folder name in the Subscribe panel, which is typically the folder name shown in the provider's web UI:

Follow-up here.

Thunderbird 140.6.0 ESR is due next week, so the Thunderbird folks are building it. Surely, something went wrong again, as the picture shows. But that's not what we're there to talk about. We're here to talk about software quality.

Question: How make fixes are included in their version 140.6.0 ESR compared to the previous version 140.5.0 ESR? Answer: Zero, nothing at all. Despite 72% of users still using the ESR version as compared to 25% of users on the buggy "Release" version (source: Desktop ADI: 72% on 140esr, 25% on Release, 3% on other), the ESR version is largely neglected while they keep flogging the regression-ridden "Release" version, see here, here and here. Betterbird on the other hand is including about 80 fixes in Betterbird 140 which the Thunderbird folks could easily ship in their version, too. But they established this ridiculous "backport" policy, where only fixes for severe issues are backported, so all the annoying regressions are left unfixed, and this applies to their "Release" version, too.

First we would like to remind the reader what ranting is about. As AI put it: Online, it signals exactly what you’re doing: calling out mistakes, bad decisions, sloppy work, or irritating trends — but in a way that’s more commentary-with-attitude than theatrical shouting.

So here goes a personal story from your favourite CEO:

I had a bad Sunday. In the morning, I was writing an e-mail and was hit by three bugs.

First, searching by custom header had been messed up since the preference mailnews.customHeaders which lists custom headers had been corrupted, likely by an add-on, since the code just doesn't do that. The separator :<space> had been replaced by \n. Very weird.

Next, I noticed that in an new composition with many attachments shown on top (which is a Betterbird feature), the header pane grew with no way to reduce it. That was actually a real bug. It got fixed in our "latest build 4".

And finally, the ghost menus hit me. A user had reported them before, but only today I found a reproducible case. After a long investigation it turned out that setting preference ui.prefersReducedMotion to the default value 0 caused this issue. Betterbird exposes the preference, hence it leads to this error. Thunderbird 140 fails the same way if one sets the preference manually. The issue seems to be fixed in later versions of Thunderbird. We haven't bisected where it got fixed.

And to add insult to injury, I noticed that Thunderbird 146 makes irreversible changes to a profile, so while switching versions, at some stage I was prompted to enter all the passwords again. That's where a backup came in handy.

But hey, there was a silver lining: A user wrote: YOU ARE MY HERO!!!!! after helping him diagnose that his mail provider was rejecting his SMTP EHLO command based on his local IP address of 192.168.1.13. BTW, AI predicted something like that based on the obscure error received: internal error AUP#EML-005. So if your mail provider plays up, you can set preference mail.smtpserver.smtpXX.hello_argument to work around it. The XX can be obtained from the account listing in the Troubleshooting Information (that's a Betterbird-only feature).

Oh yeah, SuperSandro from NixOS helped us with improving our build script by replacing uname -i with uname -m. Two workarounds for uname -i not working on Debian and macOS were made obsolete.

How was your Sunday?