У меня за много лет накопилось на сотни мегабайт почтовых баз (в формате The Bat!). Там почти исключительно небольшие текстовые сообщения, львиную долю объема которых составляют почтовые заголовки (описание путей доставки, отчеты антивирусов и прочая левая хрень). Удалив все это, можно и базу сжать в несколько раз, и во столько же раз ускорить поиск по ней.

Нетрудно написать на коленке приблуду, которая обработает экспорт в формате Unix Mailbox, а затем импортировать обратно, но опасаюсь допустить какую-нибудь мелкую ошибку в анализе/обработке формата, которая испортит отдельные письма или их части, а я этого заметить не сумею.

Может, уже есть ли что-нибудь готовое для удаления из почтовых заголовков всего, кроме From/To/Subject/Date?

Сто лет назад написал такое:

! /bin/sh

EXTRA_HEADERS=" Received: Message:\
 List-Id: List-Archive: List-Post: List-Help: List-Subscribe: List-Unsubscribe:\
 Return-Path: Errors-To: Reply-To: Delivered-To: Mail-Followup-To: Sender:\
 X-Envelope-To: X-BeenThere: X-Real-To:\
 X-Mailman-Version: Precedence: Organization: Status:\
 X-Spam: X-Spam-Level: X-Spam-Status: X-Spam-Checker-Version: X-Bogosity:\
 X-Scanner: X-Virus-Scanned: X-AntiVirus:\
 X-IP: X-Originating-IP:\
 X-Accept-Language:\
 X-From: X-Priority: X-MSMail-Priority: X-MimeOLE:\ 
 X-Enigmail-Version: X-Enigmail-Supports:\ 
 X-OriginalArrivalTime: 
 X-Operating-System: X-Window-System:"


FORMAIL_OPTIONS="-b -Y -f -d -s -e"
FORMAIL_HEADERS="$(echo "$EXTRA_HEADERS" | sed -e 's| | -I |g')"

for m in "$@"
do
        echo "Processing" $m "mailbox..."

        case $m in
            *.Z)        EXT=Z;;
            *.z)        EXT=z;;
            *.gz)       EXT=gz;;
            *.bz2)      EXT=bz2;;
        esac

        case $EXT in
            gz|Z|z)
                MBOX="$(basename $m .$EXT)"
                gunzip $m
                ;;
            bz2)
                MBOX="$(basename $m .bz2)"
                bunzip2 $m
                ;;
            *)
                MBOX="$m"
                ;;
        esac

        cat $MBOX | formail $FORMAIL_HEADERS $FORMAIL_OPTIONS | bzip2 -c > $MBOX.bz2
        rm -f $MBOX

        echo "Done!"
done

Здравствуйте, rising_edge, Вы писали:

_>Сто лет назад написал такое:

Вы в курсе, что поле в заголовке может располагаться на нескольких строках? А твой скрипт об этом в курсе?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Нетрудно написать на коленке приблуду, которая обработает экспорт в формате Unix Mailbox, а затем импортировать обратно, но опасаюсь допустить какую-нибудь мелкую ошибку в анализе/обработке формата, которая испортит отдельные письма или их части, а я этого заметить не сумею.

Я думаю, что если ты не будешь пытаться писать на коленке, собственно, парсинг почтового заголовка (он местами нетривиален), а возьмешь готовую, приверенную временем, библиотеку, то все остальное реально тривиально, и ошибиться особенно негде.

Здравствуйте, Pzz, Вы писали:

Pzz>возьмешь готовую, приверенную временем, библиотеку

Что для этого можно взять? Желательно под винду, чтоб не гонять файлы под линукс и обратно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Pzz, Вы писали:

Pzz>>возьмешь готовую, приверенную временем, библиотеку

ЕМ>Что для этого можно взять? Желательно под винду, чтоб не гонять файлы под линукс и обратно.

Vmime неплох и достаточно прост.

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>возьмешь готовую, приверенную временем, библиотеку

