Автентифікація електронної пошти або перевірка — це набір методів, спрямованих на надання інформації про походження повідомлень електронної пошти шляхом перевірки права власності на домен будь-яких агентів передачі повідомлень (MTA), які брали участь у передачі та, можливо, зміні повідомлення.

Оригінальна основа електронної пошти в Інтернеті, Simple Mail Transfer Protocol (SMTP), не має такої функції, тому підроблені адреси відправника в електронних листах (практика, відома як підробка електронної пошти) широко використовуються для фішингу, спаму електронної пошти та різних видів шахрайства. Щоб боротися з цим, було розроблено багато конкуруючих пропозицій автентифікації електронної пошти, але лише нещодавно отримали широке поширення три — SPF, DKIM і DMARC. Результати такої перевірки можуть бути використані в автоматизованому фільтруванні електронної пошти або можуть допомогти одержувачам під час вибору відповідної дії.

У цій статті не розглядається автентифікація користувачів під час надсилання та отримання електронних листів.

Обґрунтування На початку 1980-х років, коли був розроблений простий протокол передачі пошти (SMTP), він не передбачав реальної перевірки користувача або системи, що відправляє. Це не було проблемою, поки системами електронної пошти керували перевірені корпорації та університети, але після комерціалізації Інтернету на початку 1990-х років спам, фішинг та інші злочини все частіше стосуються електронної пошти. Автентифікація електронної пошти є необхідним першим кроком до визначення походження повідомлень і, таким чином, підвищення ефективності політики та законів.

На початку 2000 року виникла позиція щодо власності на домен. Це передбачає грубу автентифікацію, оскільки домени відображаються в правій частині адрес електронної пошти після значка at. Точну автентифікацію на рівні користувача можна досягти за допомогою інших засобів, таких як Pretty Good Privacy та S/MIME. Наразі цифровою ідентичністю має керувати кожен окремо.

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

Характер проблеми SMTP визначає транспортування повідомлень, а не вміст повідомлення. Таким чином, він визначає поштовий конверт та його параметри, такі як відправник конверта, але не заголовок (крім інформації трасування), і не тіло самого повідомлення. Стандарти STD 10 та визначають SMTP (конверт), тоді як STD 11 і визначають повідомлення (заголовок і тіло), яке офіційно називається форматом Інтернет-повідомлення.

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

Отримано: коли SMTP-сервер приймає повідомлення, він вставляє цей запис трасування у верхній частині заголовка (від останнього до першого). Шлях повернення (Return-Path): коли SMTP-сервер доставки здійснює остаточну доставку повідомлення, він вставляє це поле у верхній частині заголовка.

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

Шлях, зображений нижче, можна реконструювати на основі полів заголовка трасування, які кожен хост додає до верхньої частини заголовка, коли отримує повідомлення:

Return-Path: <[email protected]> Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from B.example.com (b.example.com [192.0.2.1]) by C.example.net (which is me) with ESMTP id 936ADB8838C for <[email protected]>; Tue, 05 Feb 2013 08:44:50 -0800 (PST) Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100 Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 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. Залежно від адреси одержувача повідомлення може проходити звичайним шляхом або проходити через список розсилки або службу пересилання.Наприклад, одержувач може вказати Gmail куди пересилати повідомлення на іншу електронну адресу. Відправник не обов'язково про це знає. B може бути вихідним SMTP-проксі або смарт-хостом.Правильно налаштовані проксі відображаються як частина ADMD автора. Якщо локальна мережа не блокує вихідні з'єднання через порт 25,Деякі ADMD блокують вихідне підключення до порту 25 (SMTP), щоб уникнути цього. Ця проактивна техніка описана в RFC 5068. Крім того, деякі блокують вхідні SMTP-з'єднання з IPs зазначений як dialup/DSL/cable. користувач може розгорнути певне програмне забезпечення «direct-to-mx».В даному випадку про ADMD автора взагалі не йдеться. Зазвичай так поводяться зомбі та інші шкідливі хости. Якщо MUA погано налаштований, він також може використовувати інший ретранслятор, наприклад застарілий відкритий ретранслятор, який часто не автентифікує користувача.

Користувач у роумінгу (MUA 2)

У більшості випадків все ще можна використовувати власний ADMD MSA.Деякі провайдери блокують порт 587, хоча RFC 5068 чітко говорить: Вихідні підключення до порту 25 можуть бути перехоплені та тунельовані до прозорого проксі-сервера.В даному випадку про ADMD автора взагалі не йдеться. MUA можна налаштувати на використання ретранслятора SMTP, який провайдер локальної мережі пропонує як бонус.

Відключений користувач

