Я тоже уже разобрался с этой проблемой. Все дело оказалось не в АутГлюке, а в том, что DrWEB после своей обработки письма, то ли специально, то ли по ошибке, в конце НЕКОТОРЫХ строк добавляет дополнительный символ x0D. То есть, вместо нормального окончания строки в ввиде CRLF (hex 0D0A), некоторые строки почему то заканчиваться на CRCRLF (hex 0D0D0A). И если такой последовательностью заканчивается строка-разделитель, то почтовый клиент ее не определяет и соответственно происходит ошибка в обработке MIME.
Лечится или пост-обработкой "больного" письма любым редактором типа UltraEdit. (Замена последовательности 0D0D0A на 0D0A) или, как рекомендует разработчик DrWEBа:
1. Покупка лицензии на DrWEB for Linux :-)
2. Поставить LocalScan = no в конфиге. (Я спросил у разработчиков не значит ли это, что не будет проверяться локальная почта. Их ответ: "Нет, не значит - локальная почта будет проверяться. Что проверяется не
зависит от этого параметра, это параметр лишь задает способ
взаимодействия между фильтром и демоном.")
>Мы наткнулись на такие-же грабли, и при разборе полетов выяснили, что это
>происходит в том случае, если АутГлюк неверно определяет MIME-тип файла и
>вместо base64 определяет его как quoted-printable, а после этого, когда до
>него добирается drweb, он то его и портит, поскольку "его мнение"
>о типе вложенного файла не совпадает с заявленным! Посему считаю, что
>глюк в почтовых клиентах.
>P.S. Испытано на разных платформах и клиентах. Если Почтовый клиент ставит base64,
>приложение проходит "на ура"!
|