Andreas Gohr: Weblog [splitbrain.org]

Auto-Delete old Mails from GMail

andi@undisclosed.example.com (andi) — Sun, 08 Mar 2026 12:50:07 +0000

Auto-Delete old Mails from GMail

My inbox is a mess. While I manage to maintain a somewhat close to “Inbox Zero” at work, my personal GMail's inbox currently sits at 2,215 emails . A large amount of those mails are notifications of some kind, like from Github for example.

GMail has some mechanisms to automatically sort mails and I do make use of that, but those filters are applied when the mail arrives only.

For notifications I want to see the mail. So it should land in my inbox. But when I have ignored it for a certain time, it's pretty sure I don't need it anymore. So I wanted a way to automatically delete certain mail threads that are older than a specified number of days.

So here is what I came up with using Google Apps Script.

/**
 * Main script to schedule
 *
 * Add one cleanEmails line per type of threads to clean
 */
function main() {
  cleanEmails(true, '<notifications@github.com>', 7);
}
 
 
/**
 * Find old thread based on given conditions
 * 
 * @param {bool} clean Set to false to not actually delete the mails
 * @param {string} searchString The string to search for
 * @param {int} minAgeDays The minimum age a thread (newest message) has to have
 * @param 
 */
function cleanEmails(clean, searchString, minAgeDays, headerField = 'from') {
 
  const threads = findRecentEmails(searchString, minAgeDays, headerField);
  console.log(`Found ${threads.length} threads`);
 
  threads.forEach((thread, i) => {
    logThread(thread);
    if(clean) {
      thread.moveToTrash();
      console.log('moved to Trash');
    }
  });
}
 
/**
 * Log a thread to console
 * 
 * @param {Thread} The gmail thread to log
 */
function logThread(thread) {
  const firstMsg = thread.getMessages()[0]; // newest message in thread
  const lastMsgDate = thread.getLastMessageDate();
  const dateStr = Utilities.formatDate(
    lastMsgDate,
    Session.getScriptTimeZone(),
    'yyyy-MM-dd HH:mm'
  );
 
  console.log(`Date: ${dateStr}, From: ${firstMsg.getFrom()}, Subject: ${thread.getFirstMessageSubject()}`);
}
 
/**
 * Find old thread based on given conditions
 * 
 * @param {string} searchString The string to search for
 * @param {int} minAgeDays The minimum age a thread (newest message) has to have
 * @param 
 */
function findRecentEmails(searchString, minAgeDays, headerField = 'from') {
  // Compute the cutoff date (messages must be older than this)
  const cutoffDate = new Date(Date.now() - minAgeDays * 24 * 60 * 60 * 1000);
  const cutoffFormatted = Utilities.formatDate(
    cutoffDate,
    Session.getScriptTimeZone(),
    'yyyy/MM/dd'
  );
 
  // Build Gmail search query:
  //   - headerField:searchString  → search in that header
  //   - before:YYYY/MM/DD         → older than cutoff
  //   - -is:starred               → skip starred
  const query = `${headerField}:${searchString} before:${cutoffFormatted} -is:starred`;
  console.log(`Query: ${query}`);
 
  // get the 50 newest threads with their newest message older than the cut-off date
  return GmailApp.search(query, 0, 75)
          .filter(thread => thread.getLastMessageDate() < cutoffDate)
          .sort((a, b) => b.getLastMessageDate() - a.getLastMessageDate())
          .slice(0, 50);
}

The script is scheduled to run main() every hour. For now it only handles my Github notification mails, but more will follow. The cleanEmails() function takes four parameters:

clean: set it to false if you the method to run but not delete anything. The found threads will be printed to the console.
searchString: this is what identifies the threads to delete, for example the sender's email address
minAgeDays: defines how old the youngest message in the thread has to be to be considered for deletion
headerField: defaults to from but you sometimes might want to search the subject instead.

Each call to cleanEmails() will delete the newest 50 threads matching your criteria. And by delete I mean move them to the “Trash” folder – GMail will delete them automatically after 30 days. This adds a bit of safety if something goes wrong.

With the script running every hour it will take a while until all my old Github notifications are gone, but that's fine. I heard that GMail can become sluggish when deleting too many mails at once.

Tags:: appscript, gmail, automation, javascript

Similar posts:

Add or read comments to this article »»

Copyright © 2026 Andreas Gohr
This feed is for personal, non commercial use in the subscriber's feedreader only.
All contents (especially texts and images) are protected by copyright law and may not be republished outside of splitbrain.org without prior consent. Texts may be quoted in extracts under fair use policy. [digital fingerprint: sb97741286f601b4a0d496dc8bae242e6d]

Old Game, New Clothes

andi@undisclosed.example.com (andi) — Mon, 02 Mar 2026 17:13:31 +0000

Old Game, New Clothes

Back in university in 2003 we had to do a group project. I don't remember which course it was, but the assignment was pretty open. Basically as long as you coded something, you passed.

