Аутентификация электронной почты

Методы, направленные на предоставление проверяемой информации о происхождении сообщений электронной почты

Аутентификация электронной почты или проверка, представляет собой набор методов, направленных на предоставление проверяемой информации о происхождении сообщений электронной почты путем проверки права собственности на домен любых агентов передачи сообщений (MTA), которые участвовали в передаче и, возможно, изменении сообщения.

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

В этой статье не рассматривается аутентификация пользователя при отправке и получении электронной почты.

• 1 Обоснование
• 2 Характер проблемы
  • 2.1 Отправка из сети ADMD (MUA 1)
  • 2.2 Пользователь в роуминге (MUA 2)
  • 2.3 Пользователь отключен
  • 2.4 Примечания к разделу
• 3 Широко используемые методы аутентификации
  • 3.1 SPF
  • 3.2 DKIM
  • 3.3 DMARC
• 4 Другие методы
  • 4.1 ADSP
  • 4.2 VBR
  • 4.3 iprev
  • 4.4 DNSWL
• 5 Authentication-Results
• 6 См. Также
• 7 Ссылки

В начале 1980-х, когда Simple Mail Transfer Protocol (SMTP) был разработан, он не предусматривает реальной проверки отправителя пользователя или системы. Это не было проблемой, пока системы электронной почты управлялись надежными корпорациями и университетами, но с момента коммерциализации Интернета в начале 1990-х, спам, фишинг, и другие преступления все чаще связаны с электронной почтой.

Аутентификация электронной почты - необходимый первый шаг на пути к определению источника сообщений и, таким образом, к обеспечению большей юридической силы политик и законов.

Зависимость от владения доменом возникла в начале 2000 года. Она подразумевает грубую аутентификацию, учитывая, что домены появляются в правой части адресов электронной почты после в знаке. Детальная аутентификация на уровне пользователя может быть достигнута другими способами, такими как Pretty Good Privacy и S / MIME. В настоящее время цифровая идентификация должна управляться каждым человеком.

Выдающимся аргументом в пользу аутентификации электронной почты является возможность автоматизировать фильтрацию электронной почты на принимающих серверах. Таким образом, поддельные сообщения могут быть отклонены до того, как они попадут в почтовый ящик пользователя. В то время как протоколы стремятся разработать способы надежной блокировки недоверенной почты, индикаторы безопасности могут помечать неаутентифицированные сообщения, которые все еще попадают в папку «Входящие». Исследование 2018 года показывает, что показатели безопасности могут снизить коэффициент переходов по ссылкам более чем на десять пунктов, от 48,9% до 37,2% пользователей, открывающих поддельные сообщения.

SMTP определяет транспорт сообщений, а не содержимое сообщения. Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта, но не заголовок (кроме информации трассировки) или тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (конверт), а STD 11 и RFC 5322 определяют сообщение (заголовок и тело), ​​формально называемый Интернет-формат сообщения.

SMTP определяет информацию трассировки сообщения, которая сохраняется в заголовке с использованием следующих двух полей:

• Получено: когда сервер SMTP принимает сообщение сообщение, он вставляет эту запись трассировки в верхнюю часть заголовка (от последнего к первому).
• Return-Path: когда SMTP-сервер доставки выполняет окончательную доставку сообщения, он вставляет это поле в верхнюю часть

A почтовый пользовательский агент (MUA) знает SMTP-сервер исходящей почты по его конфигурации. MTA (или сервер ретрансляции) обычно определяет, к какому серверу подключаться, просматривая запись ресурса MX (Mail eXchange) DNS для каждого доменного имени

получателя. Путь, изображенный ниже, может быть восстановлен на основе полей заголовка трассировки, которые каждый хост добавляет в верхнюю часть заголовка при получении сообщения:

Аутентификация электронной почты может быть затруднена наличием промежуточного ретранслятора. A и B явно принадлежат автору ADMD, тогда как D и E являются частью сети получателя. Какую роль играет C ?

Return-Path: Получено: от D.example.org через E.example.org через SMTP; Вт, 5 февраля 2013 г. 11:45:02 -0500 Получено: от C.example.net через D.example.org с SMTP; Вт, 5 февраля 2013 г. 11:45:02 -0500 Получено: от B.example.com (b.example.com [192.0.2.1]) от C.example.net (это я) с идентификатором ESMTP 936ADB8838C для ; Вт, 5 февраля 2013 г. 08:44:50 -0800 (PST) Получено: от A.example.com через B.example.com через SMTP; Вт, 5 февраля 2013 г. 17:44:47 +0100 Получено: от [192.0.2.27] от A.example.com через SMTP; Вт, 05 фев 2013, 17:44:42 +0100

