#mbsync — Public Fediverse posts

This week #kanchilug meet we discussed about syncing mail to local system using #mbsync (from #isync package). #archwiki is the one we relayed on and it worked flawlessly

https://wiki.archlinux.org/title/Isync

This week #kanchilug meet we discussed about syncing mail to local system using #mbsync (from #isync package). #archwiki is the one we relayed on and it worked flawlessly

https://wiki.archlinux.org/title/Isync

This week #kanchilug meet we discussed about syncing mail to local system using #mbsync (from #isync package). #archwiki is the one we relayed on and it worked flawlessly

https://wiki.archlinux.org/title/Isync

This week #kanchilug meet we discussed about syncing mail to local system using #mbsync (from #isync package). #archwiki is the one we relayed on and it worked flawlessly

https://wiki.archlinux.org/title/Isync

today, i set up emacs gnus as mail client for my work email at microsoft outlook. an administrator of our microsoft-tenant had to approve my client-id and -secret beforehand.

- emacs mail reader: gnus (with some custom elisp)
- sasl plugin kdexoauth2 for cyrus sasl method
- pizauth as oauth2 daemon
- msmtp for smtp
- isync / mbsync for imap

my custom elisp code ensures that pizauth server is running; opens the approval-URL in my browser; and asks me if i have clicked the button in the browser, before it fetches the emails.

as a final step, i'm going to set up mu as gnus search backend. just like i do for my personal emails on my personal computer.

#emacs #gnus #mail #email #outlook #microsoft #oauth #oauth2 #mbsync #isync #msmtp

today, i set up emacs gnus as mail client for my work email at microsoft outlook. an administrator of our microsoft-tenant had to approve my client-id and -secret beforehand.

- emacs mail reader: gnus (with some custom elisp)
- sasl plugin kdexoauth2 for cyrus sasl method
- pizauth as oauth2 daemon
- msmtp for smtp
- isync / mbsync for imap

my custom elisp code ensures that pizauth server is running; opens the approval-URL in my browser; and asks me if i have clicked the button in the browser, before it fetches the emails.

as a final step, i'm going to set up mu as gnus search backend. just like i do for my personal emails on my personal computer.

#emacs #gnus #mail #email #outlook #microsoft #oauth #oauth2 #mbsync #isync #msmtp

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

BTW this is is my current mail setup using #niri + #danklinux  (on top of Fedora on M1 Air).  All the visual peace of  a console client but still  offering preview one shortcut away.

- #mbsync maintains my IMAP boxes synced locally
- #aerc friendly console mail client
- #qutebrowser to preview HTML when I really need to

BTW this is is my current mail setup using #niri + #danklinux  (on top of Fedora on M1 Air).  All the visual peace of  a console client but still  offering preview one shortcut away.

- #mbsync maintains my IMAP boxes synced locally
- #aerc friendly console mail client
- #qutebrowser to preview HTML when I really need to

BTW this is is my current mail setup using #niri + #danklinux  (on top of Fedora on M1 Air).  All the visual peace of  a console client but still  offering preview one shortcut away.

- #mbsync maintains my IMAP boxes synced locally
- #aerc friendly console mail client
- #qutebrowser to preview HTML when I really need to

BTW this is is my current mail setup using #niri + #danklinux  (on top of Fedora on M1 Air).  All the visual peace of  a console client but still  offering preview one shortcut away.

- #mbsync maintains my IMAP boxes synced locally
- #aerc friendly console mail client
- #qutebrowser to preview HTML when I really need to

BTW this is is my current mail setup using #niri + #danklinux  (on top of Fedora on M1 Air).  All the visual peace of  a console client but still  offering preview one shortcut away.

- #mbsync maintains my IMAP boxes synced locally
- #aerc friendly console mail client
- #qutebrowser to preview HTML when I really need to

OK, I'm going to give it another try to make #emacs, #msmtp, #mbsync, #notmuch 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.

