Здравствуйте.
Я являюсь администратором корпоративной почтовой системы, в которой, помимо нашей, хранится ещё почта некоторых наших клиентов. В один отвратительный день некоторые пользователи начали начали жаловаться мне, что вложения к ним приходят битые.
В системе используется SMTP-сервер Postfix в качестве MTA, и Cyrus IMAPd в качестве MDA. Postfix передаёт почту Cyrus при помощи LMTP, пользователи взаимодействуют с Cyrus по протоколу IMAP и POP3. Cyrus хранит почту в файловой системе, каждое письмо в отдельном файле, каждая IMAP-папка соответствует директории в системе; локализованные имена IMAP-папок кодируются по специальной схеме с UTF-7. Помимо писем, там хранятся база данных с правами доступа к папками IMAP, таблица с хешами писем для подавления двойной доставки, индексы для быстрого поиска почты, Sieve-скрипты. (Это всё позволяет получить содержимое писем без использования протоколов IMAP и POP3, например, через scp.)
У пользователей почта настроена по IMAP, т.е. отправленные письма, как и все остальные, хранятся на сервере.
Первое, что я обнаружил — это то, что когда пользователи пересылали друг другу письмо с вложением как вложение, то приходило оно в испорченном виде. Испорчено было именно внутреннее вложение.
При этом, то, что приходило (по протоколу SMTP+LMTP) получателю пересылки, и то, что попадало (по протоколу IMAP) в папку «отправленные» пересылавшего пользователя было испорчено совершенно одинаково, и отличалось между собой только заголовками Recieved в начале письма. В «Отправленных» заголовков не было, в том, что пришло ко мне, были заголовки, добавленные Postfix и Cyrus при приёме почты. Эти заголовки (путь письма Recieved, результаты проверки на спам X-Spam-Status и на вирусы X-Virus-Scanned) — следствие нормальной работы почтовой системы.
Поэтому я сделал вывод, что отправляемое письмо портилось один раз, почтовым клиентом, перед тем как ушло по SMTP и было положено в папку IMAP. Во всех случаях клиент был Thunberbird, но разных версий.
Второе, что я обнаружил — это то, что даже во входящей почты этих же пользователей некоторые вложения отображались как битые (когда их получли по IMAP), хотя на диске в хранилище Cyrus они были нормальные. Вытаскивание почты без использования IMAP и декодирование base64 позволяло получить нормальные, не битые вложения.
Таким образом, некоторая почта портилась ещё до попадания в почтовый клиент, при получении по протоколу IMAP.
В то же время, таких проблем в Linux не наблюдается. Проблема была заметна только у тех пользователей Thunderbird, которые пользовались Windows.
Заметили, что у одного из пользователей это началось практически сразу после установки DrWeb. Первая же проверка — отключение DrWeb — подтвердила догадку: Thunderbird начал принимать почту и пересылать её без любых искажений. Также проблема исчезала, если добавить Thunderbird в исключения DrWeb (там есть список приложений, которые он не трогает).
Более детальное исследование показало, что при отключении модуля эвристического анализа DrWeb также проблема исчезала.
Всё написанное выше касается версии DrWeb Security Space 5. Проверяли на самом доступном — на 30-дневной триальной версии, только что скачанной с их сайта:
Собственно, такой же баг-репорт ушёл и в DrWeb.
Я являюсь администратором корпоративной почтовой системы, в которой, помимо нашей, хранится ещё почта некоторых наших клиентов. В один отвратительный день некоторые пользователи начали начали жаловаться мне, что вложения к ним приходят битые.
Система
В системе используется SMTP-сервер Postfix в качестве MTA, и Cyrus IMAPd в качестве MDA. Postfix передаёт почту Cyrus при помощи LMTP, пользователи взаимодействуют с Cyrus по протоколу IMAP и POP3. Cyrus хранит почту в файловой системе, каждое письмо в отдельном файле, каждая IMAP-папка соответствует директории в системе; локализованные имена IMAP-папок кодируются по специальной схеме с UTF-7. Помимо писем, там хранятся база данных с правами доступа к папками IMAP, таблица с хешами писем для подавления двойной доставки, индексы для быстрого поиска почты, Sieve-скрипты. (Это всё позволяет получить содержимое писем без использования протоколов IMAP и POP3, например, через scp.)
У пользователей почта настроена по IMAP, т.е. отправленные письма, как и все остальные, хранятся на сервере.
Клиент
Первое, что я обнаружил — это то, что когда пользователи пересылали друг другу письмо с вложением как вложение, то приходило оно в испорченном виде. Испорчено было именно внутреннее вложение.
При этом, то, что приходило (по протоколу SMTP+LMTP) получателю пересылки, и то, что попадало (по протоколу IMAP) в папку «отправленные» пересылавшего пользователя было испорчено совершенно одинаково, и отличалось между собой только заголовками Recieved в начале письма. В «Отправленных» заголовков не было, в том, что пришло ко мне, были заголовки, добавленные Postfix и Cyrus при приёме почты. Эти заголовки (путь письма Recieved, результаты проверки на спам X-Spam-Status и на вирусы X-Virus-Scanned) — следствие нормальной работы почтовой системы.
Поэтому я сделал вывод, что отправляемое письмо портилось один раз, почтовым клиентом, перед тем как ушло по SMTP и было положено в папку IMAP. Во всех случаях клиент был Thunberbird, но разных версий.
Или сервер?
Второе, что я обнаружил — это то, что даже во входящей почты этих же пользователей некоторые вложения отображались как битые (когда их получли по IMAP), хотя на диске в хранилище Cyrus они были нормальные. Вытаскивание почты без использования IMAP и декодирование base64 позволяло получить нормальные, не битые вложения.
Таким образом, некоторая почта портилась ещё до попадания в почтовый клиент, при получении по протоколу IMAP.
Разгадка
В то же время, таких проблем в Linux не наблюдается. Проблема была заметна только у тех пользователей Thunderbird, которые пользовались Windows.
Заметили, что у одного из пользователей это началось практически сразу после установки DrWeb. Первая же проверка — отключение DrWeb — подтвердила догадку: Thunderbird начал принимать почту и пересылать её без любых искажений. Также проблема исчезала, если добавить Thunderbird в исключения DrWeb (там есть список приложений, которые он не трогает).
Более детальное исследование показало, что при отключении модуля эвристического анализа DrWeb также проблема исчезала.
DrWeb
Всё написанное выше касается версии DrWeb Security Space 5. Проверяли на самом доступном — на 30-дневной триальной версии, только что скачанной с их сайта:
SpIDer Agent for Windows
spideragent.exe (5.0.1.06018)
SpIDer Agent settings module for Windows
spideragent_set.exe (5.0.1.06018)
SpIDer Guard Service
spidernt.exe (5.00.1.04160)
SpIDer Guard UI Agent
spiderui.exe (5.00.1.04160)
SpIDer Guard Control Panel Applet
spidercpl.exe (5.00.1.04160)
SpIDer Guard File System Monitor
spider.sys (5.00.1.04160)
SpIDer Gate for Windows
spidergate.exe (5.0.2.07030)
SpIDer Gate for Windows settings module
spidergate_set.exe (5.0.2.07030)
SpIDer Mail for Windows Workstation
spiderml.exe (5.0.1.06300)
SpIDer Mail for Windows Workstation settings module
spml_set.exe (5.0.1.06300)
Dr.Web Winsock Provider Hook
drwebsp.dll (5.0.1.06040)
Dr.Web R Scanner for Windows
drweb32w.exe (5, 00, 4, 6300)
DWz
drwadins.exe (4.44)
VadeRetro Antispam & AV Filter
vrcpp.dll (01.284.57)
Dr.Web Update for Windows
drwebupw.exe (5.00.4.06300)
Dr.Web Shell Extension
drwsxtn.dll (5, 00, 0, 11280)
Dr.Web Helper
drwreg.exe (5.00.3.04060)
DrWeb Protection Library for Windows
dwprot.dll (5.0.6.04070 built by: WinDDK)
DrWeb Protection for Windows
dwprot.sys (5.0.6.04070 built by: WinDDK)
Dr.Web Scanning Engine
dwengine.exe (5.0.2.01210 (Build 2133))
Dr.Web Virus-Finding Engine
drweb32.dll (5, 00, 0, 12182)
Собственно, такой же баг-репорт ушёл и в DrWeb.
