Правило procmailrc для «in-reply-to Заголовок

Question

Попытка выяснить, как иметь правило .procmailrc, которое бросает всю почту, которая отвечает ранее увиденной почте. Использование Maildir, и хотел бы, чтобы правило охватывало сообщения в Cur/ или New/ ...

Должен ли я провести анализ Procmailrc все файлы? Или я должен иметь правило, которое извлекает заголовки идентификатора сообщения, сбрасывать их в файл и разрабатывать это?

Я не могу просто проверить и бросить что-либо с заголовком In-Reply, как будто это ответ на то, чего этот адрес еще не видел, его нужно принять.

Answer 1

Вам нужно собрать кэш из ID Message-ID: S из входящих сообщений:

:0c:
| formail -zxMessage-Id: >>msgid.txt

Затем проверьте в этом заново: против этого кеша (вероятно, ранее в вашем .procmailrc Таким образом, вы можете отфильтровать спам перед добавлением идентификатора сообщений в кеш);

:0
* ? formail -zxIn-Reply-To: | fgrep -f msgid.txt -
./whitelisted

Смотрите также примеры formail -D для сравнения. Возможно, вы могли бы массировать вещи в форму, где вы могли бы использовать formail -D в качестве заднего конца (замените идентификатор сообщения: с: перед добавлением в кэш; разделить вно-то, что: и выполните аналогичную замену на каждом идентификаторе сообщения). formail может поддерживать кэш LRU постоянного размера, тогда как fgrep Файл будет просто расти на неопределенный срок (хотя в этом случае, возможно, это именно то, что вы хотите).

Когда вы изначально настроили это, вы, вероятно, хотите собрать кэш из сообщений, которые у вас есть cur а также new Уже, но после этого вам не нужно снова обращаться к этим сообщениям из вашего рецепта. (Если ваш почтовый ящик-это что-то вроде моего, Grepping в реальном времени всего входящего ящика было бы довольно невозмутимым.)

Если вам нужен большой кеш, заменить файл простого текста SQLite или что-то в этом роде, вероятно, стоит изучить. На самом деле, к тому времени, когда правильная база данных действительно стоит усилий, вам может понадобиться реальная база данных, а не SQLite, но у меня есть только расплывчатые идеи о масштабируемости различных двигателей баз данных для такого рода вещей и никакого практического опыта.

Обратите внимание, что, если у вас нет необычной настройки-ваш исходящий идентификатор сообщений: S не будет добавлен в кэш; Чтобы это было на самом деле полезно, возможно, вы должны договориться о том, чтобы это произошло как-то, и/или установить шаблон, который соответствует вашему исходящему идентификатору сообщения: S (в идеале без ложных срабатываний и, конечно, нет ложных отрицательных. Если вы переключили MUAS В прошлом вы, возможно, должны искать шаблоны для ваших старых сообщений отдельно, если вы хотите полного покрытия).

Осторожность: непроверенный, и я, наверное, довольно ржавый.