Short answer:
it's entirely possible that the cache will not be comprehensive. If you delete mail and hcache later recomputes the header cache for that mailbox, your stats will not include mail from before the deletion.
If you don't have access to the mail logs for your server, do you have access to a filter mechanism, e.g. procmail? You could use that to generate an alternative log for analysis.
Otherwise, can you poll your mailbox with a program that can generate a log of mail received? Something like an offlineimap filter, or fetchmail/retchmail combined with some hashing and caching.
Longer answer:
The cache file is a DBM-style database. Depending on the exact build options for your mutt, it could be one of QDBM, tokyo cabinet, gdbm or Berkeley DB (BDB); which all implement a variation of BDB's API.
I believe that it is unlikely you can reliably read the DB unless you use the right library implementation. ldd
tells me my local mutt uses the tokyo cabinet implementation:
$ ldd /usr/bin/mutt
…
libtokyocabinet.so.8 => /usr/lib/libtokyocabinet.so.8 (0xb74f2000)
…
You would then need to write a program, using that library, to query the BDB stored within the cache file. There are bindings for Perl, Ruby, Lua, Java, and of course C.
It would appear that headers are stored as values in the DB, indexed by a CRC. From what I can tell, the CRC is derived from the path to a mailbox, which implies that the stored headers are the headers for all mail in that mailbox. So your program is essentially going to end up with a buffer containing all headers for all mail in a given mailbox. I don't think it will be much more useful than pulling the headers from all mail currently in your mailbox (and given the "short answer" above, not guaranteed to be more reliable).
If you set the edit_headers
option to yes
, you can edit all the headers of a mail before sending, and you can set your own Date
header. A legitimate use for this is choosing your own timezone, or your own calendar.
Each server that your email passes through will add a Received
header containing the date at which it received the mail (or the date at which it deigned to process it). You can't fake these unless you have control of the server. More precisely, from the recipient's point of view, the headers are reliable starting with the last machine on the path that the recipient trusts.
A common reason for email delays is greylisting. It can be hard to predict whether a specific email will be greylisted, because the decision is partly based on a server's recent history with each sender. However, not all servers do greylisting, and the greylisting could add to your lateness anyway.
Of course, email can be delayed because of malfunction, ordinary maintenance, or general network flakiness. Email was designed to be extremely reliable but not necessarily fast (when it was invented, a lot of sites had no permanent network connection; email might be downloaded and uploaded once a day in some places). Nowadays, email isn't as reliable as it used to be, but it's often near-instantaneous. A delay can happen, but it's unusual.
If you don't know when your assignment is due, ask your instructor.
Best Answer
Unfortunately, the two possibilities suggested in the other answer were imperfect.
offlineimap
was fairly buggy at the best of times. For example, there is no way to automatically run a script after new mail arrives.fetchmail
doesn't synchronise bidirectionally.Instead, the solution that I ended up using was a combination of imapnotify and isync. I configured
imapnotify
to run a script when new mail is triggered (via IDLE).This script runs
mbsync "${channel}:INBOX"
depending on which account has mail. Next it runsnotmuch new
. Finally, it records the number of unread emails to a file as below. The contents of this file is displayed on a panel of my desktop environment.Update
imapnotify (nodejs-imapnotify) disconnects regularly with no warnings/errors, and often misses new mail. python-imapnotify also works intermittently. However, goimapnotify works very well in my experience. It rarely drops out, and when it does (e.g. because of network disconnects and/or suspend cycles), it quickly restarts itself without fuss.