ЕМ>Что для этого можно взять? Желательно под винду, чтоб не гонять файлы под линукс и обратно.

Ну, если бы ты на Go писал, я бы ответил. А для C++ не знаю

Здравствуйте, Pzz, Вы писали:

Pzz>парсинг почтового заголовка (он местами нетривиален)

Кстати, а что нетривиального может быть в парсинге именно заголовка? Насколько я вижу, названия полей там чисто текстовые (они вроде как не должны кодироваться иначе, как в ANSI), а содержимое каждого парсить не требуется — его нужно либо оставить, либо удалить. Многострочные поля всегда начинаются с пробела на следующих строках.

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>парсинг почтового заголовка (он местами нетривиален)

ЕМ>Кстати, а что нетривиального может быть в парсинге именно заголовка? Насколько я вижу, названия полей там чисто текстовые (они вроде как не должны кодироваться иначе, как в ANSI), а содержимое каждого парсить не требуется — его нужно либо оставить, либо удалить. Многострочные поля всегда начинаются с пробела на следующих строках.

Много мелких нюансов, которые надо либо знать, либо уметь аккуратно вычитать из RFC. Например, как работает перенос строк в заголовке, чувствительность имен полей заголовка к регистру символов, значимы ли пробелы и где допустимы и т.д. и т.п.

Но в принципе, ничего такого *особо* хитрого там нет. Я такое писал, оно работало. Правильно ли оно обрабатывало всякие corner cases, сейчас уже сложно сказать.

P.S. Кстати, разбор HTTP заголовка тебе тоже пойдет, они совершенно одинаковые.

Здравствуйте, Pzz, Вы писали:

Pzz>Много мелких нюансов, которые надо либо знать, либо уметь аккуратно вычитать из RFC. Например, как работает перенос строк в заголовке, чувствительность имен полей заголовка к регистру символов, значимы ли пробелы и где допустимы и т.д. и т.п.

Это все имеет значение, когда нужно именно разобрать поля, получив их значения. А зачем все это знать, чтобы просто удалить ненужные? Для этого достаточно знать, где начинается и кончается каждое поле, не более того.

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Много мелких нюансов, которые надо либо знать, либо уметь аккуратно вычитать из RFC. Например, как работает перенос строк в заголовке, чувствительность имен полей заголовка к регистру символов, значимы ли пробелы и где допустимы и т.д. и т.п.

ЕМ>Это все имеет значение, когда нужно именно разобрать поля, получив их значения. А зачем все это знать, чтобы просто удалить ненужные? Для этого достаточно знать, где начинается и кончается каждое поле, не более того.

Ну еще надо уметь отличать нужные от ненужных.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну еще надо уметь отличать нужные от ненужных.

А что может быть нужно (исключительно для целей долговременного хранения), кроме From/To/Subject/Date?

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Ну еще надо уметь отличать нужные от ненужных.

ЕМ>А что может быть нужно (исключительно для целей долговременного хранения), кроме From/To/Subject/Date?

From может быть записан, как fRoM. И пробелы между From и двоеточием, кажется, тоже допускаются, и не являются значимыми, но я в этом не уверен, надо бы в RFC заглянуть.

Еще бы я сохранял, навскидку, Cc, Bcc, Reply-To, Return-Path, Content-Type, Sender, Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-Cc, Resent-Bcc, Message-Id, In-Reply-To, References, Resent-Message-Id.

В общем, RFC надо смотреть и много думать

Здравствуйте, Pzz, Вы писали:

Pzz>From может быть записан, как fRoM. И пробелы между From и двоеточием, кажется, тоже допускаются, и не являются значимыми

Да это все понятно, это мелочи.

Pzz>Еще бы я сохранял, навскидку, Cc, Bcc, Reply-To, Return-Path, Content-Type, Sender, Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-Cc, Resent-Bcc, Message-Id, In-Reply-To, References, Resent-Message-Id.

