Короткий ответ:
Вполне возможно, что кэш не будет полным. Если вы удалите почту, а hcache позже пересчитает кеш заголовка для этого почтового ящика, ваша статистика не будет включать почту до удаления.
Если у вас нет доступа к почтовым журналам вашего сервера, есть ли у вас доступ к механизму фильтрации, например, к procmail? Вы можете использовать это для создания альтернативного журнала для анализа.
В противном случае, вы можете опросить свой почтовый ящик с программой, которая может генерировать журнал полученной почты? Что-то вроде фильтра оффлайн-карты или fetchmail / retchmail в сочетании с некоторым хэшированием и кэшированием.
Более длинный ответ:
Кеш-файл представляет собой базу данных в стиле DBM. В зависимости от точных опций сборки для вашего дурака, это может быть один из QDBM , токийский кабинет , gdbm или Berkeley DB (BDB); которые все реализуют вариант API BDB.
Я считаю, что маловероятно, что вы сможете надежно читать БД, если не используете правильную реализацию библиотеки. ldd
говорит мне, что мой местный дурак использует реализацию кабинета Токио:
$ ldd /usr/bin/mutt
…
libtokyocabinet.so.8 => /usr/lib/libtokyocabinet.so.8 (0xb74f2000)
…
Затем вам потребуется написать программу, используя эту библиотеку, для запроса BDB, хранящегося в файле кэша. Есть привязки для Perl, Ruby, Lua, Java и, конечно, C.
Похоже, что заголовки хранятся в виде значений в БД, проиндексированных с помощью CRC. Из того, что я могу сказать, CRC получен из пути к почтовому ящику, который подразумевает, что сохраненные заголовки являются заголовками для всей почты в этом почтовом ящике . Таким образом, ваша программа в конечном итоге получит буфер, содержащий все заголовки для всей почты в данном почтовом ящике. Я не думаю, что это будет гораздо полезнее, чем извлекать заголовки из всех писем, которые в данный момент находятся в вашем почтовом ящике (и, учитывая «краткий ответ» выше, гарантированно не будет более надежным).