offlineimap or mbsync?

[Stephen Eglen]

I've been using offlineimap for the last few months, and find it okay although have noticed occasional glitches (nothing reproducible) with duplicated emails.
Searching around, I found these two interesting posts


http://blog.ezyang.com/2012/08/offlineimap-sucks/

http://blog.ezyang.com/2012/08/how-offlineimap-works/

As you can imagnie, the first is quite critical!

Has anyone else used mbsync?

Stephen

[Samuel Loury]

Hi,
I've not read the links you provided yet. I use offlineimap for 1
year now and I've never noticed any problem. Can you describe the
glitches you refer to ?
--
Konubinix
GPG Key: 7439106A

[James Ladan]

On Tuesday, 13 November 2012 04:28:41 UTC-8, Stephen Eglen wrote:

Has anyone else used mbsync?

Repeating Stephen's question... has anyone tried mbsync?

I just set up a new machine and decided to try mbsync instead of offlineimap and ran into an issue almost right away.

When mbsync tries to sync my All Mail folder for Gmail, I get the error "Error: UIDVALIDITY of slave changed". This happened after I moved a message from my Inbox to All Mail (maybe I shouldn't... but that's how I was dealing with removing the inbox "label" and leaving something in "all mail").

It looks like the problem is that mu4e doesn't rename the message file when it's moved to another maildir. The manpage for mbsync has this to say about UIDs (emphasis mine):

As mbsync needs UIDs, but no standardized UID storage scheme exists for Maildir, mbsync supports two schemes, each with its pros and cons. The native scheme is stolen from the latest Maildir patches to c-client and  is therefore compatible with pine. The UID validity is stored in a file named .uidvalidity; the UIDs are encoded in the file names of  the messages.

...

The native scheme is faster, more space efficient,  endianess  independent and "human readable", but will be disrupted if a message is copied from another mailbox without getting a new file name; this would result in  duplicated  UIDs  sooner  or  later, which in turn results in a UID validity change, making synchronization fail.

Dirk - have you considered renaming files on move? A couple emails I sent were synced just fine from my sent mail folder back to gmail. One note is that mbsync doesn't rename the file, where IIRC, offlineimap did.

Maybe I should just switch back to offlineimap... but other than this issue, mbsync seems nice so far.

Thanks,
James.

[Augie Fackler]

On Apr 15, 2013, at 7:17 PM, James Ladan <ja...@ladan.ca> wrote:

> On Tuesday, 13 November 2012 04:28:41 UTC-8, Stephen Eglen wrote:
>
>> Has anyone else used mbsync?
>>
>
> Repeating Stephen's question... has anyone tried mbsync?

I've been using mbsync instead of offlineimap for ~3 months, and it's been astoundingly fast by comparison.

