Software 44791 Published by

Mutt 2.4.2 shipped this morning, marking the third patch update in the 2.4.x stable line under two months. The headline change resolves a Linux kernel timing quirk where coarse time() calls and fine-grained filesystem clocks drifted apart, triggering false "attachment changed" prompts during composition. Maintainer Kevin J. McCarthy reworked the stamping function to read stat st_mtime directly, aligning both sides of the comparison while preserving a time(NULL) + 1 fallback for edge cases. The release also cleans up orphaned files on compose abort, stabilizes GPGME key selection, and includes OpenBSD and Arch build fixes, following a diagnosis that originated in Debian's bug tracker.



Mutt 2.4.2 is here, and it quietly patches a Linux kernel timing quirk that broke email composition on modern systems

Mutt 2.4.2 shipped this morning, marking the third patch release in the 2.4.x stable line under two months. Maintainer Kevin J. McCarthy says the headline change addresses a sporadic compose-menu prompt that asks users to update attachment encoding even when nothing has changed. If you have ever opened your email client on a kernel 6.x or 7.x system and been hit with that exact warning, you are not alone. The bug has been a known interaction for months, and it is finally fixed.

Text-based mail clients like Mutt have been around since 1995, back when Michael Elkins built the original to add message scoring and threading to the ELM mail client. It never picked up a web browser engine, a JavaScript interpreter, or an embedded renderer. That deliberate restraint is exactly why security teams and power users keep coming back to it. The downside is that decades-old code still has to play nice with modern kernel internals.

Screenshot_from_2025_10_02_13_00_47

How a kernel clock mismatch tricked Mutt into thinking your attachment changed

Modern Linux kernels run on a dual-timing system. Filesystem timestamps use a fine-grained clock for nanosecond precision, while the C library time() call pulls from a coarse clock optimized for low overhead. Right around the second boundary, those two clocks can drift apart by a few milliseconds. Sometimes time() actually returns a value one second earlier than the filesystem's st_mtime for a freshly written file.

Mutt's attachment stamping function was calling time(NULL) to record when a file was added to a draft. Later, just before sending, it compared that stamp against stat st_mtime. When the coarse clock lagged behind the fine one, the comparison failed. The result was a confusing popup mid-compose, telling you your attachment had changed on disk. It only happened in a narrow timing window, which is exactly why it took a while to track down.

The fix, committed on August 20, switches the stamp to read st_mtime directly. Both sides of the comparison now pull from the same clock source. An extra stat() call during composition costs nothing in real-world terms, and Mutt already runs stat() on attachments before sending anyway. If stat() fails for some reason, the code falls back to time(NULL) + 1 to keep things moving.

Community diagnosis and the rest of the change set

The bug surfaced through Debian bug tracker #1144613, where Vincent Lefèvre reported the false warning and helped map the timing mismatch. Ian Collier, Reed Underwood, and Steffen Nurpmeso spent time reproducing it on different kernels, and Oswald Buddenhagen helped refine the patch review and commit message. McCarthy implemented the final fix. It is a textbook example of how open-source debugging actually works.

The patch itself is straightforward, which is exactly the point. Mutt does not need a rewrite to play nice with modern kernels, just a single line of logic adjusted to match the timestamp source it is already comparing against. It also mirrors what happened when glibc switched to 64-bit time_t years ago. Userland code usually has to bend before the kernel changes.

Beyond the timing patch, 2.4.2 includes a handful of smaller but meaningful improvements. The <get-attachment> command now properly cleans up files in $tmpdraftdir when you abort a compose operation, which stops orphaned attachments from quietly piling up in /var/tmp. GPGME key selection during signing and encryption gets updated flags for better reliability in multi-key setups. There are also build fixes for OpenBSD and Arch on sr.ht, a minor typo correction in the UPDATING file, and some manual updates.

The release cadence reflects an unusually active hardening phase. The 2.4.x line launched in June with thread open/close commands, a configurable draft directory, Bcc search patterns, and a full codebase reformat that required external patch maintainers to update their trees. 2.4.1 followed fifteen days later with an OpenSSL 4 build fix and an IMAP overflow patch. Fifty-seven days later sits 2.4.2, and it is exactly the kind of stability update the line needed before it settles into long-term support.

Mutt 2.4.2 is available immediately from the project's FTP server and mirrors. Keep in mind that NeoMutt still maintains its own feature set, including Lua scripting support, for those who want upstream Mutt with additional patches layered on top. Head here to grab the signed source tarball and verify it against McCarthy's GnuPG key.