> Okay, so back in the day, system mailboxes all lived in > /var/mail/whomever. Locking these things was an issue, /var was real > small on my BSD system, and on top of everything it meant having to > maintain two sets of quotas. > > So then, I modified my delivery agent (procmail in this case) to deliver > to ~/.mail.
My understanding is that the nature of a file is really only determined by the applications that access it. What makes the "system" mailboxes tricky is that applications like sendmail are relatively unsophisticated MDAs (when they're expected to do this job), and perhaps don't share the file with MUAs very well. It is also that sendmail might be doing the delivery which causes these to be regarded as "system" mailboxes, but really there's nothing inherently "system" about them. > Now, as I become more familiar with IMAP and whatnot, I'm beginning to be > of the realization that apparently your mail spool is only supposed to be > a "take things out on first sight" type of thing, which should be done > automatically by imapd if you have a special file called INBOX. > (http://www.faisal.com/docs/mbx.html) > > This breaks any familiarity I would have with things like using procmail > to deliver to ten different folders (since after all, what would be the > difference, they're *all* inbound folders that will be delivered to). All of this comes down to having healthy interaction between your MUA and MDA. The simplest way to achieve it is to simplify your MUA's access to the file(s) that your MDA write(s) to, and AFAICT the simplest access is "read-and-remove". If you have sufficiently friendly MDAs and MUAs, as is (probably) the case with procmail and pine, you don't have to do things that way. > I've been a pine whore for years, but it's been my understanding that pine > should also work that way in theory -- but for me it's not. When I move > things out of my .mail folder, they're "off the radar". Given, this is my > personal flow of work, but since pine only showed one folder at a time, I > wanted to be able to work within a reasonable timeframe (say, three > months) all without having to wait for pine to chunka-chunka-chunka > another folder open. Sorry, I didn't really follow that so I can't comment. > So, based on the above, is what I've been doing all these years "Wrong" by > the usual standards? "Wrong"? What's "wrong"? You don't want to lose mail, obviously; beyond that anything which enables you to work quickly and effectively is probably the best. > I ask all this in possible preparation for switching to a new mail format. > Most of my users are pop3 and imap types, and a lot of them complain about > the slow speed of squirrelmail (which seems to not work nicely with imapd > anyway (for which there are a multitude of alleged symptoms ranging from > the sorting to the locking to the format -- > http://www.squirrelmail.org/wiki/SpeedWithUW) Squirrelmail does not access any folders directly, so it should not be a factor in your choice of a file format. For your pop3 and imap users, pick pop3 and imap servers that work well, and the file format for remote folders will be both a consideration and a consequence of this decision. The format of local folders can be different, however. It depends on the MUA (and what MDA you may want delivering directly to them). If folders are being used both remotely and locally, you have to choose a format correspondingly, and my understanding is that this is one of the design goals of c-client's "native" formats. Sorry all that is so general, but I hope it helps. Cheers, - Joel _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