I had just switched from my trusty Palm Tungsten E2 PDA to a Linux based Sharp Zaurus and I was missing a little puzzle game I enjoyed playing on the Palm. So my friend Frank and I decided to implement our own version.

The Zaurus used QT as the graphics framework so we made it in C++ and QT. It was a fun project and it not only worked on the Zaurus but also on desktop. Frank even managed to compile it for Windows.

The time of PDAs was soon over and the age of the smartphone had begun. From time to time I thought about creating an Android app of that game. Unfortunately I had lost the original source code, so I asked Frank if he still had it and luckily he found it on an old disk.

Good thing he sent the code to my gmail account where it got archived forever. Because that was back in 2011 and I never came around to actually make that app.

But recently I remembered. And since we're living in the future (a much shittier version of the future than I had hoped, but the future nonetheless) porting code is relatively simple now.

So I spent an afternoon with Claude Code, having it analyze the original code, come up with some initial requirements and a final implementation plan. Then I let it run and it basically one-shot a working implementation .

There are many valid criticisms on LLMs and their billionaire owners. But that LLMs don't work isn't one of them…

I iterated a bit on the implementation and now have a modern version of the old game and it even includes a network mode.

The game uses modern ES6 JavaScript modules and web components, the networking is based on WebRTC (using PeerJS), it has an automatic dark mode, you can install it as an offline app thanks to PWA technology and does not even need a build system. Another tiny part of the future that doesn't suck.

If you want to give it a try, here you go: ZigNum. I find the computer quite difficult to beat – despite the rather naive “AI” approach we picked back in 2003. But maybe I'm just rusty.

Tags:: game, llm, ai, zignum, js, pwa

Similar posts:

Add or read comments to this article »»

LAN Overview 2026

andi@undisclosed.example.com (andi) — Sat, 07 Feb 2026 18:02:14 +0000

LAN Overview 2026

The last time that I blogged about my personal LAN setup was more than a decade ago. Meanwhile we moved into our own house and one of the major things we did, was adding Ethernet to every room.

So let's have a look at the current state:

This only shows the devices connected by Ethernet in detail. I added a few placeholders for the various devices connected by WiFi. Zigbee and Bluetooth devices are also omitted. I probably forgot something, too.

I am connected to the Internet via a 1GBit/s (TV) cable connection. It's great when it works, but unfortunately the service isn't the most reliable. To get Vodafone support help me faster, I opted to connect their shitty modem instead of my own Fritzbox to the line. This way they can run their access tests and don't have me unplug (and thus mutilate my network) everytime I have them on the phone. The modem runs as a simple forwarder.

I am still using a Fritzbox to run DNS and DHCP but often think about replacing it with a less consumery device where I have more control. But so far I have been too lazy. I also like their mesh network mechanism for the repeaters.

Everything else is pretty straight forward. I haven't dropped PowerLan completely - it's more reliable for extending the network out to the shed than WiFi.

The diagram was created using FossFLOW and I vibecoded a little tool to create the icons I was missing using the gpt-image-1 API.

For my own reference in the future, here's the FossFLOW file: network.json

Tags:: network, lan, house, infrastructure, powerlan, router

Similar posts:

Add or read comments to this article »»

Appy - An AppImage Installer

andi@undisclosed.example.com (andi) — Tue, 20 Jan 2026 21:14:46 +0000

Appy - An AppImage Installer

I nerd-sniped myself today. All I wanted to do was installing SuperSonic, a subsonic compatible music player written in go. One of their recommended ways to run it is an AppImage.

An AppImage is basically an ELF executable which contains a SquashFS with the application and all dependencies it needs. It's a simple way to distribute a Linux binary.

Running an AppImage is super simple. You download it, you make it executable you start it.

But for graphical tools, you probably want it integrated into your system's menu with a nice icon. For that you need to copy the AppImage to a more permanent location than your download folder, create a .desktop file in .local/share/applications and also place an icon in .local/share/icons. Now you need to remember the .desktop specification and also need to find a proper icon for your app. All not very difficult but tedious.

So I looked into available AppImage “installers” that would automate this process. I wasn't happy with what I found. It all seemed more complicated than what I wanted.

So I spent a few hours co-working with Claude to come up with my own solution called “Appy”. It's a single go binary which can install and register itself as default handler for .AppImage files.

Once installed, you can download the AppImage, double click it in your file manager and get a single button to “install” it.

You click the button, the AppImage is copied to ~/Applications, chmod'ed and the icon and desktop file are extracted from the AppImage itself and installed at the right places. And when you later want to “uninstall” the app again, you right click it in your ~/Applications folder, select “Open with… Appy” and you can uninstall it with another click of a button.

You can find Appy at Github.

Tags:: golang, appimage, linux, installer

Similar posts:

Add or read comments to this article »»

Gmail Backup and notmuch GUI

andi@undisclosed.example.com (andi) — Fri, 09 Jan 2026 17:10:31 +0000

Gmail Backup and notmuch GUI

I am still working adding services to my NAS and one thing that was on my todo list for a while was a proper GMail backup.

