Store lists in imap

[larsks]

I often switch between a desktop and laptop. I would like changes made to screening lists, etc, to be shared between both devices. It would be great if neomd would offer the option of storing the lists in imap instead of on the local filesystem. We're already using what is effectively a remote file sharing service; let's take advantage of it 😄 .

My recollection is that Alpine does something like this.

[notthatjesus]

Hi @larsks. I do this already using GNU stow and a github repo with my dotfiles. I kinda like it more that way because I don't rely on each specific app to have a sync option but rather a VCS of my choice to keep version control.

[larsks]

I think there is a large difference between the two workflows. With the lists stored in imap, the workflow is:

1. Press "I" or "O".

Using git, the workflow is:

1. Press "I" or "O".
2. After you finish reading email, don't forget to commit your changes.
3. And also don't forget to push your changes.
4. On another device, don't forget to pull your changes (and hope you don't have pending changes there you forgot to commit and push previously).

Using something like syncthing would probably be a more intuitive solution, but it still feels like for a tool designed explicitly to work with imap that taking advantage of imap for the purposes of shared configuration would be an obvious mechanism.

[notthatjesus]

Thanks for the explanation! I think it makes sense. I may give it a try over the weekend :) Jesus Rodriguez @: ***@***.***

…

________________________________ From: Lars Kellogg-Stedman ***@***.***> Sent: Friday, May 15, 2026 1:47:21 PM To: ssp-data/neomd ***@***.***> Cc: Jesús Rodríguez ***@***.***>; Comment ***@***.***> Subject: Re: [ssp-data/neomd] Store lists in imap (Issue #18) [https://avatars.githubusercontent.com/u/82622?s=20&v=4]larsks left a comment (ssp-data/neomd#18)<#18 (comment)> I think there is a large difference between the two workflows. With the lists stored in imap, the workflow is: 1. Press "I" or "O". Using git, the workflow is: 1. Press "I" or "O". 2. After you finish reading email, don't forget to commit your changes. 3. And also don't forget to push your changes. 4. On another device, don't forget to pull your changes (and hope you don't have pending changes there you forgot to commit and push previously). Using something like syncthing<https://syncthing.net/> would probably be a more intuitive solution, but it still feels like for a tool designed explicitly to work with imap that taking advantage of imap for the purposes of shared configuration would be an obvious mechanism. — Reply to this email directly, view it on GitHub<#18 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWNFUPV4CS7GDIXYLQMD7FD4237UTAVCNFSM6AAAAACY6WBM56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINJZGQ3TEMZTG4>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[sspaeti]

Thanks @larsks for the input, I didn't know you could write arbitrary data to an IMAP server. I need to check that out.

But what is already implemented are two things:

1. I use Syncthing to sync these minimal lists across my devices and I run a headless version on my NAS (see point 2 below). The setup with Syncthing that worked for me: https://neomd.ssp.sh/docs/configuration/headless/#syncthing-setup
2. a --headless version of neomd, that runs on any machine (i put it on my NAS) and syncs and runs the screeners every 2-5 minutes, screening out unwanted emails also on mobile for example. More details at https://neomd.ssp.sh/docs/configuration/headless/

But if there's a write-back to IMAP, that would be more elegant, agreed. But can you give me a hint, where or how to write lists to IMAP? A quick AI search gave me this:

This is exactly what Alpine does with its "remote configuration" feature — remote-config = {imap.example.com}Mail/.pinerc stores the pinerc as a message in a folder. Mutt/NeoMutt users have done similar things manually for years. mu4e, notmuch, and others have also leaned on this pattern.

The "proper" approach: IMAP METADATA (RFC 5464). This extension exists specifically for storing arbitrary annotations on mailboxes or on the server itself, keyed by a path-like name (e.g. /private/vendor/neomutt/screening-list). SETMETADATA / GETMETADATA commands. It's clean and semantically correct. The catch: server support is uneven. Dovecot supports it, Cyrus supports it, but Gmail famously does not, and various smaller/hosted providers don't either. So if you ship a feature relying on METADATA, you'll get bug reports from Gmail users immediately.

Is that what you meant? If so I'll check this out more - I didn't know about Alpine, the manual contains some interesting insights to test. Also i need to see if it's made for the actualy list that change often.

I can't promise anything, as the current list works really nicely, plus I like them also to have offline, to quickly remove or search, or manaully add domains, etc. I

[larsks]

I was assuming this sort of implementation:

This is exactly what Alpine does with its "remote configuration" feature — remote-config = {imap.example.com}Mail/.pinerc stores the pinerc as a message in a folder. Mutt/NeoMutt users have done similar things manually for years. mu4e, notmuch, and others have also leaned on this pattern.

You have something like a neomd folder, and inside that you have messages where the subject: header is the list name, and the message content is just the content of the list. To make an update, you would probably delete the existing message and store a new one.

From an implementation perspective, maybe you have some sort of storage interface with two implementations, one for local files and one for imap folders, and hide all the details inside the interface (and with this sort of model, if someone showed up wanting to add something like s3 storage for lists, there would be a relative straightforward path for doing so).

I can't promise anything, as the current list works really nicely, plus I like them also to have offline, to quickly remove or search, or manaully add domains, etc.

To be clear, I am suggesting this as an optional feature. There are valid reasons to keep things offline.