teub74: если у вас, например, один из двух серверов зоны дает ошибку, то вероятность успешного получения записи 50%. Такая же вероятность что Yandex при очередной проверке увидит, что вы добавили DKIM-запись.
Получите DKIM-запись со всех ваших серверов зон и сравните ее с DKIM-записью полученной с dns1.yandex.ru.
Во-первых, вы не генерируете Message-ID, поэтому его добавляет SMTP-сервер, а по стандарту должен генерировать MUA (т.е. в данном случае вы). Обычно этот заголовок в списке обязательных для подписи, поэтому это может создавать проблемы.
Во-вторых - вам google пишет
error in processing during lookup of accounts@example.com: DNS error
т.е. у вас проблемы с DNS-сервером, из-за этого может и DKIM-запись не видна Яндексу.
teub74: будет гораздо проще если все-таки показать заголовки письма. Возможно вы формируете неправильный адрес отправителя в SMTP-конверте (envelope-from, обычно можно посмотреть в поле Return-Path или по заголовкам Received). Убедитесь, что он совпадает с адресом From.
teub74: если вы отправляете письмо через smtp.yandex.ru с логином и паролем- то подпись будет делать он. Через что вы отправляете - через почтовую программу или через postfix не важно. Можете попробовать отправить через почтовую программу.
есть такой нюанс - DKIM может не накладываться, если письма не соответствуют стандартам. Проверьте, нет ли у вас, например, 8-битных символов в заголовках, правильно ли сформирован From, есть ли Date и Message-ID.
Константин Степанов: так вот, это не утечки от mail.ru, yandex и gmail. Это взяты 100500 разных баз: поломанных сайтов на разных популярных движках + базы LinedIn + базы скомпрометированных эккаунтов (через брутфорс, троянцы и т.п.) и скомпилированы в одну базу, из которой взяты емейлы и пароли и поделены по разным почтовым службам. Если у вас пароль ранее был сбручен, угнан трояном или вы его использовали на каком-то левом сайте - да, он будет в этой базе.
Константин Степанов: утечек паролей напрямую от Яндекса или Mail.Ru не было. Если ваш пароль был в базе эккаунтов, это значит что он либо легко брутился (например словарный пароль или дата рождения с инициалами) либо вы вводили при регистрации где-то адрес e-mail и пароль, совпадающий с паролем от этого e-mail.
тут может быть все, что угодно - плохо обжатый кабель, loop в сети, неправильный MTU привоодящий к jumbo frame'ам, коллизия в hash-таблицах свича, ограничение на ARP в коммутаторе / port security.
В SOCKS запрос от клиента может придти по имени или по адресу. Если в запросе приходит адрес (IPv4 или IPv6) - прокси будет использовать ровно тот протокол, который запросил клиент. Поведение -46 или -64 влияет только на запросы по имени хоста. Соответственно, чтобы прокси выбирал протокол, надо чтобы клиент в запросе передавал не адрес, а имя.
Включите логгирование в прокси, посмотрите что приходит в запросах.
В чем это заключается? Сбербанк открывается и работает нормально через socks5.
например, в невозможности использовать аутентификацию в SOCKS.
Евгений Матвеев: если бы у вас обе подписи были валидны - это не создало бы проблем. Но у вас одна невалидна и как минимум exim в таком случае валидирует DKIM неадекватно.
MrAloof:
это пример. Я не думаю, что это сделано специально для Украины. Но вообще, если я не в юрисдикции данного государства, мне несколько плевать на его законные решения, ограничивающие мою деятельность, если моя деятельность не нарушает международное право.
2. Просто сменить/добавить IP адреса у ns1 и ns2 - и обновление произойдет быстрее чем добавление в зону еще одного ns
И добавление в зону еще одного NS и смена имеющихся NS в зоне может занимать до 6 часов в зоне .ru. Но для ns9.z5h64q92x9.net этого не требуется, достаточно поменять A-запись, что может быть сделано за время TTL (15 минут и может быть понижено при желании).
Yura Khlyan:
вы, скорей всего, вставляете картинку в multipart/mixed часть. А она должна быть в multipart/related
структура письма должна быть такой
если имеется плейнтекстовая часть:
multipart/mixed
+multipart/alternative
++text/plain
++multipart/related
+++text/html
+++image/jpeg - лого
(конец multipart/related)
(конец multipart/alternative)
+text/csv
+application/pdf
(конец multipart/mixed)
если плейнтекстовая часть отсутствует, то multipart/alternative не нужен:
Посмотрите заголовки всех категорий писем, что у вас есть и посмотрите с какого IP они получены. Учитывайте только те Received в которых есть via SMTP, ESMTP, ESMTPS.
Получите DKIM-запись со всех ваших серверов зон и сравните ее с DKIM-записью полученной с dns1.yandex.ru.