You never know when the powers that be deny you access to your mails for some obscure reasons. One guard is using my own domain. When I a can't use GMail anymore, I can just use my own mail server or a different provider. But it would suck losing all my old mail.

Backup

I don't necessarily need a running IMAP server to access the backup. But the backup should be in a format that allows my to point an IMAP server to the backup and be ready to go. That means I want the mails in a Maildir directory.

For the backup I am using GMail's IMAP server. To fetch your mails by IMAP you need to enable IMAP, have 2fa enabled (as you should in general) and create an app password. You also want to hide some of the default tags from IMAP. Basically only the INBOX, your sent mail and all your custom tags should be exposed. This avoids downloading a bunch of duplicates.

To do the actual syncing, I decided to use the mbsync command from the isync package. More specifically I am using the theohbrothers/docker-isync Docker image.

The image will run one sync, then exit. I added a sleep after execution and then let Docker's restart policy taking care of running the next sync.

compose.yml

services:
  mbsync:
    image: theohbrothers/docker-isync:latest
    container_name: mbsync
    restart: unless-stopped
    user: "1000:100"
    environment:
      GMAIL_USER: ${GMAIL_USER}
      GMAIL_PASS: ${GMAIL_PASS}
    volumes:
      - ./volumes/vmail:/mail
      - ./config/mbsyncrc:/mbsyncrc:ro
    command: <
      sh -c 'while true; do
               echo "[$(date)] Running sync...";
               /sync;
               echo "[$(date)] Sync finished. Sleeping...";
               sleep 1800;
             done'

The configuration for the synchronization is relatively straight if forward. I added a bunch of comments for your and my understanding:

config/mbsyncrc

### Remote Config ###
IMAPStore gmail-remote
Host imap.gmail.com
Port 993
UserCmd "echo $GMAIL_USER"   # from environment
PassCmd "echo $GMAIL_PASS"   # from environment
AuthMechs LOGIN
TLSType IMAPS
PipelineDepth 1              # Avoid quota errors
Timeout 60                   # More graceful timeouts

### Local Config ###
MaildirStore gmail-local
Path /mail/
Inbox /mail/INBOX
SubFolders Verbatim

### Sync Settings ###
Channel gmail
Far :gmail-remote:
Near :gmail-local:
Patterns *
SyncState *
CopyArrivalDate yes          # Don't mess up message timestamps when moving them between folders.
Sync Pull                    # Download changes only, don't sync local changes up to the server.
Create Near                  # Automatically create new folders in the local copy.
Remove Near                  # Automatically remove deleted folders from the local copy.
Expunge Near                 # Expunge deleted messages from the local copy.

With the appropriate user and app password in a .env file, this will create your backup (the first run can take a loooong time).

Introducing notmore.

Next I wanted a way to look at my backup. Of course I could set up an IMAP server and point a mail client to it, but that seems relatively involved. What I wanted was a quick way to search through the Maildir.

A quick web search revealed notmuch - a xapian based mail search engine (and more that I am not using). It is super fast and simple to use. But it's CLI only. I wanted something with a web interface.

The general recommendation is netviel. A python/JavaScript interface to notmuch. Unfortunately it seems to be mostly abandoned with the last release 3 years ago and I had a really hard time getting it to work on modern Python versions within a Docker container.

So instead I decided to roll my own. I vibe engineered a PHP based search interface that wraps around the notmuch command line interface. It let's you search using notmuch's comprehensive syntax, displays the result threads and allows you to drill down into the individual mails. Attachments can also be downloaded through the interface. Simple, not more.

The tool is aptly named “notmore” and available on Github.

The repo also builds a ready to use Docker image. You can just point it at the Maildir created by the sync job above.

My full docker compose setup can be found in my github repository for the NAS docker setup.

Tags:: gmail, backup, mail, programming

Similar posts:

Add or read comments to this article »»

Password Hasher PWA

andi@undisclosed.example.com (andi) — Fri, 02 Jan 2026 19:22:47 +0000

Password Hasher PWA

Nearly two decades ago I wrote about a mechanism to have different passwords for every web site, without a central password manager storing your passwords. All you needed is an algorithm and a master password.

I am still using the mechanism¹⁾. But the original Firefox extension is abandoned, the Chrome extension that replaced it no longer works with recent Chrome changes and the Android App I was using is no longer working either.

I felt unwell today and spent the day in bed. Time enough to get coding (or rather vibe engineering). Based on the original algorithm, I built a PWA (Progressive Web App), of course updated to modern JavaScript (using the SubtleCrypto API, a web component, the clipboard API, modern nested CSS, etc.) - not even a build system was needed for this.

The app can be installed on Android and will show up in the share menu. When I need a password, I can simply share the current URL with the app and it will prefill the site tag. I enter the master pass, press enter and the password is in my clipboard, ready to use. On desktop I can use a simple bookmarklet that does the same.

This makes the system independent from any mobile apps or browser extensions. Good for another 20 years