On Tue, September 28, 2004 8:54 am, Aaron S. Joyner said: > Jason Tower wrote: > >>On Monday 27 September 2004 22:32, Matt Pusateri wrote: >> >> >>>FreeBSD 5.3Beta3 >>>Squirrelmail 1.4.3a - compiled from ports >>>PHP4.3.8 with openssl statically compiled - also from ports >>>UW-IMAP2004d. - from ports >>>Firefox 1.0PR on W2K >>>IE 5.5SP4 on W2K >>> >>> >>you might also get around this by delivering mail directly to the >>"correct" location, rather than /var/log/mail. slap something like >>this in the beginning of /etc/procmailrc: >> >> DEFAULT=$HOME/Maildir/ >> >>i use courier and maildirs, if you're running uw-imap it will be >>slightly different. >> > You left out a crucial detail. You did not describe which MTA you are > using (sendmail, postfix, exim, qmail...). With out knowing that, we > can only make even less-educated guesses about your local delivery > agent > - which is where the problem really is. As Jason suggests, if you're > running Sendmail, you need to reconfig Procmail (the local delivery > agent commonly used with Sendmail) to drop mail in the appropriate > final > destination. Alternatively, you could discount that secondary > destination and prevent UW-IMAP from shoveling mail over to the ~/mbox > directory. I don't use UW on a daily basis so proper configuration > for > that is left as an exercise for the reader. Either way, the missing > piece of the puzzle is the local delivery agent, which needs to agree > with where UW-IMAP thinks mail should end up. > > To quickly respond to Jason's concerns over the placement of mail, > there > are two simple reasons why the historical /var/spool/mail tradition is > still in use. The first (and still most valid) reason boils down to > disk access times. Mail is written to your mailbox far more often > than > you read mail from it (at least for most people :) ). When the mail > is > received by the MTA, it's spooled somewhere on the /var file system. > It's relatively safe to assume that the temp spool directory > (/var/spool/mqueue (or clientmqueue)) will reside on the same > partition, > or at least the same physical machine, as /var/spool/mail. There-by, > it's unlikely that you're going to have to open and write to a file on > a > network share to copy that file into place. On the other hand, home > directories tend to be located in all kinds of obscure places, often > over NFS mounts from the receiving mail server, or other unusual > chicanery. The other reason dates back a bit farther, and is some > what > less valid these days. In a large multi-user system, you ideally > don't > want one piece of mail (or one user getting lots of mail) to fill a > file > system and cause problems. Traditionally, before the days of user > quotas and other niceties, the best you could do was limit that to a > file system that would minimize the damage to the overall system. If > all new mail gets dropped in /var/spool/mail -- and as a result the > /var > partition fills up, hopefully it won't prevent you from logging in, > writing files to your home directory, or other critical tasks that > would > grind many more services than just mail to a halt (You did make /var a > separate partition from the rest of the system, didn't you?...). In > the > modern days of quotas, and MTAs that will return temporary errors due > to > users being over quota, the risk of running out of disk space can be > mitigated in other ways. But it's still a nice safe-guard for those > eventualities like when you upgrade a machine and forget to include > quota support in the kernel... and don't notice for a few months > (don't > laugh too hard, I had that happen recently). :) > > So that's our mail-spool-location history lesson for the day. > Hopefully > at least a few people will read it and enjoy it. :) If anyone else > knows of any other obvious reasons (or even not-so-obvious ones) that > I've over looked, feel free to chime in. I'm by no means > authoritative > on history. > > Aaron S. Joyner > -- Filling in the missing piece of the puzzle: Sendmail 8.13.1. Also procmail is not installed by default on FreeBSD. This domain only has two users, and I really have never needed the features of procmail. Of course running sendmail doesn't bother me either, so maybe I'm just indifferent.
Aaron, thanks for the history lesson. I don't mind mail going to /var/mail/. Does anyone have a good technical reason to deliver all mail to ~ besides that all mail for each user is in one place. I am looking for more of an answer than personal preference. Sending new mail to /var/mail or /var/spool/mqueue or /var/spool/clientmqueue seems to be the defacto sendmail way of doign things. So if I am willing to run sendmail, then what techincal reason can someone give me to change the default way it does things? Thanks, Matt -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
