TopCrawler выполнен в виде классической Windows службы и предназначен для сбора и сортировки больших объемов писем с указанных ящиков. Основная идея проекта - использование SMTP в качестве универсального механизма обмена данными между различными службами. В настоящий момент реализованы функции, соберающие статистику по маркетинговым рассылкам: FBL отчеты, bounce письма, полезные письма.
Данный проект является частью внутреннего сервиса известной организации и может содержать в себе жесткие связи с другими узлами.
- Поддержка 3 типов писем: fbl, bounce, crm (полезные письма от клиентов).
- Поддержка плагинов для парсинга тела письма.
- Отправка основных показателей жизнедеятельности в Zabbix (тайминги доступа к ящикам, количество обработанных писем/ошибок).
- Возможность парсинга писем с вложениями.
- 2 режима работы: служба или консольное приложение.
- Запись RAW email в файловый архив.
- Остановка службы с сохранением промежуточных результатов.
Система сбора почты состоит из 2-х основных частей: БД для хранения категоризированных FBL отчетов и Bounce писем, DB API в виде набора хранимых процедур и сервисной части, выполняющей категоризацию, парсинг писем и запись результатов.
БД выполнена в виде плоского хранилища и содержит всего 3 таблицы: FBL, Bounce, BounceType и 4 процедуры, реализующие API доступа к таблицам.
Пример CRM базы в проекте отсутствует. Для полной работоспособности службы данную БД необходимо реализовать самостоятельно или переписать класс Crm.
Главный рабочий процесс службы выполнен в виде DataFlow конвейера и содержит в себе 7 блоков: блок первоначальной категоризации письма _sortMailDataBlock, 3 блока парсинга писем (_spamFilterDataBlock для crm писем, _checkBounceDataBlock и _identifyDataBlock для bounce писем), 3 блока записи результатов для различных категорий _addToCrmDataBlock, _addToBounceDataBlock, _addToFblDataBlock. Количество копий каждого блока (степень параллелизма) настраиваются в конфигурационной файле в специальной пользовательской секции DataFlowOptionsList и подбираются опытным путем под конкретную систему. Списки опрашиваемых ящиков также хранятся в конфигурационном файле в специальной секции CredentialsList.
После прочтения списка почтовых ящиков из настроек, служба забирает с них всю почту по POP3 (для каждого ящика в отдельном потоке.)
Использование простейшего протокола POP3 оправдано в данной ситуации, так как службе всего лишь требуется забрать всю почту с ящика как можно быстрее.
Каждый из ящиков имеет определенный тип (crm, fbl, bounce), таким образом категоризация сводится к определению типа ящика.
Данное ограничение не вызовет никаких проблем при правильной организации сервисных ящиков. Bounce письма должны падать на ряд ящиков, выделенных исключительно под эти цели с использованием служебного заголовка return-path. Ящики для FBL отчетов обычно указываются в личных кабинетах почтовых провайдеров, предоставляющих данную услугу. Для любой новой задачи (например синхронизация данных 2-х систем) можно выделить отдельный тип ящиков, что тоже будет неплохой практикой.
Все письма поступают в блок категоризации _sortMailDataBlock, а затем распределяются по блокам второго уровня в зависимости от типа ящика. FBL письма сразу записываются в БД блоком _addToFblDataBlock. CRM письма фильтруются на предмет спама блоком _spamFilterDataBlock, а затем записываются в БД блоком _addToCrmDataBlock. Bounce письма категоризируются по типам автоответов в блоке _checkBounceDataBlock, затем в тела письма находится адрес отправителя (не автора Bounce письма, а изначального адресата кому мы пытались отправить письмо) в блоке _identifyDataBlock, а результаты записываются в базу блоком _addToBounceDataBlock.
Правила парсинга писем блоками _checkBounceDataBlock и _identifyDataBlock реализованы в плагинах, подгружаемых в момент запуска службы. Для создания нового плагина (например нового правила парсинга) достаточно написать любой класс, реализующий интерфейс ICondition (для категоризации Bounce) или IIdentification (для нахождения отправителя).
Плагины по сути являются условиями, которые вычисляются для содержимого письма и проверка завершается на первом истинном условии. Таким образом "сложные" условия должны быть упакованы в "условие-обертку".