OK, I'm going to give it another try to make #emacs, #msmtp, #mbsync, #notmuch 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.

OK, I'm going to give it another try to make #emacs, #msmtp, #mbsync, #notmuch 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.

OK, I'm going to give it another try to make #emacs, #msmtp, #mbsync, #notmuch 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.

OK, I'm going to give it another try to make #emacs, #msmtp, #mbsync, #notmuch 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.

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

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

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).

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:

https://cosroe.com/2025/04/neomutt-notmuch-mbsync.html

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:

https://cosroe.com/2025/04/neomutt-notmuch-mbsync.html

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:

https://cosroe.com/2025/04/neomutt-notmuch-mbsync.html

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)

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)

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)

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)

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)

#homelab What didn't go as well:
- Needed flatpaks & appimages for more recent versions than in #leap but I'll live. I'm not ready for #tumbleweed for a daily driver.
- Using the Vorta GUI for Borg backup under sudo. Kludged it with waypipe.
- offlineimap (python2). There's a Py3 version but it was a no go even trying to use the git repo. Switched to #mbsync.
- Fighting the firewall. Default on. Pulled my hair out for a while with mDNS etc.
- atuin uses sqlite3 which behaves badly on ZFS.

Spass: #mbsync synct alle Mailboxen. Beim nächsten Aufruf beschwert es sich. dasdie Foldertiefe zu hoch ist (vuiele Folder in der Hiearchie).... und will nimmer ;)

After a lot of other stuff I’m back at it. TIL that php ENUMS are kind of hard to do assertions on in PHPUnit. assertSame and assertEquals both don’t work.

What I can do though is this:
$this->assertSame(SyncStatus::Pending->value, $syncStatusAfter->value);
#buildinpublic #mbsync

After many hours of familystuff, I’m back trying to see why one of the tests is still failing, now that my sidequest about the seeder is complete. #buildinpublic #mbsync

I’m working on a little side quest atm. I’m creating a database seeder that automatically adds a user to the db so that I can reset the db quicker. It’s pretty easy with laravel and I love the distinction between migrations (schema changes) and seeders (data additions) #buildinpublic #mbsync

Today I’m spending time in the library working on my notes. I thought I’d try to do a #buildinpublic kind of thing, since it was fun the last couple of days to post about what I’m doing as regards to #mbsync. so I’m going to try this here, too. Hashtags will be #buildinpublic and #zknstuff.

#buildinpublic #mbsync That’s it for today. Lots of little things done. Learned some stuff and realized a lot of things about how to structure the sync state. This’ll be the most important part of the app, so it’s alright if it takes some time and some attempts to get right.

#buildinpublic #mbsync Alright. The test for a post that is unchanged does the ting and I created already a similar test for a newly created post. However I don’t like how the sync status is saved in the db. Or rather how differnt kinds of logic are reduced to only the sync state. We need to differentiate between the state of the sync itself and (pending/synchronized/error) and what we sync ... https://blog.martin-haehnel.de/2024/04/13/buildinpublic-mbsync-alright.html

#buildinpublic #mbsync So. Me the last few hours:

"I’m not distracted, I’m on a side quest.
— https://beige.party/@RickiTarr/112264314660393539"

Where was I? Oh yes. Refactoring/Writing a test for the markForSync method. I have the starting point for the test, which creates a post using a factory and writes that same data to disk. Now we need to run the post through our method and see that the posts sync_status is not marked for creation/update/deletion.

#buildinpublic #mbsync Ugh. And even more problems. I use the laravel validated dto package, because I like working with DTOs and getting validation “for free” is nice. However:

If a post doesn’t have a category the mb api returns an empty array. Fine. I can validate this as 'categories' => ['present', 'array'],, but interestingly the DTOs saves this internally as null. And guess what? categories in not nullable anymore when I try to save a post with empty categories to the db. Hmpf.

