Control: tag -1 moreinfo On Sun, 20 Oct 2019 at 17:58:55 +0200, Jonas Smedegaard wrote: > Apparently interimap treats some mailboxes specially:
It shouldn't, one can trim the output of the LIST command with the
‘list-*’ options, and perform further filtering with ‘ignore-mailbox’,
but then all mailboxes listed without ‘\NonExistent’ nor ‘\NoSelect’
attributes should be treated equally. It doesn't use the Special-Use
IMAP extension [RFC 6154] to associate mailboxes under the hood.
> If mailbox Junk or Trash exist and is non-empty,
> then interimap fails with an error requesting to delete those first.
I think it's just a coincidence that it happened for your Junk/Trash
mailbox :-P What error message did you get exactly? Was it
database: ERROR: Mailbox $MAILBOX exists. Run `interimap --delete
$MAILBOX` to delete.
? That one appears when 1/ there is a known association in the database
for $MAILBOX between the local and remote servers, and 2/ $MAILBOX is
present on the local or remote server, but not both. A typical
situation is when one runs `interimap` (so $MAILBOX is present on both
servers, and an association is present in the database), then later
either deletes $MAILBOX on one (and only one) server, or renames it to
something else. Could it be what happened? Otherwise, do you have a
reproducer?
Unfortunately I'm not sure how to best solve the above (which thus
should be added to the “Known Bugs And Limitations” section of the
manual :-P). If you deleted $MAILBOX on one server, chances are that
you also want to delete it on the other one and in the database; and if
you renamed it to $MAILBOX2, chances are that you similarly want to
mirror the situation. However IMAP4rev1 doesn't provide a way to
distinguish between these situations (the NOTIFY extension from RFC 5465
would help, but Dovecot support is not working properly and AFAICT no
other server supports it). So instead it aborts and wait for manual
intervention :-/ The safest way out of that issue is to run
interimap --target=database --delete $MAILBOX
(That's also what's suggested in the development version.) That will
remove the association in the database, but not touch the IMAP sides.
The worst that can lead to is duplicates (if the mailbox was in fact
renamed to $MAILBOX2 you'll end up with $MAILBOX and $MAILBOX2 on both
servers), not mail loss.
Silently deleting IMAP mailboxes is not an option due to the risk of
data loss. We can't reliably determine whether the mailbox was deleted
or renamed. (The UIDVALIDITY value can't be relied upon as there there
is no guaranty it uniquely defines a mailbox — there might even be some
collisions.) Moreover the mailbox could have been renamed to something
not LISTed for whatever reason, in which case the program would
incorrectly believe it's been deleted.
That said we could use the UIDVALIDITY value to *suggest* a --rename
command instead of --delete when a mailbox has disappeared on one server
*and* a new mailbox with same UIDVALIDITY value and ≥UIDNEXT/HIGHESTMODSEQ
values has appeared. Any help to improve the heuristic and/or
documentation would be welcome, of course :-)
--
Guilhem.
signature.asc
Description: PGP signature
