Apparently our July has been so busy that we didn’t find the time to write up the progress report for June. But a late report is better than no report 😄

If you need a refresher on what happened the previous month, read the May 2023 Progress Report.

Improved account setup

The roadmap item we’re currently working on is Improve Account Setup. Most of our time went into working on this. However, for June there’s no exciting news to share. We mostly worked on the internal plumbing; that is important to get right, but not necessarily great material for a blog post. Hopefully there will be new screenshots to share in July’s progress report.

App maintenance

Having an app with a large user base means we can’t spend all of our time working on new features. Fixing bugs is a large and important part of the job. Here’s a writeup of just three of the bugs we fixed in June.

Folder appears to be empty

A user reported that some of their folders appear to be empty in K-9 Mail. Using the provided debug log (❤️) we were able to track this down to a message containing an invalid email address, specifically one whose local part (the text before the @ symbol) exceeds the limit of 64 characters.

The error was thrown by a newly added email address parser that is stricter than what we used before. At first it was a bit surprising that this would lead to messages in a folder not being shown. We deliberately kept this new implementation out of the code responsible for parsing emails after download and the code for displaying messages.

However, it turned out the new email address parser was used when getting the contact name belonging to an email address. This lookup is performed when loading the message list of a folder from the local database. When an error occurs during this step, an empty message list is shown to the user.

To fix this bug and limit the impact of similar problems in the future, we made the following changes:

  • Ignore most errors when parsing email addresses from messages that the user has received. The world is full of email addresses that violate the specification but work mostly fine in practice. However, we still want to be strict when it comes to the email addresses we accept, e.g. when setting up a new account.
  • Ignore errors with the email address when trying to fetch the system contact belonging to that email address. This may lead to the app not being able to fetch a contact name for an spec-violating email address. But this will no longer lead to failing to load the entire message list.
  • We added a message with an email address whose local part exceeds the length limit to our test account. That way we are likely to catch bugs related to such email addresses before they make it into a beta release.

We’re very grateful to our beta testers for finding and reporting bugs like this one. That way we can fix them before they make it into a stable release.

Adding an email address to an existing contact

With the introduction of the message details screen we added a button to add a message sender or recipient to the contacts database using an installed contact app. If the email address can already be found in the contacts database, this button is hidden and tapping the participant name, email address, or contact picture opens the contacts app.

Screenshot of message details screen

Previously the app didn’t make that distinction and tapping an email address or participant name would open the contacts app using the “show or create” action. Apparently this reliably allowed to add an email address to an existing contact. However, the “insert” action used by the details screen only allows adding the email address to an existing contact with some contacts apps, but not others 😞

Screenshot of Google contacts app with "insert" action Screenshot of AOSP contacts app with "insert" action

We changed the action to start the contacts app from “insert” to “insert or edit”, and this seems to reliably offer the option to add the email address to an existing contact.

Screenshot of Google contacts app with "insert or edit" action Screenshot of AOSP contacts app with "insert or edit" action

Reply behavior depends on message size

A user reported that the behavior when replying to a message retrieved via a mailing list was different depending on whether the message had been downloaded completely or only partially.

K-9 Mail supports only downloading parts of a message when the email exceeds a configured size. In that case also only selected parts of the message header are downloaded. Unfortunately, we forgot to include the List-Post header field that is used to determine the email address to which to reply.

The fix was simply adding List-Post to the list of header fields to fetch from the IMAP server.

Community contributions

In June we merged the following pull requests by external contributors:


In June 2023 we published the following beta versions:

If you want to help shape future versions of the app, become a beta tester and provide feedback on new features while they are still in development.

This progress report was also published in the Thunderbird blog.