bohdanNa,
Вам все расписали же: основная проблема - это наличие некодированных 8-битных символов в теме письма. Это делает письмо некорректным, особенно если кодировка отличается от UTF-8.
Вторая проблема - отсутствие альтернативной текстовой части.
Ну еще у вас в HTML части отсутствует HTML.
Но еще раз, даже если вы все приведете в порядок, это не гарантирует вам доставку писем. Чтобы письма доставлялись, необходимо не только стандартам соответствовать, нужны хорошие репутационные оценки для вашего домена, а для этого надо чтобы письма были нужны получателям.
Wish01, тогда возможно так влияет именно DKIM Signer, зачем-то декодирует заголовки или блокирует их кодирование. Попробуйте пустить письмо мимо него, если оно придет с кодированными заголовками - то действительно баг в нем.
Wish01, тогда могу честно признаться, что не знаю как вы добились такого результата. В дефолтных конфигурациях Exchange всегда корректно кодирует заголовки. Чем именно его можно так поломать - не знаю.
Можно было бы подумать, что причина в SMTPUTF8, точнее RFC 6532, но Exchange его не поддерживает.
Content-Type надо указывать в заголовках парта. Опубликуйте где-нибудь EML, без этого можно только гадать, но скорей всего - да, неправильно указан или не указан Content-Type.
Евгений Матвеев, так вы не уложитесь в ограничение на запрос 10 записей.
Если есть возможность прописать IP адреса серверов - не надо ничем другим усложнять политику. Посмотрите, например, политики крупных почтовых сервисов.
astrotrain , при таких мавзолеях версией glibc вы не отделаетесь. Да, лучше собрать под старой системой, но если зверинец большой, то скорей всего придется делать несколько разных сборок.
Coffin, тогда именно queue_run_max и смотрите почему не получается запустить большое количество обработчиков очередей, это может быть из-за ulimit'ов на файлы или процессы. ulimit на файлы должен быть как минимум вдвое больше queue_run_max, ulimit на процессы - больше queue_run_max.
И смотрите в чем именно у вас затык - письма медленно спулятся из вашего приложения или медленно отправляются из очереди? Если медленно спулятся - так наверное вы их спулите в один поток, распараллеливайте именно постановку писем в очередь.
astrotrain, а вы уверены, что у вас только версии библиотек не совпадают? Вы можете использовать инструкции, которые поддерживаются на вашей машине и не поддерживаются на другой. В целом, создать бинарник, который будет работать во всех дистрибутивах линукс - это практически нерешаемая проблема, как минимум, обычно рекомендуют как минимум использовать два билда для более старых и более новых систем.
Например тут: stevehanov.ca/blog/index.php?id=97
1. "От" это скорее всего заголовок From. Посмотрите документацию по этому приложению, я не имею представления какое поле чему в нем соответствует, русские наименования неочевидны.
2. Если вы принимаете почту для своего домена на собственный сервер, значит у вас совершенно точно есть MTA.
1. Это не заголовок, это адрес отправителя SMTP-конверта (envelope-from, smtp.mailfrom). Тот адрес отправителя, который указывается в команде MAIL FROM в SMTP, в заголовках он может вообще отсутствовать. В заголовок Return-Path его заносит сервер получателя.
2. MTA - Mail Transfer Agent, почтовый сервер обрабатывающий вашу почту - exim, sendmail, postfix и т.д.
3. Если вы будете складывать баунсы в один ящик то получите то, что имеете сейчас, что >40% баунсов нестандартизированы и даже у одного отправителя их формат и текстовки могут меняться, обработать их сложно, а обработать все - невозможно в принципе, т.к. вы не можете определить на какое письмо а иногда и на какой адрес получателя пришел баунс. На некоторые письма может приходить более одного баунса (например несколько баунсов на то, что письмо задержано а потом еще один на то, что оно не доставлено).
Влад, я не знаю что значит "типичная программа" и что она умеет. Службы типа GetResponse/MailChimp умеют это делать (определять статус доставки письма) "из коробки". Если вы все расссылаете и контролируете сами, то заводите домен, например delivery.example.com. Во From: письма пишете что-нибудь стандартное, например support@example.com, но в SMTP-конверте для каждого отправленного письма генерируете some-random-id@delivery.example.com и заносите информацию об отправленном письме вместе с some-random-id в базу. В MTA для delivery.example.com прописываете скрипт локальной доставки (MDA) или транспорт, который будет обрабатывать входящие письма и факт получения письма и тип полученного письма (NDR, автоответ и т.п.) на some-random-id@delivery.example.com записывать в базу по some-random-id. Если, например, на 5 последовательно отправленных писем одному пользователю получены NDRы - отписывать пользователя. Складывать NDRы в ящик смысла нет, т.к. у пользователей могут быть перенаправления и очень часто сложно определить на какое письмо пришел NDR, если вы не делаете как описано выше.
Вот например заголовки письма от LinkedIn (у других крупных отправителей найдете ровно то же самое):
m-9qwr1a55jomejxn16ltjll33dawbmkfx8539wl7l742i1m4to7yx6ihg9k****@bounce.linkedin.com в данном случае сгенерированный уникальный адрес, если бы письмо не было доставлено - NDR придет на него и LinkedIn будет знать какое письмо не было доставлено.
Вам все расписали же: основная проблема - это наличие некодированных 8-битных символов в теме письма. Это делает письмо некорректным, особенно если кодировка отличается от UTF-8.
Вторая проблема - отсутствие альтернативной текстовой части.
Ну еще у вас в HTML части отсутствует HTML.
Но еще раз, даже если вы все приведете в порядок, это не гарантирует вам доставку писем. Чтобы письма доставлялись, необходимо не только стандартам соответствовать, нужны хорошие репутационные оценки для вашего домена, а для этого надо чтобы письма были нужны получателям.