#buildinpublic #mbsync Discoverd another problem: I was allowing the categories field (json in the db) in my Post model to be null. Turns out if you do that you can’t cast that json to array through eloquent. So I changed that in my migrations, but this means that the assumption you can write a post to the db with categories being null doesn’t hold anymore. So more yak shaving… https://laracasts.com/discuss/channels/laravel/cast-to-array-not-working

Is there any way to use #mbsync with the Cyrus SASL plugin, but restrict that plugin to only one mail account? Installing that plugin prevents 3 of my 4 email accounts from syncing, but the fourth requires OAUTH2 to be able to connect.

#isync #neomutt

Finally set up #mbsync (or #isync) correctly enough to for uplink-downlink sync to work and it's like magic. Processed my email with #mu4e and hundreds of emails that were piling up since July were deleted and filed away in an evening.

Idk what's up with Firefox these days (besides, like, laying off hundreds of people) but it wouldn't download the Gmail attachments I needed for work, so my plans for using #Emacs as my email client got stepped up all of a sudden. I did get as far as fetching mail using #Mu a couple weeks ago but not automatic synchronization, so I set up an #isync / #mbsync service and timer according to the instructions on this page, https://wiki.archlinux.org/index.php/Isync ran M-x mu4e on Emacs and voila, new email. Pressed e, downloaded all 8 files at once from the prompt and done. I finally have a dedicated email client back, even if it's a program I barely know how to use yet!

I'm syncing my mail manually for 2 years now. Switched from #OfflineIMAP to #mbsync in the meantime. I'm still not sure if it's good or bad or neutral that it says:

Maildir warning: ignoring INBOX

Okay, jetzt habe ich mal #mbsync ausprobiert. Ja, es ist schneller. Aber es synct irgenwdie längst nicht alle Folder und bringt komische Fehlermeldungen (INBOX will er nicht aufmachen, einige Folder kann er lokal nicht öffnen, ...) das geht wohl wieder Richtung #offlineimap

@true_mxp I just switched to #OfflineIMAP for use with #DavMail.

But my problem was that my Exchange instance somehow assigned duplicate UIDs to different emails in different folders, so #mbsync just couldn't download a large part of my mail. And OffineIMAP had some way to handle that more gracefully.

After some months of using #mbsync I noticed that unlike #offlineimap it doesn't sync all of the mail, just few months of the most recent letters... Can't find anything about this behavior in the docs.

#DavMail has always been slow (I’m using it with #mbsync to access my work e-mail), but now it has become unbearably slow: what used to take maybe 30 s, now takes 4–5 min. Has anybody else noticed this?

Update on my experiences with #DavMail and #mbsync: after a lot of experimentation, it turned out that the problem of unsynced messages occurred with messages above a certain size. Apparently DavMail behaves in a way that differs from other #IMAP servers and that mbsync doesn’t handle well.

I’ve massively increased the size of buf in src/socket.h (from 100000 to 5000000), and this seems to have solved the problem. The real problem is probably in the protocol handling, but this is at least a workaround that allows me to continue reading mail with #mu4e in #Emacs.

@moritz Habe #davmail auf dem MacBook laufen, und da hat es sich gemeldet, als das token abgelaufen ist. Zumindest der teil sollte funktionieren… Mein problem ist vor allem, dass es überhaupt nicht mit #mbsync harmonisiert. Jetzt ist es ein paar tage ohne fehlermeldung gelaufen, aber schon jammert mbsync wieder über volle input buffers :-/ Immerhin fehlen anscheinend noch keine nachrichten … Wenn es zuverlässig funktionieren würde, wäre es auch nicht so schlimm, dass es lahm ist …

@Cnoceda @ericsfraga Unfortunately, my experience so far with #davmail, #mbsync, and #MicrosoftExchange: it’s hopeless.

I’ve tried both mbsync 1.4.4 and the current git version. I thought I had it working when it finally didn’t stop with some error—but then I discovered that hundreds of messages were never synchronized.

This is a disaster.