Re: How to deal with new mail?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday, February 16 at 09:19 AM, quoth Benjamin Buch:
>> Hmmmm... and these are all local folders? The next task is to
>> figure out why mutt isn't seeing new mail in them. What sort of an
>> environment are we working with? Are these folders mbox's or
>> Maildir's? What sort of filesystem are they on? Are they on an NFS
>> share or a filesystem that's been mounted with the noatime option?
>
> Yes, they are all local folders within my maildirectory
> /home/benni/mail.
> Format is mbox, since it was the default format for procmail and
> mutt, so I thought I'll stick with it.
> I'm using (x)ubuntu linux, all is on my local filesystem which is
> ext3. I'm not quite sure about the noatime option, but mount -l
> gives me
>
> /dev/sda5 on / type ext3 (rw,errors=remount-ro) []
>
> , and I guess you would see it there if sda5 would be mounted with the
> noatime option?
Indeed.
> I checked the mailboxes manually, and they have access-times and
> modify-times that differ. Although the modify-times are far older as
> the access-times because I visited those mailboxes some times after
> they recieved new mail... but seems like everything is all right I
> guess.
Well, if these are old folders with new mail that have been read by
other email programs (in other words, if the access times are more
recent than the modify times), that would explain why mutt isn't
identifying them as containing "new" mail.
Just to make sure things are working, try touching one of these mboxes
to update the modify-time, like so:
touch -m ~/mail/lists
See if mutt doesn't recognize it as containing new mail then. If mutt
identifies it as containing new mail, then we have identified the
problem. If it doesn't... then either something else is reading the
mbox and updating the access-time, or mutt is broken.
> You're tempting me to switch to maildirs... ;-)
They do work quite well. :)
> For testing purposes, I did set mark_old=no. In this way I can keep
> new messages marked as new even if I visited the folder they're in.
> Right now, I can only tell if there's new mail in a mailbox by
> visiting that mailbox. If I did so with mark_old unset, the new
> mails would be marked as old mails after visiting, and I would have
> to wait until I would receive new mail or write some mail to myself
> which would be annoying after some times.
The way mutt handles mboxes with mark_old=no is that it prevents the
access time from changing, so that the mbox still appears to have new
mail in it. But if the access time is already more recent than the
modify time, then the mbox will stay as-is, and won't be identified as
having new mail in it. Does that make sense?
I think all you need to do to fix things is to first figure out which
mboxes have new mail, use `touch -m` to change their modify times so
that mutt thinks they have new mail, and as long as no other programs
are altering the timestamps (e.g. some other email client), then mutt
should continue to treat these mboxes correctly.
> macro index G "!fetchmail -k"
> macro pager G "!fetchmail -k"
For what it's worth, this probably should be done slightly
differently. First, you can combine them:
macro index,pager G "!fetchmail -k"
Then, instead of using the key-mapping for "execute program", call the
function directly:
macro index,pager G "<shell-escape>fetchmail -k<enter>"
That way, even if you later remap ! to something else, the macro will
continue to work without being updated.
>
> ##########################################
> # #
> # The following is a copy of /etc/Muttrc #
> # #
> ##########################################
> #
> # default list of header fields to weed when displaying
> ignore "from " received content- mime-version status x-status
> message-id
> ignore sender references return-path lines
> ignore date delivered-to precedence errors-to in-reply-to user-agent
> ignore x-loop x-sender x-mailer x-msmail-priority x-mimeole x-ms-
> x-priority
> ignore x-accept-language x-authentication-warning thread- priority
> importance
> ignore x-original-to domainkey-signature dkim-signature
This is also irrelevant to your stated problem, but you probably don't
want to just have an ever-growing list of headers to ignore. Instead,
do it the other way, and just list the headers you want to pay
attention to:
ignore *
unignore subject
unignore to
unignore cc
unignore from:
Hope that helps,
~Kyle
- --
University politics are vicious precisely because the stakes are so
small.
-- Henry Kissinger
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFHt4ptBkIOoMqOI14RAiAlAKCfZon1Fqd+mIMe9aa2lkcmGtNBmwCfZ13T
OEfTvlc+1N6j2S02Ns7Hd4k=
=zSpB
-----END PGP SIGNATURE-----