Dear fellow nerds,

I recently started to use aerc, synched locally with mbsync. Unfortunately, I’m facing a rather annoying problem with Gmail:

  • I read emails (flag “seen”) and move them to the archive;
  • run the mbsync < account > command to sync;
  • the mails are correctly moved, however, they seem to lose the “seen” flag, and they revert to unread.

Am I missing something? Any idea what could be the problem? If it matters, I’m on a Wayland session on NixOS.

Thanks!

  • gnuhaut@lemmy.ml
    2·
    10 days ago

    The “seen” flag should be represented by an “S” in the filename of the mail (see Maildir spec).

    You could probably observe filename changes using:

    fsnotifywait -m $YOUR_MAILDIR -r -e move -e create -e delete

    While that is running in your terminal, move a mail using aerc, and see if aerc correctly preserves the “S” flag in the filename.

    • Luca Mancini@lemmy.worldOP
      1·
      5 days ago

      I tried a few things, and the aerc behaviour seems fine. When I read an email, the “S” is added, and when I move it, the flag is preserved.

      However, I observed 2 scenarios:

      • If I read > mbsync > move > mbsync, the result is the expected one, having the mail red and moved on both server and locally;
      • If I read > move > mbsync, the mail is red and moved locally, but it’s only moved on the server. This means that the next time that I do mbsync, the mail will revert to unread locally.

      One thing I noticed (which might be the problem somehow?) is that:

      • The filename is initially something like “1756379541.12762_13.host,U=13:2,”
      • After the reading changes to “1756379541.12762_13.host,U=13:2,S”
      • After the moving changes to “1756379541.12762_13.host:2,S”
      • After the sync changes to “1756379541.12762_13.host,U=3376:2,S”
      • And eventually, after another sync the S flag is removed

      This means that the difference in the 2 scenarios above, is that in the first case (the expected one) the mail is synced while having the U=13 present, while in the second case is synced with the U removed.
      I tried to understand what’s the meaning of that part (which looks like an ID) and if it’s relevant in the process, but I didn’t find any information, sadly.

      For now, I think I will just use the imap connection rather than local, but if you have any insights, please let me know! 🙃 And thanks again for the debugging tip, it really helped to understand what’s going on! :D

      • gnuhaut@lemmy.ml
        1·
        5 days ago

        That “U=xxx” is the IMAP UID, which is a unique identifier that message has in the IMAP mailbox. mbsync adds that to the filename just so it can track which (local) message corresponds to what message on the IMAP server.

        When moving a message from one mailbox (folder) to another, this UID changes, because it’s per-mailbox only. If you read the manpage for mbsync, it says explicitly that the MUA should strip the U=xxx when moving between maildirs, so the behavior of aerc here is correct.

        In order to get to the bottom of this, you’d probably have to enable the debug output of mbsync and look at exactly what IMAP commands it sends to Gmail, then decipher the relevant command(s) by looking at the RFC, and then decide whether it’s Gmail or mbsync’s fault this gets lost. You could also contact the mbsync devs with this I guess.

        I found someone complaining about the same issue, without getting a reply, 7 years ago, except that person was using mutt: https://stackoverflow.com/questions/52218254/isync-mbsync-on-gmail-marks-mail-as-new-after-move-to-another-folder

        That doesn’t help you obviously but from this we might guess it’s probably not aerc’s fault.

    • Luca Mancini@lemmy.worldOP
      2·
      10 days ago

      Thank you very much the info! I was looking for something like this, but eventually I failed 😆
      I’ll try as soon as I can and get back with the result!