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

Question

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

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

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

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

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

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

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

Answer 1

article - это именно то, что вы ищете. Он основан на отличном инструменте log parser.

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

Answer 2

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

Answer 3

Я основал программу счетчика отказов на этом посту, только чтобы узнать позже, что этот метод фактически не работает для отправителей большого объема, потому что журналы SMTP не находятся в последовательном порядке. Об этом в своем блоге: Email Bounce Detection in SMTP Logs and Why It Is Impossible.

Answer 4

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

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

1. Все исходящие письма дают unique return-path header, которые при декодировании, идентифицирует адрес электронной почты получателя и конкретной рассылки.

2. Apache James сервер, который получает почту, возвращенную на адрес возвращенного пути.

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

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

Answer 5

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

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

Наивное соответствие шаблона для отскоков в входящих журналах (от нулевого отправителя до одного из ваших адресов VERP-ed) будет неточным. Существует несколько причин:

• Будут предупреждения о задержках, смешанные с фактическими отказами отказов.
• Большинство внешних и других автоответчиков используют нулевого отправителя для предотвращения синдрома баттлин-ботов.
• Аналогично, системы с запросом-ответом (например, * spit * boxbe.com) имеют тенденцию использовать нулевой отправитель.
• Ваши адреса отправителя VERP-ed, если они постоянны для каждого получателя, будут собираться спамерами и возвращаться как цели спама, так и обратное рассеяние.

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