#mbsync

chfkch :nixos: :rust:chfkch@ruhr.social
2026-01-16

Usually i am pretty amazed how much time i save while configuring my systems with NixOS/HomeManager. But this time i am trying to set up mbsync/mu/mu4e stack and i think some options are scattered all over.

I got a basic setup running now, but where do i put for example the inbox path if it differs from defaults?

#NixOS #HomeManager #Emacs #mu4e #MBSync

2025-11-21

OK, I'm going to give it another try to make , , , work for taming email. I'm looking (sternly 😡 ) at you, gmail forced down my throat by my <insert-employer-entity-here>...

My ideal setup would likely be simple: edit messages from emacs, store messages locally, fuzzy search available, viewing email threads, and completion for filling *to* and *from* fields.

How hard could it be? -- Wish me luck.

2025-09-22

from ‘A couple of Mu4e improvements’ | Baty.net

Another snag I’ve run into while using Mu4e was that sometimes I also use Apple’s Mail on macOS and iOS and any messages I delete there would only be flagged as “trashed” in Mu4e, so they would show up in the inbox, cluttering things considerably. The fix for this was to set Expunge Both in my .mbsyncrc file. Also much better! That one has been bugging me for a long time.

Source: A couple of Mu4e improvements | Baty.net

2025-09-20

Me and my new #yubikey5 part 2:

Now we get to the nitty-gritty parts. I'm using #mbsync to sync multiple #imap accounts to local #maildir and I am automating this via #systemd : a timer calls a service very 5 minutes, that will call mbsync on all mail accounts if connected to the internet.

Providing the passwords via #pass that is encrypted with #yubikey will need that yubikey to be unlocked (i.e. a pin needs to be provided). When providing this pin (e.g. by manually calling mbsync on one of my mail accounts), it will be stored for at least 12h, and up to 24h (on my home pc; mobile and remote devices will of course hav different settings).

However, if I never manually provide the PIN, the systemd automated scripts will fail. E.g. I just connected the key, but not used it.

First I thought, this was due to me using the `curses` version #pinentry . But that's not the whole truth. Even with `pinentry-gtk` the systemd script will not trigger a PIN entry. I didn't quite understand why, and therefore ran a different direction:

Could I just auto-unlock the yubikey if I connected it? I wrote a #udev rule that would recognize the yubikey. Learning that I need to put scripts for udev in certain dirs, and being unhappy with it, I then wrote a systemd service for the udev to call instead, and with that I maanged to finally get a PIN entry request using the gtk version.

And then it got me thinking. Why did that work, but my mailsync that basically has the same things involved (script instead of udev that triggers systemd that wants to decrypt something using yubikey triggering PIN entry). And then it hit me: My mailsync systemd service was missing the `DISPLAY=:0` environment variable, thus the script can't trigger the GUI. Half a days worth of work, all for nothing :picardfacepalm:

But hey, the weekend is young. Next up: If triggered via CLI i want gpg to trigger `pinentry-curses` instead of `pinentry-gtk`. Sounds easy: have a `pinentry-auto` script figuring out where it has been called from. Well... not really #wip

Screenshot of a terminal in background showing a manual triggering of mbsync with one of my mail addresses, and a GTK window in foreground (pinentry-gtk) prompting me to insert the PIN to unlock my Yubikey to decript the passwords provided by the GPG encrypted password store from pass.Full-screen terminal window showing the output from `journalctl -n0 -f` when I plug in the youbikey and wait while for the automatic mailsync service to trigger.

The output shows that while the Yubikey is inserted and properly recognized, when mbsyncer starts it asks for the PIN, but directly gets a `PIN callback returned error: IPC call has been cancelled` message, which in turn makes the decription fail, which leads to a skipping of the account in mbsync. And this will continue for the next 7 mailboxes I own...Termial showing the bat output from the udev rule I wrote:

`ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1050", ATTR{idProduct}=="0407", TAG+="systemd", ENV{SYSTEMD_USER_WANTS}="yubikey-unlock.service"`

