[TriLUG] Solved: Squirrelmail - message count doesn't auto refresh on folders - firefox

[Aaron S. Joyner]

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