Имеется ввиду клиент инициируется 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.
И смотрите в чем именно у вас затык - письма медленно спулятся из вашего приложения или медленно отправляются из очереди? Если медленно спулятся - так наверное вы их спулите в один поток, распараллеливайте именно постановку писем в очередь.
Я обычно запускаю что надо через 3proxy
system "notepad.exe"
в 3proxy.cfg и
3proxy --install