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 будет знать какое письмо не было доставлено.
Evelate, в POP3 нельзя делать более одного подключения одновременно. Либо перейдите на IMAP либо уменьшите интервал сбора писем и сделайте его разным (и лучше не целое количество минут) у разных клиентов. У The Bat! есть такая особенность, что он всегда проверяет почту в первую секунду минуты, поэтому несколько клиентов идет одновременно.
Evelate, тогда отключите пароли приложений (или оставьте включенным и сгенерируйте пароль приложения - это более безопасно) и проверьте настройки POP3 в The Bat! - подключение должно обязательно быть через SSL или TLS.
Evelate, тогда в https://passport.yandex.ru/profile проверьте, не включены ли пароли приложений или двухфакторная аутентификация, если что-то из этого включено - то сгенерируйте для The Bat! пароль приложения и используйте его для POP3/SMTP вместо основного пароля учетной записи.