This file lives under: `/etc/udev/rules.d/99-yubikey-unlock.rules`Console with vim showing the content of the new `systemd` service I wrote, which lives in my home dir under: `.config/systemd/user/yubikey-unlock.service`

Content:

```
[Unit]
Description=Yubikey GPG Unlock
After=graphical-session.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'TEMP_FILE=$(/usr/bin/mktemp); echo "unlock test" | /usr/bin/gpg --encrypt -r FEE1636BFD47D3E8 > "$TEMP_FILE"; /usr/bin/gpg --quiet --decrypt "$TEMP_FILE" >/dev/null 2>&1; /usr/bin/rm "$TEMP_FILE"'
Environment="DISPLAY=:0"
```

Last line was missing in my mailsync service, which is why the PIN entry did not trigger for fetching mails... you'll never stop learning :D
2025-08-30

Migrate #EMail from server A, to server B.
- #Thunderbird and drag them.
- #isync #mbsync, and read docs
- #imapsync, setup an Arch VM, because it's packaged there (as opposed to Debian/Ubuntu).

2025-06-13

New post on how to filter out email using GNU Mailutils sieve command. It's great for organising email so that you can focus on the important ones!

Sieve's actually a standard. I thought you had to run a full Dovecot IMAP server to use it - overkill for filtering email! Turns out that Mailutils has a command line Sieve that can run after mbsync!

futurile.net/2025/06/07/neomut

Also, a detailed page on Sieve:

futurile.net/resources/mailuti

@riff Le pire, c'est que je fetche déjà automatiquement les mails de toutes mois plusieurs fois par jours avec #mbsync, à des fins de sauvegarde.

Mais c'est que le quart du boulot, quoi.

2025-04-13

I wrote a new blog post about how to setup #neomutt #email with Office 365, using #mbsync #msmtp and #notmuch, along with how to make it work with multiple accounts:

cosroe.com/2025/04/neomutt-not

A small white on black caricature of a dog house, with a book and postal bag in front. A leash is seen leading out of the entrance, with the empty collar on the floor. Some paw tracks of a small dog can be seen suggesting the dog has left the house.
2025-02-11

@florine I just created a free trial account, and don't have much to add apart from that receiving mail works just fine, and I was able to get IMAP access to it setup and working with #mbsync and #notmuch without any trouble at all. As others have said, can't test sending mail from it as trial only allows you to send to mailbox.org accounts. I doubt that'll be an issue though.

Will explore Android clients tomorrow...

#degoogle

Yann Büchau :nixos:nobodyinperson@fosstodon.org
2025-01-12

For quite some time I have sporadically run #mbsync configured to pull several IMAP accounts and it indeed brings in emails. BUT:

