Jason Tower wrote:
On Monday 27 September 2004 22:32, Matt Pusateri wrote: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.
FreeBSD 5.3Beta3you 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:
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
DEFAULT=$HOME/Maildir/
i use courier and maildirs, if you're running uw-imap it will be slightly different.
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 -- 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
