Инструмент для анализа журналов SMTP, который находит отказы

Question

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

Чтобы найти отказы, я анализирую файл журнала SMTP с помощью log parser.Журналы поступают с SMTP-сервера Microsoft.

Некоторые отскоки великолепны, например 550+#5.1.0+Address+rejected+user@domain.com.Есть user@domain.com в прыжке.

Но у некоторых нет электронной почты в сообщении об ошибке, например 550+No+such+recipient.

Я создал простой Ruby-скрипт, который анализирует журналы (использует log parser), чтобы определить, какая почта вызвала что-то вроде 550+No+such+recipient.

Я просто удивлен, что не смог найти инструмент, который это делает.Я нашел такие инструменты, как Zabbix и Splunk, для анализа журналов, но они выглядят излишеством для такой простой задачи.

Кто-нибудь знает инструмент, который анализировал бы журналы SMTP, находил отказы и электронные письма, которые их вызывают?

Answer 1

Это Статья это именно то, что вы ищете.Он основан на замечательном инструменте анализатор журналов.

Анализатор журналов - мощный, универсальный инструмент, обеспечивающий универсальный запрос доступ к текстовым данным, таким как файлы журналов , XML-файлы и CSV-файлы, а также к ключевым источникам данных на Операционная система Windows®, такая как Журнал событий, реестр, файловая система и Active Directory®.Вы сообщаете анализатору журналов, какая информация вам нужна и как вы хотите ее обработать.Результаты вашего запроса могут быть пользовательски отформатированы в виде текстовых выходных данных, или они могут быть сохранены для более специализированных целевых объектов, таких как SQL, системный журнал или диаграмма.Большинство программных средств предназначено для выполнения ограниченного числа конкретных задач.Анализатор журналов другой...количество способов, которыми его можно использовать, ограничено только потребностями и воображением пользователя. Мир - это ваша база данных с логом Синтаксический анализатор.

Answer 2

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

Мы используем следующую настройку для обнаружения и классифицировать все отскакивает после доставки в удаленный MTA.

1. Всем исходящим письмам присваивается уникальный заголовок обратного пути который при декодировании идентифицирует адрес электронной почты получателя и конкретное почтовое отправление.

2. Ан Апач Джеймс сервер, принимающий почту, возвращается на адрес обратного пути.

3. Пользовательская почтовая программа, разработанная на Java и выполняемая в Apache James, которая декодирует адрес to, отправляет текст электронного письма по адресу студия прыжков boogietools для классификации типа отказов, а затем сохраняет результаты в нашей базе данных.

Это работает очень, очень хорошо.Мы способны обнаруживать постоянные жесткие отказы и временные мягкие отказы, которые далее подразделяются на очень детализированные типы отказов, такие как отклонения от рассылки спама, ответы вне офиса и т.д.

Answer 3

Вы не хотите анализировать журналы, чтобы попытаться идентифицировать отскоки.У вас будут как ложноотрицательные, так и ложноположительные результаты, если вы просто посмотрите журналы.

Отскоки могут генерироваться ниже по потоку от сервера, на который вы осуществляете доставку.В журналах исходящих сообщений вашего сервера они будут выглядеть как успешные доставки.

Наивное соответствие шаблону для отскоков во входящих журналах (от нулевого отправителя на один из ваших верифицированных адресов) будет неточным.Есть несколько причин, почему:

• Будут появляться предупреждения о задержке, смешанные с реальными сообщениями о сбоях.
• Большинство автоответчиков вне офиса и подобных им используют нулевой отправитель для предотвращения синдрома боевых роботов.
• Аналогично, системы "запрос-ответ" (такие как * spit * boxbe.com), как правило, используют нулевой отправитель.
• Ваши ДОСТОВЕРНЫЕ адреса отправителей, если они являются постоянными для каждого получателя, будут перехвачены спамерами и вернутся либо в качестве целей для рассылки спама, либо в качестве обратного рассеяния.

Так что, к сожалению, единственный надежный способ сделать это - изучить сами сообщения об отказах.Большинство из них будут иметь MIME-часть "отчет / статус доставки" в соответствии с RFC1894, и в зависимости от выбранного вами языка, вероятно, существуют библиотеки или модули, помогающие с другими форматами отказов.Единственный, с которым у меня есть непосредственный опыт работы, - это модуль Perl Mail::DeliveryStatus::BounceParser, который работает достаточно хорошо.

Answer 4

Мне нравится LogParser.Когда мне нужно выполнить синтаксический анализ для чего-то очень специфичного или пользовательского или с использованием регулярных выражений, я использую biterScripting.На самом деле у них есть несколько примеров сценариев, которые я использовал для начала.Один из них находится в http://www.biterscripting.com/Download/SS_WebLogParser.txt.

Answer 5

Я основал программу счетчика отказов на этом посте, только чтобы позже выяснить, что этот метод на самом деле не работает для отправителей большого объема, потому что журналы SMTP расположены не в последовательном порядке.Подробнее об этом читайте в моем блоге.: Обнаружение отказов электронной почты в журналах SMTP и почему это невозможно.