Your message dated Mon, 21 Oct 2019 00:07:45 +0200
with message-id <[email protected]>
and subject line Re: Bug#942726: interimap: specially treated mailboxes Trash
and Junk are undocumented
has caused the Debian Bug report #942726,
regarding interimap: specially treated mailboxes Trash and Junk are undocumented
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
942726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942726
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: interimap
Version: 0.4-1
Severity: minor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Apparently interimap treats some mailboxes specially:
If mailbox Junk or Trash exist and is non-empty,
then interimap fails with an error requesting to delete those first.
That's a nice idea, but surprising and undocumented.
Also, nice if the names of such special mailboxes were configurable.
- Jonas
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl2shD8ACgkQLHwxRsGg
ASHIUBAAhViSP2re62FndvUU7jpMwlCJA7A6fhWn+pDFmb7qBUA15ooPf0AKyKQ5
1YtcomV/G4E7tiyQ/Ea9h8925ToZJuEJe9kMoXcXB1WzHlyR6rnC9dr6/7XK/aUr
aWsdI88bQApGduklODzODRU18908tAl/xSWdKQWQeAgStwYYjFrYO0ymc6J5ihnX
0ZgkFCxDDfBKWOalffDf+/ZOtnr2oe7WtxAgVHaVpjnumW72/OD+UkSN+/iP096F
WLdBV6PBlEAO+ffkldeuSknc6Ru/ZXmkqq4o89lA/tposV6euGeCCh6B9cGrqkZJ
LiGfSJpIafs1YXBminEjhljavAnek3v5NX+zYdIJPMxnJDbleQLLArny80Qxw5TI
N8P/xvVd+BRVr+dz2PXfYn0ianRsawGJYg0SGuyZ1zauUvukpHMVReiVs44jQCTG
o1bJMkn5HJ1f4sWB+t/iDSm74Qt4EKgQnD//P1FVtBqVcE7torQER0BfPLymOQed
ILPFxH/dugNy5SyNAMZrcSFzhsRxAwdZaDo0TirWPXf+de9dv0K2dWutdI6ImP5h
SvKxp5KQS+jsDD2T8rWBUYJeAYCroYvW9n5i2TtsxbFeNXN1MCdsFt5bkJnWbinn
bQlVOqwPcZdPSH3J7huh4jv+2fnylt7CgcX8MM9d+/aYicN82TM=
=J7JN
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
Quoting Guilhem Moulin (2019-10-20 23:20:52)
> 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?
Ah, it might simply be me messing around: I did a test run until I got
the access setup working, then removed all local data (or so I thought)
and then ran it again. Didn't think of the (now obvious) cause that I
had missed to remove the database and/or the local mailboxes.
> 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 :-)
Thanks for the details - I do think the current error message makes
adequate sense now, though :-)
Closing as a non-bug.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
--- End Message ---
