Имеется ввиду клиент инициируется TLS соединение. Кто и как при этом устанавливал соединение на транспортном уровне не важно, вы можете назначать в паре клиента и сервер исходя из любых соображений, лишь бы они об этом знали.
А что вы имеете ввиду под C2C? У вас все равно есть кто-то, кто инициирует соединение, с точки зрения TLS он является клиентом, если необходима взаимная авторизация - используйте TLS с клиентским и серверным сертифкатом, заранее обменявшись их фингерпринтами.
Этот совет во-первых неправильный, т.к. указывать надо "a" запись из другого домена, а во-вторых вредный, т.к. много всего инклюдить и использовать конструкцию mx не стоит из-за ограничений на число разрешний имен. Подробно расписано здесь:
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% баунсов нестандартизированы и даже у одного отправителя их формат и текстовки могут меняться, обработать их сложно, а обработать все - невозможно в принципе, т.к. вы не можете определить на какое письмо а иногда и на какой адрес получателя пришел баунс. На некоторые письма может приходить более одного баунса (например несколько баунсов на то, что письмо задержано а потом еще один на то, что оно не доставлено).
