SPF vs. DKIM - точные варианты использования и различия


20

Я извиняюсь за смутное название. Я не совсем понимаю, почему SPF и DKIM должны использоваться вместе.

Во-первых: SPF может пройти там, где он должен потерпеть неудачу, если отправитель или DNS «подделан», и он может потерпеть неудачу там, где он должен пройти, если задействованы некоторые расширенные настройки прокси-серверов и серверов пересылки.

DKIM может пройти там, где он должен потерпеть неудачу, либо из-за ошибки / слабости в криптографии (мы исключаем это, отсюда и упрощенная точка), либо потому, что DNS-запрос подделан.

Так как ошибка криптографии исключена, разница (как я вижу это) состоит в том, что DKIM может использоваться в установках, где SPF потерпит неудачу. Я не могу привести ни одного примера, в котором было бы полезно использовать оба. Если настройка допускает SPF, то DIKM не должен добавлять дополнительную проверку.

Может ли кто-нибудь дать мне пример преимущества использования обоих?

Ответы:


15

SPF имеет гораздо больше рейтингов, чем Pass / Fail. Использование их в эвристическом подсчете спама делает процесс более простым и точным. Сбой из-за «расширенных настроек» означает, что почтовый администратор не знал, что он делал при настройке записи SPF. Там нет настройки, которую SPF не может правильно объяснить.

Криптография не работает в абсолютах, никогда. Единственное шифрование, разрешенное в DKIM, обычно требует значительных ресурсов для взлома. Большинство людей считают это достаточно безопасным. Каждый должен оценивать свои ситуации. Опять же, DKIM имеет больше рейтингов, чем просто Pass / Fail.

Один пример, в котором можно было бы использовать оба: отправка двум разным сторонам, где один проверяет SPF, а другой проверяет DKIM. Другой пример - отправка стороне с контентом, который обычно имеет высокий рейтинг в тесте на спам, но это компенсируется как DKIM, так и SPF, что позволяет доставлять почту.

В большинстве случаев это не требуется, хотя отдельные почтовые администраторы устанавливают свои собственные правила. И то, и другое помогает решить различные аспекты СПАМА: SPF - это ретранслятор электронной почты, а DKIM - целостность электронной почты и подлинность источника.


Хорошо, я следую вашим замечаниям (особенно если некоторые могут просто использовать только один из двух - как я этого не понял!). Таким образом, SPF и DKIM могут иметь разные настройки и рейтинги, но в целом они должны быть лицом к одной монете. К вашему последнему пункту: Почте из авторизованного ретранслятора (SPF) следует доверять точно так же, как и действительной подписи DKIM. В конце концов, владелец домена одобрил и то и другое. Я только что проверил свою почту только с SPF, и хотя мои университеты и Gmail предлагают принять ее, hotmail рассматривает ее как спам - возможно, потому что они полагаются на DIKM. Спасибо за ваш комментарий Крис!
удаленный пользователь 42

Hotmail использует SenderID (так сказать SPF 2.0), DKIM, SenderScore, PBL и собственную технологию фильтрации. Они немного скрытны относительно точной формулы.
Крис С

18

На этот вопрос ответили некоторое время назад, но я думаю, что в принятом ответе отсутствует смысл того, почему оба должны использоваться вместе, чтобы быть эффективными.

SPF проверяет IP-адрес последнего прыжка SMTP-сервера по авторизованному списку. DKIM проверяет, что почта была первоначально отправлена ​​данным доменом, и гарантирует ее целостность.

Допустимые сообщения с подписью DKIM могут использоваться как спам или фишинг, если они повторно отправляются без изменений. SPF не проверяет целостность сообщения.

Представьте себе сценарий, когда вы получаете действительное электронное письмо с подписью DKIM (из вашего банка, от друга и т. Д.), И вы находите хороший способ использовать это письмо без изменений: тогда вы можете просто отправить это письмо тысячи раз разным людям. Поскольку почтовое изменение не изменяется, подпись DKIM по-прежнему будет действительной, и сообщение будет считаться легитимным.

В любом случае, SPF проверяет источник (реальный IP / DNS SMTP-сервера) почты, поэтому SPF предотвратит пересылку почты, поскольку вы не можете переслать действительную почту через хорошо настроенный SMTP-сервер, и почта, приходящая с других IP-адресов, будет отклонено, эффективно предотвращая повторную отправку «действительных» сообщений DKIM как спама.


Не могли бы вы привести несколько примеров того, как почта может быть использована без изменений?
user3413723

Любое электронное письмо, начинающееся со слова «Уважаемый клиент», «Уважаемый пользователь» или «Уважаемый <первая часть вашего адреса электронной почты перед знаком @»>. Вот почему важно, чтобы в законных электронных письмах для вас всегда содержалась хотя бы одна часть вашей личной информации, например, часть вашего почтового / почтового индекса или ваше полное имя. (Это делает их более аутентичными и не подлежащими повторному использованию.)
Adambean

Но если поля заголовка были подписаны, включая получателей, то наверняка это исключает возможность повторной атаки на новых получателей? Т.е. добавление подписей h=from:to;( от необходимости в RFC 6376 до того , чтобы быть необязательным) должно позволять атаки повторного воспроизведения только на одного и того же получателя. Что плохо, но не так плохо, как то, что предлагает этот ответ.
Ричард Данн

4

Вот некоторые причины , вы всегда должны публиковать как SPF и DKIM.

  1. Некоторые поставщики почтовых ящиков поддерживают только одно или другое, а некоторые поддерживают оба, но весят одного больше, чем другого.

  2. DKIM защищает электронную почту от изменения в пути, SPF - нет.

Я бы добавил DMARC в список тоже. В чем недостаток, чтобы всегда публиковать полную аутентификацию электронной почты?


1
«Что плохого в том, чтобы всегда публиковать полную аутентификацию электронной почты?», Усилия! Я предполагаю, что Devops - это уже PITA, какой еще кирпич в стене, или 3, в зависимости от обстоятельств.
Гордон Ригли

При чем тут интернет-провайдер? Вы имеете в виду почтового провайдера?
Уильям

Да, я имел в виду провайдера почтовых ящиков. Люди часто получали услуги электронной почты от интернет-провайдеров, поэтому я привык говорить провайдер.
Нил Анускевич,

Спасибо за указание на это, поскольку я теперь изменил его на поставщика почтовых ящиков.
Нил Анускевич,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.