Важно понимать, что первые несколько строк в верхней части заголовка обычно доверяют получателю. Фактически, эти строки записываются машинами в домене административного управления получателя (ADMD ), которые действуют в соответствии с ее или его явным мандатом. Напротив, строки, которые доказывают причастность A и B, а также предполагаемого автора MUA, могут быть подделкой, созданной C . Показанное выше поле Received:является эпохальной частью заголовка. Return-Path:записывается E, агентом доставки почты (MDA), на основе конверта сообщения. Дополнительные поля трассировки, предназначенные для аутентификации электронной почты, могут заполнять верхнюю часть заголовка.

Обычно сообщения, отправляемые ADMD автора, попадают прямо в адрес назначения MX (то есть B → D на рисунках). ADMD отправителя может добавлять токены аутентификации, только если сообщение проходит через его ящики. Наиболее распространенные случаи можно схематизировать следующим образом:

Схематическое представление наиболее распространенных способов передачи сообщения электронной почты от автора к получателю.

Отправка из сети ADMD (MUA 1)

• MSA ADMD аутентифицирует пользователя либо на основе его IP-адреса, либо на основе других средств аутентификации SMTP. В зависимости от адреса получателя сообщение может следовать по обычному пути или проходить через список рассылки или службу пересылки. B может быть исходящим SMTP-прокси или smarthost.
• Если локальная сеть не блокирует исходящие соединения через порт 25, пользователь может развернуть некоторое программное обеспечение «direct-to-mx». Обычно так ведут себя зомби и другие вредоносные хосты.
• Если MUA плохо настроен, он также может использовать другое реле, например устаревшее открытое реле, который часто не аутентифицирует пользователя.

Пользователь в роуминге (MUA 2)

• В большинстве случаев можно использовать собственный ADMD MSA.
• Исходящие подключения к порту 25 могут быть перехватывается и туннелируется на прозрачный прокси.
• MUA может быть настроен на использование SMTP-реле, которое поставщик локальной сети предлагает в качестве бонуса.

Отключенный пользователь

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

Примечания к разделу

SPF

SPF аутентифицирует IP-адрес отправителя.

SPF позволяет получателю проверить, что электронное письмо, которое якобы пришло из определенного домена, исходит с IP-адреса, авторизованного администраторами этого домена. Обычно администратор домена авторизует IP-адреса, используемые их собственными исходящими MTA, включая любой прокси или смарт-хост.

IP-адрес отправляющего MTA гарантированно является действительным с помощью протокола управления передачей, поскольку он устанавливает соединение путем проверки доступности удаленного хоста. Получающий почтовый сервер получает команду HELOSMTP вскоре после установки соединения и Mail from: в начале каждое сообщение. Оба они могут содержать доменное имя. Верификатор SPF запрашивает в системе доменных имен (DNS) соответствующую запись SPF, которая, если она существует, будет указывать IP-адреса, авторизованные администратором этого домена. Результатом может быть «пройден», «не пройден» или какой-то промежуточный результат - и системы обычно принимают это во внимание в своей фильтрации спама.

DKIM

DKIM аутентифицирует части содержимого сообщения.

DKIM проверяет содержимое сообщения, используя цифровые подписи. Вместо цифровых сертификатов ключи для проверки подписи распространяются через DNS. Таким образом, сообщение связывается с доменным именем.

Администратор домена, совместимый с DKIM, генерирует одну или несколько пар асимметричных ключей, затем передает закрытые ключи подписывающему MTA и публикует открытые ключи в DNS. Метки DNS структурированы как selector._domainkey.example.com, где selector определяет пару ключей, а _domainkey- фиксированное ключевое слово, за которым следует имя подписывающего домена, чтобы произошла публикация. под управлением ADMD этого домена. Непосредственно перед введением сообщения в транспортную систему SMTP подписывающий MTA создает цифровую подпись, которая покрывает выбранные поля заголовка и тела (или только его начало). Подпись должна охватывать основные поля заголовка, такие как От:, Кому:, Дата:и Тема:, а затем добавляется в сам заголовок сообщения в виде поля трассировки. Любое количество ретрансляторов может получать и пересылать сообщение, и на каждом этапе подпись может быть проверена путем получения открытого ключа из DNS. Пока промежуточные реле не изменяют подписанные части сообщения, его DKIM-подписи остаются действительными.

