<<< Date Index >>>     <<< Thread Index >>>

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-----