- #maildir format is weird. What's with the cur/new/tmp structure?
- why the heck is the hostname in the filenames?
- Feels like it doesn't like to be migrated and be continued from somewhere else.
- two-way sync seems to be kinda broken (not needed anyway)
- Holy cow is the configuration unnecessarily verbose and complicated 🤯 (should be well #nix-able though)

2024-11-07
mbsync works perfectly now in #edora 41 fresh install (tested with asahi linux). gr8

#fedora #asahi #mbsync

@parleur c'est quoi #mbsync ?

Bon, et c'est parti pour une reconfiguration de #mbsync pour une bonne douzaine de boîtes mail, parce-que c'est quand-même top au moins pour l'archivage.

2024-08-05

I started my own fork of #isync (or #mbsync)

https://codeberg.org/jarkko/isync

It has now couple of commits:

❯ git log --oneline -2
8ea62c9 (HEAD -> main, origin/main) fix: compile with -fno-lto
f5782aa refactor: open code FORCEASYNC far and near parameters

The first is the fix for crash in #Fedora. The second open codes FORCEASYNC:

diff --git a/src/common.h b/src/common.h
index 940e74d..22bd827 100644
--- a/src/common.hb
+++ b/src/common.h
@@ -120,7 +120,8 @@ BIT_ENUM(
        ZERODELAY,
        KEEPJOURNAL,
        FORCEJOURNAL,
-       FORCEASYNC(2),
+       FORCEASYNC_F,
+       FORCEASYNC_N,
        FAKEEXPUNGE,
        FAKEDUMBSTORE,
 )

I plan to do this for all of those, as it allows to cut some slack out from bit_enum_get.pl. That will lead to a roadmap where eventually the whole ugly script can be rendered out replaced with BIT_UL macro from kernel (msync is GPL 2.0 licensed).

There is also a #zig branch but before build can be defined properly the C codebase first needs to be made sound in terms of the build. Then it is relatively easy task to repeal and replace main.c with main.zig.

#email

2024-08-01

Here’s my #mbsync #GCC workaround for #Fedora:

commit ebf6bcea7ebdba15553692777d292e59ec1d5e2e (HEAD -> master)
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Thu Aug 1 21:36:37 2024 +0300

    work around a GCC-14 optimizer issue
    
    mbsync throws SIGSEGV in sync_opened(). As it turns out for some
    reason the second entry in the local array 'boxes' is optimized
    out:
    
    (gdb) print boxes
    $1 = {0x5555556c4540, <optimized out>}
    
    Fix this by pinning the variable using a dummy inline assembly
    statement:
    
    __asm__ __volatile__("" :: "m" (boxes));
    
    This sets an invariant, which should guarantee that the compiler
    leaves 'boxes' untouched.
    
    As a comparative measure mbsync was compiled also with clang without the
    fix, and the resulting ELF binary does not have this issue.
    
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2302132
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
        if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
                mvars->chanptr->boxlist = 2;
                char **boxes[2];
+               __asm__ __volatile__("" :: "m" (boxes));
                boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
                boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
                box_ent_t **mboxapp = &mvars->chanptr->boxes;

Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=2302132

2024-08-01
(gdb) print boxes
$1 = {0x5555556c4540, <optimized out>}

I noticed this so I tried:

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
mvars->chanptr->boxlist = 2;
char **boxes[2];
+ __asm__ __volatile__("" :: "m" (boxes));
boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
box_ent_t **mboxapp = &mvars->chanptr->boxes;

That literally fixed the bug! I.e. could this be a #GCC bug?

RT @gromit, @adamw

#mbsync #gcc #fedora #bug #isync
2024-08-01
When using #m2sync, compared to #mbsync, you need to use "maildirpp:" instead of maildir "maildir:".

Just though to mention since I was puzzling around this for few hours, and wondering why #notmuch finds everything, and aerc finds nothing.

EDIT: Had some issues with this but it seems interesting and relevant so I keep tracking this project. Now I at least got the mbsync bug fixed in Fedora.
2024-08-01

I found a modern actively updated alternative for #isync (or #mbsync): #m2sync

It is part of #vomit project: https://sr.ht/~bitfehler/vomit/

Compared to the complexity of ~/.mbsyncrc, my config is now dead simple:

cat .config/vomit/config.toml 
[kapsi]
local = "~/.cache/mail/kapsi"
remote = "mail.kapsi.fi:993"
user = "jjs"
pass-cmd = "pass show imap/mail.kapsi.fi"

I love vomit!

2024-08-01
I realized that despite #mbsync crashing in #Fedora I could use #rsync as a backup because I have also SSH shell to my Maildir.

So I give a shot for that, i.e. ssh+rsync, but over longer period of time, I still would prefer to use mbsync. Anyway, it is a workaround.
2024-07-31
#mbsync always crashes here in #Fedora (even when compiled from upstream):

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055d33068a967 in sync_chans (mvars=0x7ffef80ee330, ent=<optimized out>) at /usr/src/debug/isync-1.4.4-8.fc40.x86_64/src/main.c:906
906 char *sname = boxes[N] ? boxes[N][sb] : NULL;

Any ideas? I used coredumpctl to discover this location but for comparative testing I also compiled the latest upstream of mbsync, and it crashes in the exact same location.

#isync

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst