ASPLinux 9.2 В качестве МТА стоит Qmail в связке с vpopmail и DrWEB.
Почта вроде ходит нормально, но частенько при получении с моего POP3 писем почтовым клиентом OutlookExpress(другие не проверялись) вместо нормального почтового содержания приходит вот такая фигня...(см. пример ниже). Замечено что это происходит если письмо с MIME и с boundary, в том числе с вложением. При этом вложение представляется как обычный текст, а не как вложение. Если тоже письмо отправлено не на мой почтовик, а к примеру на mail.ru, то при получении его тем же почтовым клиентом письмо выглядит нормально и вложение вполне извлекаемо/читаемо....
Скорее всего проблема в моём MTA, а точнее в получении и обработке писем с MIME. Не подскажите где копать чтобы победить проблему?
-----------------------------------------------------------------------Вот так выглядят некоторые полученные письма:
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0042_01C43C1E.272AFA70"
------=_NextPart_001_0042_01C43C1E.272AFA70
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition:
=20=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD,=20
=FB=C1=C8=CF=D7 =ED=C9=C8=C1=C9=CC\=E6=CF=CB=C9=CE =
=F3=C5=D2=C7=C5=CA.=20
123001, =ED=CF=D3=CB=D7=C1,=20
=F0=F2=E9=B3=ED =EB=EC=E9=E5=EE=F4=EF=F7 - =
=ED=C1=CD=CF=CE=CF=D7=D3=CB=C9=CA =D0=C5=D2., =C4. 5, =D3=D4=D2. 1 =
(=F0=D5=DB=CB=C9=CE=D3=CB=C1=D1), =F4=C5=CC: 753-8050, 753-8950, =
105-6633, =E6=C1=CB=D3: 903-9168.и т.д.
> Скорее всего проблема в моём MTA, а точнее в
>получении и обработке писем с MIME. Не подскажите где копать чтобы
>победить проблему?абсолютно нормально для multipart они выглядят - просто
скорее всего DrWeb Content-Type изменяет или MIME-Version убирает
посмотри заголовки писем внимательно.
Мы наткнулись на такие-же грабли, и при разборе полетов выяснили, что это происходит в том случае, если АутГлюк неверно определяет MIME-тип файла и вместо base64 определяет его как quoted-printable, а после этого, когда до него добирается drweb, он то его и портит, поскольку "его мнение" о типе вложенного файла не совпадает с заявленным! Посему считаю, что глюк в почтовых клиентах.
P.S. Испытано на разных платформах и клиентах. Если Почтовый клиент ставит base64, приложение проходит "на ура"!
Я тоже уже разобрался с этой проблемой. Все дело оказалось не в АутГлюке, а в том, что 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,
>приложение проходит "на ура"!