У вас PTR-записи нет
>host 188.227.74.16
Host 16.74.227.188.in-addr.arpa. not found: 3(NXDOMAIN)
обратитесь к хостеру, чтобы для прописали PTR в server1.artofbiz.ru
icsy: по IP-адресу да, через whois или обратное разрешение, но не глядя в результаты запроса к вашей зоне. По заголовкам отправленного письма тоже будет понятно, что оно отправлено с pdd.
Не могу сказать именно про рендеринг, но в целом ориентируетесь на следующее: если задача или запрос плохо параллелится и при этом выполняется малое количество задач одновременно и в ближайшие 5 лет это не изменится - используйте одну максимально мощную машину.
Если задача плохо параллелится, есть жесткие ограничения по времени выполнения задачи или запроса и прямо сейчас или в ближайшем будущем планируете выполнение нескольких задач одновременно - стройте кластер из мощных машин.
Если задача хорошо параллелится или нет ограничений по времени, но при этом идет большое количество задач одновременно - стройте кластер или ферму на недорогом железе с хорошим показателем эффективности энергопотребления (потребления энергии на единицу вычисления).
Дмитрий: проверил, у меня доходит на оба ящика. Нет каких-то хитрых особенностей, типа того, что mail1 от mail2 отличается только регистром символов, например? Или, возможно, когда-то регистрировали домен на pdd.yandex.ru?
Received: by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 1KJiF8h9Lr-AoLKl8SV;
Thu, 4 Feb 2016 16:10:50 +0300
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client certificate not present)
это означает, что ты отправляешь на Яндекс через SMTP, и SMTP-конверт формирует твоя почтовая программа. Убедись, что на уровне конверта (envelope-to) ты передаешь двух получателей, а не одного. Яндекс НЕ смотрит в заголовок To, он ему фиолетов.
Роман: так я вроде бы и ответил - если вы не устанавливали корневой сертификат провайдера и браузер не показывает нарушений в протоколе https:// - значит провайдер не может дешифровать трафик.
ChymeNik: про Windows не уверен как именно работает нулевой лингер, но точно могу сказать что коннекты в time-wait / fin-wait там ни к каким негативным последствиям, типа невозможности рестартануть сервис и слушать тот же порт, не приводят.
Если у вас BSD, то, скорей всего, это не лечится, чтобы избежать проблем при повторном запуске демона/открытии порта используйте SO_REUSEADDR / SO_REUSEPORT. Если Linux, то это странно, потому что при нулевом лингере по идее должен идти RESET, а не закрытие сокета через FIN. Попробуйте устанавливать лингер при создании сокета. Возможно вы пропустили какие-то ситуации закрытия сокета, например когда закрытие соединения инициируется другой стороной.
+ если у вас протокол с долго живущими соединениями, которые могут подолгу простаивать без передачи данных, не забывайте использовать SO_KEEPALIVE, иначе клиенты за NAT'ом могут отваливаться втихую, что и приводит к многочисленным fin-wait'ам.
Eddik: нет, ничего не могу сказать. Но в целом, чем больше уровней вы накрутите - тем меньше будет выигрыш, т.к. фактически придете к тому же самому функционалу, что реализован в ядре и вряд ли он будет сильно быстрей работать. Если поверх юзерспейс-стека вы поднимете, например, интерфейс для быстрого сетевого аналога мемкеша - то есть шанс, что-то выиграете. А если накрутите веб-сервер со скриптами - то вряд ли заметите разницу. Возможно вам надо смотреть не в сторону kernel bypass, а наоборот унести что-то в ядро, например через sendfile() / splice().
Василий Печерский: вот пример конфигурации нескольких пулов адресов с модулем rlm_ippool wiki.freeradius.org/modules/Rlm_ippool
там же в комментарии сверху пример что в каком файле прописать, чтобы одной группе пользователей назначались адреса из одного пула, а другой из другого.
Аналогичная проблема так же может быть с черновиками, проверьте что черновики настроены правильны и что яндекс не собирает черновики во входящие. Если собирает - можно отключить хранение копии черновика в IMAP-папке.