Зачем?

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Еще бы я сохранял, навскидку, Cc, Bcc, Reply-To, Return-Path, Content-Type, Sender, Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-Cc, Resent-Bcc, Message-Id, In-Reply-To, References, Resent-Message-Id.

ЕМ>Зачем?

Потому, что если есть поле Reply-To, то ответ посылается туда, а не на From, а где в этой картине мира находится Return-Path, я не помню, но где-то находится (см. RFC). А по полям, содержащим Message-Id, можно построить древообразное представление переписки (оно именно так и строится).

Это все полезная информация, нет смысла ее терять.

Здравствуйте, Pzz, Вы писали:

Pzz>Это все полезная информация, нет смысла ее терять.

Ну, разве что в плане сохранения альтернативных адресов корреспондентов, которые пишут с разных адресов и без подписей, искренне полагая, что их всегда опознают.

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Это все полезная информация, нет смысла ее терять.

ЕМ>Ну, разве что в плане сохранения альтернативных адресов корреспондентов, которые пишут с разных адресов и без подписей, искренне полагая, что их всегда опознают.

Так очень часто делают почтовые рассылки.

Здравствуйте, Pzz, Вы писали:

Pzz>Еще бы я сохранял, навскидку, Cc, Bcc, Reply-To, Return-Path, Content-Type, Sender, Resent-From, Resent-Sender, Resent-Date, Resent-To, Resent-Cc, Resent-Bcc, Message-Id, In-Reply-To, References, Resent-Message-Id.
Pzz>В общем, RFC надо смотреть и много думать

Много думать не стал — ограничился этим:

message-id, from, to, cc, bcc, subject, date,
content-disposition, content-id, content-language, content-length,
content-type, content-transfer-encoding, mime-version,
envelope-from, envelope-to,
reply-to, return-path, sender, delivered-to,
resent-message-id, resent-from, resent-sender, resent-date, resent-to, resent-cc, resent-bcc,
in-reply-to, mail-reply-to,
references, thread-index, thread-topic,

Все остальное выкидывается. Базы ужимаются более, чем вдвое (примерно 40% от исходного размера).

Здравствуйте, Pzz, Вы писали:

Pzz>Много мелких нюансов, которые надо либо знать, либо уметь аккуратно вычитать из RFC.

Занявшись обработкой своих баз, наткнулся на проблему, которой RFC не охватывает. В базе обнаружилось немало сообщений (достаточно старых), где первой строкой идет "From ..." — видать, какие-то кривые почтовики отправляли целиком запись из MailBox. Когда The Bat! экспортирует эти сообщения в формате UNIX Mailbox, он к этим строкам, как положено, добавляет префикс ">", и в секции заголовков появляется псевдо-заголовок без двоеточия:

From xxx@cameo.plala.or.jp Sat Apr 9 04:13:09 2005
>From xxx@cameo.plala.or.jp Fri Apr 8 14:12:53 2005
Received: from mvs1.plala.or.jp (c158129.vh.plala.or.jp [210.150.158.129])

По идее, такую хрень надо безжалостно выкидывать — в сообщениях последних лет этой лажи нет. Можно ли придумать какие-нибудь доводы за то, чтобы сохранять такие строки?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>По идее, такую хрень надо безжалостно выкидывать — в сообщениях последних лет этой лажи нет. Можно ли придумать какие-нибудь доводы за то, чтобы сохранять такие строки?

Это, если я не ошибаюсь, старый формат UNIX mailbox. Отличается именно по слову From без двоеточия в начале первой строки, после которого идет адрес. Сохраняется эта строка с целью сохранить envelope from, который не то же самое, что From: в заголовке письма.

Вероятно, более свежий Bat решил эту строку не сохранять (возможно, вставляет что-то вместо нее в заголовок письма).

P.S. Пусть Валентин Нечаев (netch80) меня поправит, если я ошибаюсь; он лучше помнит такие подробности.