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

[Matt Pusateri]

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