datarmatan, это неправильный вопрос, на него невозможно ответить, можно ответить на вопрос годится ли он для ваших целей. В целом, вы можете считать, что стоимость непосредственной атаки на "классический" https это порядка 100000 долларов, т.е. они доступны всем крупным игрокам и правительственным агентствам + https не защищен на MitM к серверу, т.е. вас может атаковать ваш хостер или провайдер или канальный оператор. В большинстве случаев это достаточный уровень защиты, т.к. хостер может вам что-то внедрить непосредственно на сервер, и наверняка имеются более "дешевые" способы атак для других сторон, например вынести ваш сервер по поддельным документам.
А если вы реализуете свой клиент с самоподписанным сертификатом и пиннингом (или сделаете соответствующую конфигурацию, например, Firefox убрав в ней доверие ко всем сертификатам кроме вашего) и уберете на серверной стороне все лишние cyphersuit'ы (оставите, например, ECDHE-ECDSA-AES256-GCM-SHA384 или ECDHE-ECDSA-CHACHA20-POLY1305 если не верите правительственным агентствам), то получите весьма надежную в плане криптографии конфигурацию.
Это очень плохой совет. Никогда не используйте свои алгоритмы шифрования и даже свои реализации чужих алгоритмов шифрования, используйте общепринятые подходы и стандартные библиотеки, разработанные именно для ваших целей, т.к. даже самый надежный криптоалгоритм можно неправильно реализовать и неправильно использовать.
Антон Золотарев, скорей всего это как раз Return Path Domains. У вас сейчас в адресе SMTP-конверта (его же обычно называют Return-Path)
bounce-md_31048554.5b6d87d8.v1-f74b6b8ee64a4e8b868a7b5f2a584b1d@mandrillapp.com
а чтобы проходил SPF-DMARC надо чтобы там был ваш поддомен.
Там нужно не верификацию проходить, скрей всего там нужно сделать CNAME запись на mandrillapp.com, почитайте документацию, я не работал с Mandrill.
Иван, это был пример, и это обновление под Windows 2008R2, для других версий Windows может быть другая версия KB. Посмотрите не прилетали ли обновления в момент когда начались проблемы.
Вячеслав Грачунов, где именно идет перехват не известно, это может быть и между клиентом и прокси и между прокси и сервером, второе несколько вероятней.
GADARUKU, для контент-фильтров - да, по крайней мере на практике он чаще всего используется.
Если контент не нужен, только параметры клиента - то обычно используется протокол policy.
Евгений Матвеев, не может быть двух редиректов в одной spf-записи, может быть два include.
Если вам надо 20 серверов - перечисляйте 20 ip4, в чем проблема? ip4 не требует отдельного DNS-разрешения, не надо их считать, они никак не влияют на лимит в 10 DNS-запросов.
А как вы отправляете письма, напрямую со своего сервера или через Яндекс? И что у вас при этом в адресе отправителя (From:) и в адресе SMTP-конверта (envelope-from)?
Максим, скорей всего будет, если Message-ID будет сгенерирован до DKIM-подписи. Но правильней DKIM подписыватьв exim, тогда DKIM точно будет накладываться после генерации Date и Message-ID.
Возможно вы DKIM подпись делаете в PHP скрипте, поэтому она и накладывается до генерации Message-ID. Так обычно не делают, подпись делается на уровне MTA.
Максим, формат у Message-ID такой же как у адреса электронной почты. После собаки обычно ставится домен отправителя или каноническое имя хоста (никаких требований к домену нет), до собаки любая уникальная строка, например рандомная.
А если вы реализуете свой клиент с самоподписанным сертификатом и пиннингом (или сделаете соответствующую конфигурацию, например, Firefox убрав в ней доверие ко всем сертификатам кроме вашего) и уберете на серверной стороне все лишние cyphersuit'ы (оставите, например, ECDHE-ECDSA-AES256-GCM-SHA384 или ECDHE-ECDSA-CHACHA20-POLY1305 если не верите правительственным агентствам), то получите весьма надежную в плане криптографии конфигурацию.