Цифрова листівка може надсилати пошту від імені клієнта, який ввів адресу електронної пошти на локальній клавіатурі; можна вважати, що деякі вебформи працюють аналогічно.В даному випадку про ADMD автора взагалі не йдеться.

Примітки до розділу

Використовувані методи аутентифікації

SPF

SPF дозволяє одержувачу перевірити, чи електронний лист, який, як стверджується, надійшов із певного домену, надходить з IP-адреси, авторизованої адміністраторами цього домену. Зазвичай адміністратор домену авторизує IP-адреси, які використовуються його власними вихідними MTA, включаючи будь-який проксі-сервер або смарт-хост.

Протокол керування передаванням гарантує дійсність IP-адреси MTA, що надсилає, оскільки він встановлює з'єднання, перевіряючи, чи доступний віддалений хост.IP Address forgery is possible, but generally involves a lower level of criminal behavior (breaking and entering, wiretapping, etc.), which are too risky for a typical hacker or spammer, or insecure servers not implementing RFC 1948, see also Transmission Control Protocol#Connection hijacking. Поштовий сервер-отримувач отримує команду HELO SMTP невдовзі після встановлення з'єднання та Mail from: на початку кожного повідомлення. Обидва вони можуть містити доменне ім'я. Верифікатор SPF запитує систему доменних імен (DNS) щодо відповідного запису SPF, який, якщо він існує, указує IP-адреси, авторизовані адміністратором цього домену. Результатом може бути «пройшов», «не пройшов» або якийсь проміжний результат — і системи, як правило, враховують це у своїй фільтрації спаму.

DKIM

DKIM перевіряє вміст повідомлення, розгортаючи цифрові підписи. Замість використання цифрових сертифікатів ключі для перевірки підпису поширюються через DNS. Таким чином, повідомлення пов'язується з доменним ім'ям.

Адміністратор домену, сумісний із DKIM, генерує одну або кілька пар асиметричних алгоритмів шифрування, потім передає приватні ключі MTA, що підписує, і публікує відкриті ключі в DNS. Мітки DNS структуровані як selector . _domainkey.example.com, де селектор ідентифікує пару ключів, а _domainkey — це фіксоване ключове слово, за яким іде ім'я підписуючого домену, щоб публікація відбувалася під контролем ADMD цього домену. Безпосередньо перед введенням повідомлення в транспортну систему SMTP підписуючий MTA створює цифровий підпис, який охоплює вибрані поля заголовка та тіла (або лише його початок). Підпис має охоплювати основні поля заголовка, такі як From:, To:, Date:, і Subject:, а потім додається до самого заголовка повідомлення як поле трасування. Будь-яка кількість ретрансляторів може отримати та пересилати повідомлення, і на кожному стрибку підпис може бути перевірений шляхом отримання відкритого ключа з DNS. Поки проміжні ретранслятори не змінюють підписані частини повідомлення, його DKIM-підписи залишаються дійсними.

DMARC

DMARC дозволяє вказувати політику для автентифікованих повідомлень. Він створений на основі двох існуючих механізмів: Sender Policy Framework (SPF) і DomainKeys Identified Mail (DKIM).

Це дозволяє адміністративному власнику домену публікувати політику в своїх DNS-записах, щоб указати, який механізм (DKIM, SPF або обидва) використовується під час надсилання електронної пошти з цього домену; як перевірити поле From:, представлене кінцевим користувачам; як одержувач повинен справлятися з помилками — і механізм звітування про дії, виконані відповідно до цих політик.

Інші методи Було запропоновано низку інших методів, але зараз вони або застаріли, або ще не отримали широкої підтримки. До них належать — ідентифікатор відправника, перевірка сертифікованого сервера, ключі домену та наведені нижче:

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

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

VBR VBR додає гарантію до вже аутентифікованої особи. Для цього методу потрібні всесвітньо визнані органи, які сертифікують репутацію доменів.

Відправник може подати заявку на отримання довідки до ваучерного органу. Посилання, якщо воно прийняте, публікується у гілці DNS, яким керує цей орган. Гарантований відправник повинен додати поле заголовка VBR-Info: до повідомлень, які він надсилає. Він також повинен додати підпис DKIM або використовувати інший метод автентифікації, наприклад SPF. Одержувач після підтвердження особи відправника, може перевірити гарантію, заявлену в VBR-Info: шляхом пошуку посилання.

iprev Програми повинні уникати використання цього методу як засобу автентифікації. Незважаючи на це, його часто використовують, а його результати, якщо такі є, записують у поле заголовка Received: окрім інформації TCP, яка вимагається специфікацією SMTP.