First of all, thanks for the quick responses. My dim mind is finally getting itself wrapped around these issues. And also thanks for making such an impressive app. I wish more linux/unix servers were as easy to set up and understand as Binc :-)
On Thu, 2004-09-30 at 15:06, Andreas Aardal Hanssen wrote: > You should be aware that the problem _is_ caused by a bug in offlineimap, > so it's not all bad to apply the patch that Daniel suggested. Or to email > the offlineimap maintainers and get them to fix it. The bug is that > offlineimap stores file names in new/ with characters that are disallowed > by the standard. > Yes, I realize that now, and the patch seems to make sense. My worry is only my own insecurity, i.e. what offlineimap does is pretty much 'magic' to me, yet I let it operate on my mail, which is pretty important to me. So the idea of patching it with something I don't quite understand and which has seemingly only been tested by the original author is a little scary. When I have some more time to try and understand the source and setup some test mailboxes, I will probably venture there, but for the time being i would rather not. I will however mail the offlineimap author and ask about this issue. > This is true, but UW-IMAP doesn't support nested mailboxes, only nested > UNIX paths. Or to make it clear: UW-IMAP has no special folder structure. > When you log in as john, it lists all files in ~john. Then you need to > navigate to the folder that contains mailbox-files. Typically you would > search for mailboxes in the "Mail/" or "mail/" directory. UW-IMAP does not > support structures such as INBOX/Work or Groups/BincIMAP/News, if INBOX is > a mailbox and Groups is a mailbox and BincIMAP is a mailbox. INBOX is > hardcoded to /var/spool/mail/john or something like that. This approach is > considered unsafe for several obvious reasons. :-) Ah, ok, I will stay well away from UW-imap then. thanks. In any case, for a local IMAP server to be used only by myself from localhost, I am not even considering setting up anything more complex than binc. > Binc IMAP, on the other hand, operates only inside a single mail depot, > and if you set the chroot path, user and group, it also considers the > depot as its jail. It enters the jail, locks the key, and can no longer > access anything outside the jail. Inside this depot, it defines a method > in which mailboxes can exist at both the root level and as children of > other mailboxes, and mailboxes can contain both emails and other > mailboxes. It does that in a way that is compliant with IMAP. The method, > structure, convention, is called IMAPdir. Yes, and that seems to make perfect sense. > If Evolution supports IMAPdir, then there will be no problem. :-) Actually, the problem is not really with evolution, because I would be more than happy to use Evolution via IMAP to localhost, in fact that was the main reason for me to start using Binc in the first place (well actually to replace Evolution with thunderbird), but the basic idea is the same. I think Evolution has become a confusing factor in this Q&A, since I am only using Evolutions local Maildir support (which seems to not be standards compliant) because I can not get offlineIMAP's Maildirs to work correctly with Binc ;-) So that returns me to the fact that the problem is with offlineIMAP, which I am not willing to give up on, so perhaps I will try and dig into the patch that Daniel suggested. > Because the IMAP protocol defines folders differently from UNIX, there's > no trivial way to have Binc IMAP support the UNIX folder structure for > mailboxes. Sadly! :-) No problem :-) cheers and thanks /tomas
