Дмитрий: проверил, у меня доходит на оба ящика. Нет каких-то хитрых особенностей, типа того, что 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-папке.
Tian: попробуйте на mail.ru или gmail, они покажут причину фейла. Убедитесь, что DKIM-ключ опубликован как _domainkey.site.site.com (с селектором из s=), проверьте все, о чем говорилось ранее, и еще вы используете нормализацию simple для тела письма, при ней важны переводы строк, проверьте что используете правильные переводе (CR+LF) и они не трансформирутся в процессе передачи или поправьте нормализацию на relaxed/relaxed.
Mail.Ru формирует сообщение на основе стандарта DMARC (RFC 7489) с использованием технологий авторизации SPF (RFC 7208) и DKIM (RFC 6376) и сообщает о невозможности проверки отправителя, если авторизация отсутствует или не совпадает с доменом отправителя. Использование открытого стандарта прозрачно для всех сторон.
GMail формирует сообщение на основе принадлежности DKIM-подписи.
Оба сообщения, и GMail и Mail.Ru являются правильными и не противоречат друг другу. Гугл информирует о том, что письмо было отправлено через Яндекс, а не через Mail.Ru не делая выводов о возможности подделки отправителя. Мы информируем о том, что не можем проверить авторство письма и отправитель мог быть подделан, что справедливо при отправке письма от пользователя mail.ru через Яндекс. Здесь www.slideshare.net/phdays/ss-35165366 презентация с конференции PHDays с демонстрацией возможностей подделки отправителя при подобных проверках.