>
> I just set up a new machine and decided to try mbsync instead of
> offlineimap and ran into an issue almost right away.
>
> When mbsync tries to sync my All Mail folder for Gmail, I get the error
> "Error: UIDVALIDITY of slave changed". This happened after I moved a
> message from my Inbox to All Mail (maybe I shouldn't... but that's how I
> was dealing with removing the inbox "label" and leaving something in "all
> mail").
>
> It looks like the problem is that mu4e doesn't rename the message file when
> it's moved to another maildir. The manpage for mbsync has this to say about
> UIDs (emphasis mine):
>
> As mbsync needs UIDs, but no standardized UID storage scheme exists for
> Maildir, mbsync supports two schemes, each with its pros and cons. The
> native scheme is stolen from the latest Maildir patches to c-client and is
> therefore compatible with pine. The UID validity is stored in a file named
> .uidvalidity; the UIDs are encoded in the file names of the messages.
> ...
> The native scheme is faster, more space efficient, endianess independent

> and "human readable",* but will be disrupted if a message is copied from
> another mailbox without getting a new file name*; this would result in

> duplicated UIDs sooner or later, which in turn results in a UID
> validity change, making synchronization fail.
>
>
> Dirk - have you considered renaming files on move? A couple emails I sent
> were synced just fine from my sent mail folder back to gmail. One note is
> that mbsync doesn't rename the file, where IIRC, offlineimap did.
>
> Maybe I should just switch back to offlineimap... but other than this
> issue, mbsync seems nice so far.

I've not noticed this, but I only use my mbsync'ed copy for reading messages in some non-INBOX areas where Thunderbird/Mail.app is a disaster.

>
> Thanks,
> James.
>
> --
> You received this message because you are subscribed to the Google Groups "mu-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[James Ladan]

On Tue, Apr 16, 2013 at 2:35 PM, Augie Fackler <r...@durin42.com> wrote:

On Apr 15, 2013, at 7:17 PM, James Ladan <ja...@ladan.ca> wrote:
 > Repeating Stephen's question... has anyone tried mbsync?

I've been using mbsync instead of offlineimap for ~3 months, and it's been astoundingly fast by comparison.

Yes, I'd really like to continue using it.

> When mbsync tries to sync my All Mail folder for Gmail, I get the error
> "Error: UIDVALIDITY of slave changed". This happened after I moved a
> message from my Inbox to All Mail (maybe I shouldn't... but that's how I
> was dealing with removing the inbox "label" and leaving something in "all
> mail").
>
> It looks like the problem is that mu4e doesn't rename the message file when
> it's moved to another maildir. The manpage for mbsync has this to say about
> UIDs (emphasis mine): 

...

 

I've not noticed this, but I only use my mbsync'ed copy for reading messages in some non-INBOX areas where Thunderbird/Mail.app is a disaster.

Hmm. Have you tried moving messages between folders using mu4e and then re-syncing? From the mbsync man page it sounds like the issue may not appear right away, though. I wonder if it appeared right away in my case because the email would have already existed in both inbox and "all mail".

Thanks,

James.

[Alan Schmitt]

James Ladan writes:

> On Tue, Apr 16, 2013 at 2:35 PM, Augie Fackler <r...@durin42.com> wrote:
>
>> On Apr 15, 2013, at 7:17 PM, James Ladan <ja...@ladan.ca> wrote:
>> > Repeating Stephen's question... has anyone tried mbsync?
>>
>> I've been using mbsync instead of offlineimap for ~3 months, and it's been
>> astoundingly fast by comparison.
>
> Yes, I'd really like to continue using it.

This made me curious: how was the migration from one to the other? I
have a working offlineimap setup here, but I also find it quite slow.

Thanks,

Alan

[James Ladan]

On Wednesday, 17 April 2013 04:18:34 UTC-7, Alan Schmitt wrote:

This made me curious: how was the migration from one to the other? I
have a working offlineimap setup here, but I also find it quite slow.

The reason I decided to try it was in setting up the new box, offlineimap wanted to resync all of my email... so I figured if that was going to happen I might as well try mbsync.

For Gmail, it was a little annoying, as the [Gmail]/ prefix on inbox, all mail, trash, etc. takes a bit of tweaking to handle. I ended up creating unique "channels" for each folder I wanted synced:

Channel gmail-inbox

Master :gmail-remote:INBOX

Slave :gmail-local:Inbox

Create Both

Expunge Both

Sync All

SyncState *

Aside from the issue with moved messages not being renamed, I like how it's working so far, and mbsync is certainly more light-weight.

offlineimap with no changes to update:

real 0m19.572s

user 0m3.096s

sys 0m0.336s

mbsync with no changes to update:

real 0m13.661s

user 0m0.127s

sys 0m0.043s

Cheers,
James.

[Alan Schmitt]

James Ladan writes:

> The reason I decided to try it was in setting up the new box, offlineimap
> wanted to resync all of my email... so I figured if that was going to
> happen I might as well try mbsync.
>
> For Gmail, it was a little annoying, as the [Gmail]/ prefix on inbox, all
> mail, trash, etc. takes a bit of tweaking to handle. I ended up creating
> unique "channels" for each folder I wanted synced:
>
> Channel gmail-inbox
> Master :gmail-remote:INBOX
> Slave :gmail-local:Inbox
> Create Both
> Expunge Both
> Sync All
> SyncState *
>
>
> Aside from the issue with moved messages not being renamed, I like how it's
> working so far, and mbsync is certainly more light-weight.

Thanks a lot, I'll definitely have a look.

Alan

[Alan Schmitt]

Hi,

So I tried to set it up this week-end and I managed to get it working. I
had to use the version from git to be able to synchronize subfolders,
but that was not too difficult. There was a showstopper bug for me,
though, which made me go back to offlineimap..

James Ladan writes:

> Aside from the issue with moved messages not being renamed, I like how it's
> working so far, and mbsync is certainly more light-weight.

I tried moving a message from my inbox to a folder, and upon the next
synchronization, I got an error "Maildir error: duplicate UID 49." The
problem is that the message was actually deleted: it was no longer in
the inbox, and was not in the destination folder. I'm lucky I only lost
one message and noticed this immediately.

To avoid this issue, do you simply not move any message at all?

Thanks,

Alan

[James Ladan]

On Mon, Apr 22, 2013 at 12:00 AM, Alan Schmitt <alan.s...@polytechnique.org> wrote:

I tried moving a message from my inbox to a folder, and upon the next
synchronization, I got an error "Maildir error: duplicate UID 49." The
problem is that the message was actually deleted: it was no longer in
the inbox, and was not in the destination folder. I'm lucky I only lost
one message and noticed this immediately.

Yikes. That's definitely no good! I didn't lose the email that caused the sync issue for me. If I had, I would have cautioned against even trying it.

To avoid this issue, do you simply not move any message at all?

Yes, unfortunately, that's basically what I've been doing for now.

I've actually gone to a mode where I'm using Gmail more than mu4e, so it's not too painful. I'd like to go back the other way... I just formed a bad habit when auto-completion stopped working in Emacs 23. Now I'm using Emacs 24 finally, and auto-completion works but now I can't move messages due to going with mbsync. Not in a hurry to download all of my email yet again to switch back to offlineimap.

James.

[Max]

The very neat feature of offlineimap is its ability to use keyring to request
password with python script.

As far as I can tell the only way for mbsync is to read plaintext password from
configuration file - this makes it way less secure.

would be happy to hear corrections,
Max.

[James Ladan]

On Mon, Apr 22, 2013 at 12:23 AM, Max <govnotot...@gmail.com> wrote:

The very neat feature of offlineimap is its ability to use keyring to request
password with python script. 

As far as I can tell the only way for mbsync is to read plaintext password from
configuration file - this makes it way less secure.

Haven't tried otherwise. After having keyring trouble one too many times with offlineimap (probably the fault of the keyring, not offlineimap), I switched to using encfs for files that contain credentials. Maybe not perfect, but the files in the encfs mount are not available to any other user.

 

[Max]

22.04.2013 09:31, James Ladan пишет:

> but the files in the
> encfs mount are not available to any other user.
>

Only when you're not logged in. Once you've logged in - the files on encfs are
indistinguishable from files on any other partition. That's important point to
remember - and that's why I'd love to see keyring support implemented in mbsync, the
same way it's implemented in msmtp for example.

cheers,
Max.

[Alan Schmitt]

To get around this, I used expect to launch mbsync. More precisely I
have a shell script that gets the password from my OS X keychain (you
can replace USER and SERVERNAME by the ones you want):

--8<---------------cut here---------------start------------->8---
#!/bin/sh

PASSWD=`/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain`

/Users/schmitta/bin/call_mbsync $1 $PASSWD
--8<---------------cut here---------------end--------------->8---

Then I use expect to enter the password

--8<---------------cut here---------------start------------->8---
#!/usr/bin/expect

# disable timeout (otherwise is 10 seconds)
set timeout -1
set channel [lindex $argv 0]
set passwd [lindex $argv 1]
spawn -noecho mbsync -c /Users/schmitta/etc/mbsync-config $channel
expect "Password (inria): "
send "$passwd\r"
expect eof
exit 0
--8<---------------cut here---------------end--------------->8---

Hope this helps,

Alan

[Alan Schmitt]

James Ladan writes:

> On Mon, Apr 22, 2013 at 12:00 AM, Alan Schmitt <
> alan.s...@polytechnique.org> wrote:
>
>> I tried moving a message from my inbox to a folder, and upon the next
>> synchronization, I got an error "Maildir error: duplicate UID 49." The
>> problem is that the message was actually deleted: it was no longer in
>> the inbox, and was not in the destination folder. I'm lucky I only lost
>> one message and noticed this immediately.
>>
>
> Yikes. That's definitely no good! I didn't lose the email that caused the
> sync issue for me. If I had, I would have cautioned against even
> trying it.

I've asked the isync mailing list about it. I'd really like to get it
working, not only because it's faster, but I'm having issues with
offlineimap not expunging messages (it's leaving messages with the T
flag in my inbox).

>> To avoid this issue, do you simply not move any message at all?
>
> Yes, unfortunately, that's basically what I've been doing for now.
>
> I've actually gone to a mode where I'm using Gmail more than mu4e, so it's
> not too painful. I'd like to go back the other way... I just formed a bad
> habit when auto-completion stopped working in Emacs 23. Now I'm using Emacs
> 24 finally, and auto-completion works but now I can't move messages due to
> going with mbsync. Not in a hurry to download all of my email yet again to
> switch back to offlineimap.

Thanks for the explanation.

Best,

Alan

[Alan Schmitt]

James Ladan writes:

> Dirk - have you considered renaming files on move? A couple emails I sent
> were synced just fine from my sent mail folder back to gmail. One note is
> that mbsync doesn't rename the file, where IIRC, offlineimap did.

It seems that renaming the file on move would be the only way to have
mu4e and mbsync play nicely together. One could also use the alternative
mapping scheme, but it seems to be less efficient.

Alan

[James Ladan]

True, to processes running under my UID. Not quite as good as per-program access control. (Does Gnome keyring do that? I don't recall.)

Cheers,

James.

[James Ladan]

On Mon, Apr 22, 2013 at 12:43 AM, Alan Schmitt <alan.s...@polytechnique.org> wrote:

I've asked the isync mailing list about it. I'd really like to get it

working, not only because it's faster, but I'm having issues with
offlineimap not expunging messages (it's leaving messages with the T
flag in my inbox).

Somewhat terse responses. :) Basically affirms the documentation.

Thanks for the explanation.

Sorry I wasn't clearer earlier.

Cheers,
James.

[Max]

24.04.2013 10:08, James Ladan пишет:

Not sure either but direct access to plaintext password by reading known file is
obviously way easier than calling to gnome keyring api functions.

cheers,
Max.

[Jann Horn]

On Mon, Apr 22, 2013 at 09:40:17AM +0200, Alan Schmitt wrote:
> Max writes:
>
> > The very neat feature of offlineimap is its ability to use keyring to request
> > password with python script.
> >
> > As far as I can tell the only way for mbsync is to read plaintext password from
> > configuration file - this makes it way less secure.
> >
> > would be happy to hear corrections,
> > Max.
>
> To get around this, I used expect to launch mbsync. More precisely I
> have a shell script that gets the password from my OS X keychain (you
> can replace USER and SERVERNAME by the ones you want):
>
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
>
> PASSWD=`/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain`
>
> /Users/schmitta/bin/call_mbsync $1 $PASSWD

This is frigging insecure, *never do that*!

Every process on your system that isn't chrooted (or in a different PID namespace) can see
the command lines of every process, even if the process belongs to another user. Try
running `ps aux` or so on a multi-user system – you'll see everyone's processes, not just
yours, with the complete command line. This works by reading /proc/<pid>/cmdline – this contains
the command-line arguments of every process and is world-readable without any restrictions.

So, never put sensitive data into a cmdline, always pass it through files or pipes.

[Max]

16.05.2013 08:54, Jann Horn пишет:

completely agree.

here is the feature request for keyring support -
http://sourceforge.net/tracker/?func=detail&aid=3611534&group_id=69662&atid=525347

[Alan Schmitt]

Jann Horn writes:

>> To get around this, I used expect to launch mbsync. More precisely I
>> have a shell script that gets the password from my OS X keychain (you
>> can replace USER and SERVERNAME by the ones you want):
>>
>> --8<---------------cut here---------------start------------->8---
>> #!/bin/sh
>>
>> PASSWD=`/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain`
>>
>> /Users/schmitta/bin/call_mbsync $1 $PASSWD
>
> This is frigging insecure, *never do that*!
>
> Every process on your system that isn't chrooted (or in a different PID namespace) can see
> the command lines of every process, even if the process belongs to another user. Try
> running `ps aux` or so on a multi-user system – you'll see everyone's processes, not just
> yours, with the complete command line. This works by reading /proc/<pid>/cmdline – this contains
> the command-line arguments of every process and is world-readable without any restrictions.
>
> So, never put sensitive data into a cmdline, always pass it through files or pipes.

OK, I won't ;-)

How would I do the same thing using a file or pipes?

Thanks,

Alan

[Jann Horn]

> How would I do the same thing using a file or pipes?

With a pipe, you could do it this way:

/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain | /Users/schmitta/bin/call_mbsync $1

However, I have no idea how you'd read that in "expect". Here's another solution – quick and dirty, but should work:

PASSWD=`/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain`

expect -f - <<EOF

# disable timeout (otherwise is 10 seconds)
set timeout -1

set passwd "$2"
spawn -noecho mbsync -c /Users/schmitta/etc/mbsync-config "$1"
expect "Password (inria): "
send "$PASSWD\r"
expect eof
exit 0
EOF

Note: I didn't test this.

[Alan Schmitt]

Jann Horn writes:

> With a pipe, you could do it this way:
>
> /usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain | /Users/schmitta/bin/call_mbsync $1
>
> However, I have no idea how you'd read that in "expect". Here's another solution – quick and dirty, but should work:
>
> PASSWD=`/usr/bin/security -v find-internet-password -g -a USER -s SERVERNAME -w ~/Library/Keychains/login.keychain`
> expect -f - <<EOF
> # disable timeout (otherwise is 10 seconds)
> set timeout -1
> set passwd "$2"
> spawn -noecho mbsync -c /Users/schmitta/etc/mbsync-config "$1"
> expect "Password (inria): "
> send "$PASSWD\r"
> expect eof
> exit 0
> EOF
>
> Note: I didn't test this.

Thanks a lot!

Alan

[Marius Hofert]

Hi Alan,

So do you use mbsync? If so, can you post your settings, please?

Cheers,

Marius

[Alan Schmitt]

Hello Marius,

Marius Hofert writes:

> So do you use mbsync? If so, can you post your settings, please?

I don't, because of the renaming issue. Until it is changed, I prefer to
stick to offlineimap.

Alan

[Marius Hofert]

Thanks, Alan.

But there is no 'issue' open on github: https://github.com/djnym/isync

How should they fix the problem if they don't know about it? :-)

[Alan Schmitt]

Hello Marius,

Marius Hofert writes:

> Thanks, Alan.
>
> But there is no 'issue' open on github: https://github.com/djnym/isync
>
> How should they fix the problem if they don't know about it? :-)

For the mbsync author, the problem is not on mbsync's side:
http://sourceforge.net/mailarchive/message.php?msg_id=30754681

Unfortunately, Dirk does not seem too eager to rename messages when
moving them (although he might consider some patch to do so, as this
email suggests):
https://groups.google.com/d/msg/mu-discuss/3MjUIen8B1s/dkumdjJJsvYJ

There is a feature request on mu's github:
https://github.com/djcb/mu/issues/146

Alan

[Marius Hofert]

Alan Schmitt writes:

> Hello Marius,
>
> Marius Hofert writes:
>
>> Thanks, Alan.
>>
>> But there is no 'issue' open on github: https://github.com/djnym/isync
>>
>> How should they fix the problem if they don't know about it? :-)
>
> For the mbsync author, the problem is not on mbsync's side:
> http://sourceforge.net/mailarchive/message.php?msg_id=30754681

ahh, okay.

>
> Unfortunately, Dirk does not seem too eager to rename messages when
> moving them (although he might consider some patch to do so, as this
> email suggests):
> https://groups.google.com/d/msg/mu-discuss/3MjUIen8B1s/dkumdjJJsvYJ
>

How serious is that 'moving/renaming message' bug?
For example, does it already appear when flagging a read message for
deleting (=> message will be deleted => moved from inbox to trash)? That
would make mbsync useless.

Can you say some words when it works and when it doesn't?

[I read your post on April 22 when you tried to move a message from the
inbox to another, but it's not clear to me how serious this problem
is. I've never moved messages around but could image at some point to
move a message from the trash back to the inbox... a problem?]

>
> There is a feature request on mu's github:
> https://github.com/djcb/mu/issues/146

okay, I subscribed, too.

>
> Alan

[Alan Schmitt]

Marius Hofert writes:

> How serious is that 'moving/renaming message' bug?
> For example, does it already appear when flagging a read message for
> deleting (=> message will be deleted => moved from inbox to trash)? That
> would make mbsync useless.
>
> Can you say some words when it works and when it doesn't?

If you move a message without changing the name, this is what happens
with mbsync (assuming you're synchronizing a local client and a server):
- it sees the message has disappeared in some mailbox in the client, so
it deletes it on the server;
- it sees a new message in another mailbox, but the name is already
used, so it is not put on the server and an error is signaled.

The consequence is that the client and the server are now out of sync:
the server is missing one message. The reason I lost some mail was my
fault: I was not aware the message was still present on the client and
when I starting synchronizing using offlineimap, I got messages from the
server.

To solve this, one can manually rename the file, and mbsync will
properly synchronize it.

Alan

[Joost Kremers]

On Tue, May 21 2013, Alan Schmitt <alan.s...@polytechnique.org> wrote:
> If you move a message without changing the name, this is what happens
> with mbsync (assuming you're synchronizing a local client and a server):
> - it sees the message has disappeared in some mailbox in the client, so
> it deletes it on the server;
> - it sees a new message in another mailbox, but the name is already
> used, so it is not put on the server and an error is

[...]

> To solve this, one can manually rename the file, and mbsync will
> properly synchronize it.

Has anyone tried using the AltMap option of mbsync? Seems like it's
designed to work around this issue. The man page does warn that "[t]he
alternative scheme would fail if a MUA changed a message’s file name in
a part mbsync considers invariant; this would be interpreted as a
message deletion and a new message, resulting in unnecessary traffic",
but I think unnecessary traffic isn't as bad as a failing sync.

--
Joost Kremers
Life has its moments

[Stephen Eglen]

Just curious if anyone has had any success with mbsync, rather than offlineimap.

Here's a recent (November 2013) thread re: mbsync and offlineimpa with gmail, but no definite win.

https://bbs.archlinux.org/viewtopic.php?id=173039

I'm curious about this as I'm thinking of biting the bullet and implementing a little script to delete attachments from msgs, but I need to be sure that

they will get back to the server after editing.  (I might try mutt first with a direct connection to the server!)

Stephen

[uu1...@gmail.com]

I have recently begun using mbsync with mu4e. Although the feature described in this thread was implemented, there is currently (at least) one issue remaining, see https://github.com/djcb/mu/issues/321.

With regards to mbsync, be sure to use HEAD, so that you can use the PassCmd setting and some other stuff. Below is part of my .mbsync config, in case you are interested:


IMAPAccount example
Host imap.gmail.com
User exa...@gmail.com
PassCmd "~/.bin/imap-get-password exa...@gmail.com imap.gmail.com"
UseIMAPS yes
RequireSSl yes
UseTLSv1.2 yes
CertificateFile ~/.ca-certificates/ca-bundle.crt

IMAPStore example-remote
Account example

MaildirStore example-local
Path ~/.mail/example/
Inbox ~/.mail/example/INBOX

Channel example
Master :example-remote:
Slave :example-local:
# Opt-in for interesting [Gmail]* folders.
Patterns * ![Gmail]* "[Gmail]/Trash" "[Gmail]/Drafts" "[Gmail]/Starred" "[Gmail]/Sent Mail"
Create Slave

Expunge Both
Sync All
SyncState *

Best regards,
UU.

[Stephen Eglen]

On Sunday, December 1, 2013 1:56:49 AM UTC+1, uu1...@gmail.com wrote:

I have recently begun using mbsync with mu4e. Although the feature described in this thread was implemented, there is currently (at least) one issue remaining, see https://github.com/djcb/mu/issues/321.

With regards to mbsync, be sure to use HEAD, so that you can use the PassCmd setting and some other stuff. Below is part of my .mbsync config, in case you are interested:

Thanks, this looks very helpful + having an example .mbsynrc file is great.