DMARC

DMARC позволяет специфицировать политику для аутентифицированных сообщений. Он построен на основе двух существующих механизмов: Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM).

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

Был предложен ряд других методов, но сейчас они либо устарели, либо еще не получили широкой поддержки. К ним относятся Sender ID, Certified Server Validation, DomainKeys и следующие:

ADSP

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

ADSP был понижен до исторического уровня в ноябре 2013 года.

VBR

VBR добавляет ручку к уже аутентифицированной идентичности. Для этого метода требуются всемирно признанные органы, подтверждающие репутацию доменов.

Отправитель может подать заявку на рекомендацию в уполномоченный орган. Ссылка, если она принята, публикуется в ветке DNS, управляемой этим органом. Подтвержденный отправитель должен добавлять поле заголовка VBR-Info:к отправляемым им сообщениям. Также следует добавить подпись DKIM или использовать другой метод аутентификации, например SPF. Получатель после проверки личности отправителя может проверить подтверждение, указанное в VBR-Info:, просмотрев ссылку.

iprev

Приложениям следует избегать использования этого метода как средство аутентификации. Тем не менее, это часто выполняется, и его результаты, если таковые имеются, записываются в поле заголовка Received:помимо информации TCP, требуемой спецификацией SMTP.

Обратный IP-адрес, подтвержденный поиском IP-адреса только что найденного имени, является просто показателем того, что IP-адрес был правильно настроен в DNS. обратное разрешение диапазона IP-адресов может быть делегировано ADMD, которое их использует, или может оставаться под управлением сетевого провайдера. В последнем случае невозможно получить полезную идентификацию, относящуюся к сообщению.

DNSWL

Поиск DNSWL (белый список на основе DNS) может предоставить оценку отправителя, возможно, включая его идентификацию.

RFC 8601 определяет поле заголовка трассировки Authentication-Results:, где получатель может записывать результаты проверок аутентификации электронной почты, которые он выполнил. В одном поле можно указать несколько результатов для нескольких методов, разделенных точкой с запятой и соответствующим образом упакованных.

Например, следующее поле якобы записано Receiver.example.orgи сообщает результаты SPF и DKIM :

Аутентификация -Результаты: Receiver.example.org; spf = передать smtp.mailfrom = example.com; dkim = pass [email#160;protected] 

Первый токен после имени поля, Receiver.example.org, это идентификатор сервера аутентификации, токен, известный как authserv-id. Получатель, поддерживающий RFC 8601, отвечает за удаление (или переименование) любого ложного заголовка, утверждающего, что он принадлежит его домену, чтобы нисходящие фильтры не могли запутаться. Однако эти фильтры все еще необходимо настроить, поскольку они должны знать, какие идентификаторы может использовать домен.

Почтовому пользовательскому агенту (MUA) немного сложнее узнать, каким удостоверениям он может доверять. Поскольку пользователи могут получать электронную почту из нескольких доменов - например, если у них есть несколько адресов электронной почты, - любой из этих доменов может пропускать поля Authentication-Results:, поскольку они выглядят нейтрально. Таким образом злонамеренный отправитель может подделать идентификатор authserv-id, которому пользователь будет доверять, если сообщение пришло из другого домена. Допустимый Authentication-Results:обычно появляется чуть выше поля Received:в том же домене, из которого было ретранслировано сообщение. Дополнительные поля Получено: полямогут появляться между этим и верхней частью заголовка, поскольку сообщение было передано внутри между серверами, принадлежащими тому же самому доверенному ADMD.

Центр присвоения номеров Интернета поддерживает реестр параметров аутентификации электронной почты. Однако не все параметры необходимо регистрировать. Например, могут быть значения локальной «политики», предназначенные только для внутреннего использования сайта, которые соответствуют локальной конфигурации и не требуют регистрации.

• DMARC - Система предотвращения мошенничества с электронной почтой
• Шифрование электронной почты
• Подмена электронной почты - Создание спама в электронной почте или фишинговых сообщений с поддельными идентификационными данными или адресом отправителя
• Идентификатор
• Безопасный обмен сообщениями