Ho there, On Sunday, October 24 at 10:11 PM, quoth Enrico Weigelt: > > Well, just about any network filesystem can share a mailbox, and > > will work that way (NFS, AFS, Samba, AFP, etc.). > > No, this doesn't work for me: > > a) mbox locks are not really stable > b) too slow on large mbox'es > c) no locking of single mails > d) no active change-signalling (you just can check mtime and reread > the whole mailbox) 1) use Maildir instead of mbox: Maildir's were designed to be accessed by multiple clients at the same time, mboxes weren't. 2) what do you nead single-mail locking for? Do you edit your email? > I'm currently running several instances of mutt on one machine > (sharing via NFS makes trouble since locks are not really working here) Again: mbox was not designed for concurrent access. > Well, perhaps some of the existing protocols like IMAP or POP3 already > provide what I desire, but I just dont know it ... One thing that comes to mind... I don't know how gung-ho you are for writing your own code, but mail clients don't generally speak anything *but* IMAP4 and POP3. > My requirements are: > > * strong authentication + encryption w/ password and public key Strong authentication as in kerberos or as in a user/password combo. Why do you need this? (For example, if ssh-style authentication is acceptable, you can use ssh to tunnel IMAP/POP connections.) Most IMAP/POP implementations support encryption, as well. > * support for virtual hosting Most IMAP/POP implementations support virtual hosting. For example, both bincimap and courier imap servers work well with vpopmail's virtual host scheme (I use them). > * posting mails What do you mean? What's wrong with SMTP for sending mail? > * hierachical mailboxes IMAP's got you covered. > * single mail locking (for multiple access) If all you need is safe multiple-client access, then servers like CourierIMAP and BincIMAP both have you covered. Pretty much any IMAP server that uses Maildir as the backend will do it for you very well. > * fast header transfer (of the most-important headers) ... I'm not sure what you mean. > * mail part access ... I'm not sure what you mean here, either. > * searching and tagging, also over multiple mailboxes Why do you need protocol-level support for this? Apple's Mail.app, for example, has powerful cross-mailbox searching built on top of IMAP and POP. This seems like a client-side feature, not a protocol-level feature. > * mail uploading and moving between boxes IMAP's all over this one. > * compressed transfer Why do you need this? Technically, if you use ssh to tunnel your IMAP/POP connections, it can compress the connection for you, transparently. > * active change notification (s->c message when watched box or mail changed) Nope, no luck there. And frankly, outside of something custom, you're not going to get that. Given the bottleneck nature of the server-client model, you want as little state on the server as you can get away with. Having the server responsible for keeping track of clients that can go away without notice leaves too much state on the server, for the minimal gain of not having a polling client. Why is this a requirement? > Ideally a server for that supports: > > * virtual folders (or better: directories with multiple links) > * mounting of folders and an API for virtual folder backends. Again: too much state on the server. Good luck! > * multiple access and caching What server have you found that does not allow multiple access? What sort of caching are you looking for? I'm not trying to be particularly rude... I am really curious what situation you're confronting that has these requirements. ~Kyle -- And thou shalt smite the house of Ahab thy master, that I may avenge the blood of my servants the prophets, and the blood of all the servants of the LORD, at the hand of Jezebel. For the whole house of Ahab shall perish. -- Bible, II Kings (9:7-8)
Attachment:
signature.asc
Description: Digital signature