Автентифікація електронної пошти або перевірка — це набір методів, спрямованих на надання інформації про походження повідомлень електронної пошти шляхом перевірки права власності на домен будь-яких агентів передачі повідомлень (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 та RFC 5321 визначають SMTP (конверт), тоді як STD 11 іRFC 5322 визначають повідомлення (заголовок і тіло), яке офіційно називається форматом Інтернет-повідомлення.
SMTP визначає інформацію трасування повідомлення, яке зберігається в заголовку за допомогою наступних двох полів:
- Отримано: коли SMTP-сервер приймає повідомлення, він вставляє цей запис трасування у верхній частині заголовка (від останнього до першого).
- Шлях повернення (Return-Path): коли SMTP-сервер доставки здійснює остаточну доставку повідомлення, він вставляє це поле у верхній частині заголовка.
Поштовий клієнт (MUA) знає SMTP-сервер вихідної пошти з його конфігурації. MTA (або сервер ретрансляції), зазвичай, визначає, до якого сервера підключатися, шукаючи запис ресурсу MX (Mail eXchange) DNS для кожного доменного імені одержувача.
Шлях, зображений нижче, можна реконструювати на основі полів заголовка трасування, які кожен хост додає до верхньої частини заголовка, коли отримує повідомлення:
Return-Path: <author@example.com> 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 <different-recipient@example.net>; 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. Залежно від адреси одержувача повідомлення може проходити звичайним шляхом або проходити через список розсилки або службу пересилання. B може бути вихідним SMTP-проксі або смарт-хостом.
- Якщо локальна мережа не блокує вихідні з'єднання через порт 25, користувач може розгорнути певне програмне забезпечення «direct-to-mx». Зазвичай так поводяться зомбі та інші шкідливі хости.
- Якщо MUA погано налаштований, він також може використовувати інший ретранслятор, наприклад застарілий відкритий ретранслятор, який часто не автентифікує користувача.
Користувач у роумінгу (MUA 2)
- У більшості випадків все ще можна використовувати власний ADMD MSA.
- Вихідні підключення до порту 25 можуть бути перехоплені та тунельовані до прозорого проксі-сервера.
- MUA можна налаштувати на використання ретранслятора SMTP, який провайдер локальної мережі пропонує як бонус.
Відключений користувач
- Цифрова листівка може надсилати пошту від імені клієнта, який ввів адресу електронної пошти на локальній клавіатурі; можна вважати, що деякі вебформи працюють аналогічно.
Примітки до розділу
- Наприклад, одержувач може вказати Gmail куди пересилати повідомлення на іншу електронну адресу. Відправник не обов'язково про це знає.
- Правильно налаштовані проксі відображаються як частина ADMD автора.
- Деякі ADMD блокують вихідне підключення до порту 25 (SMTP), щоб уникнути цього. Ця проактивна техніка описана в RFC 5068. Крім того, деякі блокують вхідні SMTP-з'єднання з IPs зазначений як /DSL/cable.
- В даному випадку про ADMD автора взагалі не йдеться.
- Деякі провайдери блокують порт 587, хоча RFC 5068 чітко говорить:
Використовувані методи аутентифікації
SPF
SPF дозволяє одержувачу перевірити, чи електронний лист, який, як стверджується, надійшов із певного домену, надходить з IP-адреси, авторизованої адміністраторами цього домену. Зазвичай адміністратор домену авторизує IP-адреси, які використовуються його власними вихідними MTA, включаючи будь-який проксі-сервер або смарт-хост.
Протокол керування передаванням гарантує дійсність IP-адреси MTA, що надсилає, оскільки він встановлює з'єднання, перевіряючи, чи доступний віддалений хост. Поштовий сервер-отримувач отримує команду 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.
Зворотня IP-адреса, підтверджена пошуком IP-адреси щойно знайденого імені, є лише ознакою того, що IP-адресу була правильно налаштовано в DNS. Зворотне вирішення діапазону IP-адрес може бути делеговано ADMD, який їх використовує, або може залишатися під керуванням провайдера мережі. В останньому випадку неможливо отримати корисну ідентифікаційну інформацію, пов'язану з повідомленням.
DNSWL
Перегляд DNSWL (білого списку на основі DNS) може надати оцінку відправника, можливо, включаючи його ідентифікацію.
Автентифікація-результати
RFC 8601 визначає поле заголовка трасування Authentication-Results:
де одержувач може записати результати перевірок автентифікації електронної пошти, які він виконав. Кілька результатів для кількох методів можна повідомити в одному полі, розділивши їх крапкою з комою та обернувши відповідним чином.
Наприклад, таке поле нібито створено receiver.example.org
і повідомляє про результати SPF та DKIM:
Authentication-Results: receiver.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass header.i=@example.com
Перший маркер після назви поля, receiver.example.org
, є ідентифікатором сервера автентифікації, маркером, відомим як authserv-id. Приймач, що підтримує RFC 8601, несе відповідальність за видалення (або перейменування) будь-якого хибного заголовка, який стверджує, що він належить до його домену, щоб фільтри нижнього потоку не заплуталися. Однак ці фільтри все одно потрібно налаштувати, оскільки вони мають знати, які ідентифікатори може використовувати домен.
Для поштового агента користувача (MUA) трохи важче дізнатися, яким ідентифікаторам він може довіряти. Оскільки користувачі можуть отримувати електронну пошту з кількох доменів — наприклад, якщо у них є кілька адрес електронної пошти — будь-який з цих доменів може пропускати поля Authentication-Results:
оскільки вони виглядають нейтральними. Таким чином, зловмисний відправник може підробити ідентифікатор authserv, якому користувач довіряв би, якби повідомлення надійшло з іншого домену. Справжні Authentication-Results:
зазвичай з'являються відразу над полем Received:
тим самим доменом, з якого було передано повідомлення. Додатково Received:
поля можуть з'являтися між цим і верхньою частиною заголовка, оскільки повідомлення було передано внутрішньо між серверами, що належать тому самому довіреному ADMD.
Орган з присвоєння номерів Інтернету веде реєстр параметрів автентифікації електронної пошти[ 7 квітня 2022 у Wayback Machine.]. Однак не всі параметри потрібно реєструвати. Наприклад, можуть існувати локальні значення «політики», розроблені лише для внутрішнього використання сайту, які відповідають локальній конфігурації і не потребують реєстрації.
Див. також
- DMARC – технологія, що дозволяє отримувачу електронної пошти перевірити справжність її відправника;
- Шифрування електронної пошти;
- Ident — протокол, описаний в RFC 1413, призначений для ідентифікації користувача, який встановлює TCP — з'єднання.
Примітки
- Заповніть пропущені параметри: назву і/або авторів. arXiv:[1].
- kerner, Sean Michael. DMARC Email Security Adoption Grows in U.S. Government. eWeek. Процитовано 24 листопада 2018.
- . workshop. Federal Trade Commission. November 9–10, 2004. Архів оригіналу за 3 June 2012. Процитовано 4 лютого 2013.
The Report, however, identified domain-level authentication as a promising technological development
- Hang Hu; Gang Wang (15 серпня 2018). . 27th Security Symposium. Архів оригіналу за 19 лютого 2022. Процитовано 19 лютого 2022.
- [[[:Шаблон:Cite IETF/makelink]] Simple Mail Transfer Protocol]. .
- [[[:Шаблон:Cite IETF/makelink]] Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1]. doi:10.17487/RFC7208. .
- [[[:Шаблон:Cite IETF/makelink]] Simple Mail Transfer Protocol]. doi:10.17487/RFC5321. .
- 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).
- Scott Kitterman (21 листопада 2009). . spf-help. gossamer-threads.com. Архів оригіналу за 7 травня 2016. Процитовано 19 лютого 2022.
I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders.
- [[[:Шаблон:Cite IETF/makelink]] DomainKeys Identified Mail (DKIM) Signatures]. doi:10.17487/RFC6376. .
- Dave Crocker (16 жовтня 2007). . DKIM.org. Архів оригіналу за 29 вересня 2017. Процитовано 17 лютого 2013.
- [[[:Шаблон:Cite IETF/makelink]] DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]. .
- Barry Leiba (25 листопада 2013). . IETF. Архів оригіналу за 5 березня 2016. Процитовано 19 лютого 2022.
- [[[:Шаблон:Cite IETF/makelink]] Vouch By Reference]. doi:10.17487/RFC5518. .
- [[[:Шаблон:Cite IETF/makelink]] Message Header Field for Indicating Message Authentication Status]. .
- [[[:Шаблон:Cite IETF/makelink]] Classless IN-ADDR.ARPA delegation]. doi:10.17487/RFC2317. .
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Avtentifikaciya elektronnoyi poshti abo perevirka ce nabir metodiv spryamovanih na nadannya informaciyi pro pohodzhennya povidomlen elektronnoyi poshti shlyahom perevirki prava vlasnosti na domen bud yakih agentiv peredachi povidomlen MTA yaki brali uchast u peredachi ta mozhlivo zmini povidomlennya Originalna osnova elektronnoyi poshti v Interneti Simple Mail Transfer Protocol SMTP ne maye takoyi funkciyi tomu pidrobleni adresi vidpravnika v elektronnih listah praktika vidoma yak pidrobka elektronnoyi poshti shiroko vikoristovuyutsya dlya fishingu spamu elektronnoyi poshti ta riznih vidiv shahrajstva Shob borotisya z cim bulo rozrobleno bagato konkuruyuchih propozicij avtentifikaciyi elektronnoyi poshti ale lishe neshodavno otrimali shiroke poshirennya tri SPF DKIM i DMARC Rezultati takoyi perevirki mozhut buti vikoristani v avtomatizovanomu filtruvanni elektronnoyi poshti abo mozhut dopomogti oderzhuvacham pid chas viboru vidpovidnoyi diyi U cij statti ne rozglyadayetsya avtentifikaciya koristuvachiv pid chas nadsilannya ta otrimannya elektronnih listiv ObgruntuvannyaNa pochatku 1980 h rokiv koli buv rozroblenij prostij protokol peredachi poshti SMTP vin ne peredbachav realnoyi perevirki koristuvacha abo sistemi sho vidpravlyaye Ce ne bulo problemoyu poki sistemami elektronnoyi poshti keruvali perevireni korporaciyi ta universiteti ale pislya komercializaciyi Internetu na pochatku 1990 h rokiv spam fishing ta inshi zlochini vse chastishe stosuyutsya elektronnoyi poshti Avtentifikaciya elektronnoyi poshti ye neobhidnim pershim krokom do viznachennya pohodzhennya povidomlen i takim chinom pidvishennya efektivnosti politiki ta zakoniv Na pochatku 2000 roku vinikla poziciya shodo vlasnosti na domen Ce peredbachaye grubu avtentifikaciyu oskilki domeni vidobrazhayutsya v pravij chastini adres elektronnoyi poshti pislya znachka at Tochnu avtentifikaciyu na rivni koristuvacha mozhna dosyagti za dopomogoyu inshih zasobiv takih yak Pretty Good Privacy ta S MIME Narazi cifrovoyu identichnistyu maye keruvati kozhen okremo Vazhlivim argumentom dlya avtentifikaciyi elektronnoyi poshti ye mozhlivist avtomatizuvati filtraciyu elektronnoyi poshti na serverah oderzhuvachah Takim chinom pidrobleni povidomlennya mozhut buti vidhileni do togo yak voni nadhodyat do papki Vhidni koristuvacha U toj chas yak protokoli pragnut rozrobiti sposobi nadijnogo blokuvannya nenadijnoyi poshti indikatori bezpeki mozhut poznachati neavtentifikovani povidomlennya yaki vse she nadhodyat do papki Vhidni Doslidzhennya 2018 roku pokazuye sho pokazniki bezpeki mozhut zniziti koeficiyent klikiv bilsh nizh na desyat punktiv z 48 9 do 37 2 koristuvachiv yaki vidkrivayut pidrobleni povidomlennya Harakter problemiSMTP viznachaye transportuvannya povidomlen a ne vmist povidomlennya Takim chinom vin viznachaye poshtovij konvert ta jogo parametri taki yak vidpravnik konverta ale ne zagolovok krim informaciyi trasuvannya i ne tilo samogo povidomlennya Standarti STD 10 ta RFC 5321 viznachayut SMTP konvert todi yak STD 11 iRFC 5322 viznachayut povidomlennya zagolovok i tilo yake oficijno nazivayetsya formatom Internet povidomlennya SMTP viznachaye informaciyu trasuvannya povidomlennya yake zberigayetsya v zagolovku za dopomogoyu nastupnih dvoh poliv Otrimano koli SMTP server prijmaye povidomlennya vin vstavlyaye cej zapis trasuvannya u verhnij chastini zagolovka vid ostannogo do pershogo Shlyah povernennya Return Path koli SMTP server dostavki zdijsnyuye ostatochnu dostavku povidomlennya vin vstavlyaye ce pole u verhnij chastini zagolovka Poshtovij kliyent MUA znaye SMTP server vihidnoyi poshti z jogo konfiguraciyi MTA abo server retranslyaciyi zazvichaj viznachaye do yakogo servera pidklyuchatisya shukayuchi zapis resursu MX Mail eXchange DNS dlya kozhnogo domennogo imeni oderzhuvacha Shlyah zobrazhenij nizhche mozhna rekonstruyuvati na osnovi poliv zagolovka trasuvannya yaki kozhen host dodaye do verhnoyi chastini zagolovka koli otrimuye povidomlennya Avtentifikaciya elektronnoyi poshti mozhe buti uskladnena nayavnistyu promizhnogo rele A i B yavno nalezhat do domenu administrativnogo upravlinnya avtora todi yak D i E ye chastinoyu merezhi oderzhuvachiv Yaku rol vidigraye S Return Path lt author example com gt 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 lt different recipient example net gt 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 Vazhlivo rozumiti sho pershim kilkom ryadkam u verhnij chastini zagolovka oderzhuvach zazvichaj doviryaye Naspravdi ci ryadki pishutsya mashinami v domeni administrativnogo keruvannya ADMD oderzhuvacha yaki diyut vidpovidno do yiyi chi jogo yavnogo doruchennya Navpaki ryadki yaki dovodyat prichetnist A i B a takozh MUA peredbachuvanogo avtora mozhut buti pidrobkoyu stvorenoyu C Pole Received pokazane vishe ye epohalnoyu chastinoyu zagolovka Return Path zapisuyetsya E agentom dostavki povidomlen MDA na osnovi konverta povidomlennya Dodatkovi polya trasuvannya priznacheni dlya avtentifikaciyi elektronnoyi poshti mozhut zapovnyuvati verhnyu chastinu zagolovka Zazvichaj povidomlennya nadislani ADMD avtora nadhodyat bezposeredno do MX adresata tobto B D na malyunkah ADMD vidpravnika mozhe dodati markeri avtentifikaciyi lishe yaksho povidomlennya prohodit cherez jogo yashiki Najposhirenishi vipadki mozhna shematizuvati tak Shematichne zobrazhennya najposhirenishih sposobiv peredachi povidomlennya elektronnoyi poshti vid jogo avtora do oderzhuvacha Nadsilannya z merezhi ADMD MUA 1 MSA ADMD atentifikuye koristuvacha na osnovi jogo IP adresi abo inshih zasobiv avtentifikaciyi SMTP Zalezhno vid adresi oderzhuvacha povidomlennya mozhe prohoditi zvichajnim shlyahom abo prohoditi cherez spisok rozsilki abo sluzhbu peresilannya B mozhe buti vihidnim SMTP proksi abo smart hostom Yaksho lokalna merezha ne blokuye vihidni z yednannya cherez port 25 koristuvach mozhe rozgornuti pevne programne zabezpechennya direct to mx Zazvichaj tak povodyatsya zombi ta inshi shkidlivi hosti Yaksho MUA pogano nalashtovanij vin takozh mozhe vikoristovuvati inshij retranslyator napriklad zastarilij vidkritij retranslyator yakij chasto ne avtentifikuye koristuvacha Koristuvach u roumingu MUA 2 U bilshosti vipadkiv vse she mozhna vikoristovuvati vlasnij ADMD MSA Vihidni pidklyuchennya do portu 25 mozhut buti perehopleni ta tunelovani do prozorogo proksi servera MUA mozhna nalashtuvati na vikoristannya retranslyatora SMTP yakij provajder lokalnoyi merezhi proponuye yak bonus Vidklyuchenij koristuvach Cifrova listivka mozhe nadsilati poshtu vid imeni kliyenta yakij vviv adresu elektronnoyi poshti na lokalnij klaviaturi mozhna vvazhati sho deyaki vebformi pracyuyut analogichno Primitki do rozdilu Napriklad oderzhuvach mozhe vkazati Gmail kudi peresilati povidomlennya na inshu elektronnu adresu Vidpravnik ne obov yazkovo pro ce znaye Pravilno nalashtovani proksi vidobrazhayutsya yak chastina ADMD avtora Deyaki ADMD blokuyut vihidne pidklyuchennya do portu 25 SMTP shob uniknuti cogo Cya proaktivna tehnika opisana v RFC 5068 Krim togo deyaki blokuyut vhidni SMTP z yednannya z IPs zaznachenij yak DSL cable V danomu vipadku pro ADMD avtora vzagali ne jdetsya Deyaki provajderi blokuyut port 587 hocha RFC 5068 chitko govorit Vikoristovuvani metodi autentifikaciyiSPF Dokladnishe Sender Policy Framework SPF avtentifikuye IP adresu vidpravnika SPF dozvolyaye oderzhuvachu pereviriti chi elektronnij list yakij yak stverdzhuyetsya nadijshov iz pevnogo domenu nadhodit z IP adresi avtorizovanoyi administratorami cogo domenu Zazvichaj administrator domenu avtorizuye IP adresi yaki vikoristovuyutsya jogo vlasnimi vihidnimi MTA vklyuchayuchi bud yakij proksi server abo smart host Protokol keruvannya peredavannyam garantuye dijsnist IP adresi MTA sho nadsilaye oskilki vin vstanovlyuye z yednannya pereviryayuchi chi dostupnij viddalenij host Poshtovij server otrimuvach otrimuye komandu HELO SMTP nevdovzi pislya vstanovlennya z yednannya ta Mail from na pochatku kozhnogo povidomlennya Obidva voni mozhut mistiti domenne im ya Verifikator SPF zapituye sistemu domennih imen DNS shodo vidpovidnogo zapisu SPF yakij yaksho vin isnuye ukazuye IP adresi avtorizovani administratorom cogo domenu Rezultatom mozhe buti projshov ne projshov abo yakijs promizhnij rezultat i sistemi yak pravilo vrahovuyut ce u svoyij filtraciyi spamu DKIM DKIM autentifikuye chastini vmistu povidomlennya Dokladnishe DomainKeys Identified Mail DKIM pereviryaye vmist povidomlennya rozgortayuchi cifrovi pidpisi Zamist vikoristannya cifrovih sertifikativ klyuchi dlya perevirki pidpisu poshiryuyutsya cherez DNS Takim chinom povidomlennya pov yazuyetsya z domennim im yam Administrator domenu sumisnij iz DKIM generuye odnu abo kilka par asimetrichnih algoritmiv shifruvannya potim peredaye privatni klyuchi MTA sho pidpisuye i publikuye vidkriti klyuchi v DNS Mitki DNS strukturovani yak i selector i domainkey example com de selektor identifikuye paru klyuchiv a domainkey ce fiksovane klyuchove slovo za yakim ide im ya pidpisuyuchogo domenu shob publikaciya vidbuvalasya pid kontrolem ADMD cogo domenu Bezposeredno pered vvedennyam povidomlennya v transportnu sistemu SMTP pidpisuyuchij MTA stvoryuye cifrovij pidpis yakij ohoplyuye vibrani polya zagolovka ta tila abo lishe jogo pochatok Pidpis maye ohoplyuvati osnovni polya zagolovka taki yak From To Date i Subject a potim dodayetsya do samogo zagolovka povidomlennya yak pole trasuvannya Bud yaka kilkist retranslyatoriv mozhe otrimati ta peresilati povidomlennya i na kozhnomu stribku pidpis mozhe buti perevirenij shlyahom otrimannya vidkritogo klyucha z DNS Poki promizhni retranslyatori ne zminyuyut pidpisani chastini povidomlennya jogo DKIM pidpisi zalishayutsya dijsnimi DMARC Dokladnishe DMARC DMARC dozvolyaye vkazuvati politiku dlya avtentifikovanih povidomlen Vin stvorenij na osnovi dvoh isnuyuchih mehanizmiv Sender Policy Framework SPF i DomainKeys Identified Mail DKIM Ce dozvolyaye administrativnomu vlasniku domenu publikuvati politiku v svoyih DNS zapisah shob ukazati yakij mehanizm DKIM SPF abo obidva vikoristovuyetsya pid chas nadsilannya elektronnoyi poshti z cogo domenu yak pereviriti pole From predstavlene kincevim koristuvacham yak oderzhuvach povinen spravlyatisya z pomilkami i mehanizm zvituvannya pro diyi vikonani vidpovidno do cih politik Inshi metodiBulo zaproponovano nizku inshih metodiv ale zaraz voni abo zastarili abo she ne otrimali shirokoyi pidtrimki Do nih nalezhat identifikator vidpravnika perevirka sertifikovanogo servera klyuchi domenu ta navedeni nizhche ADSP ADSP dozvoliv specifikaciyu politiki dlya povidomlen pidpisanih domenom avtora Povidomlennya povinno bulo spochatku projti avtentifikaciyu DKIM a potim ADSP mig vimagati karalnoyi obrobki yaksho povidomlennya ne bulo pidpisane domenom ami avtora vidpovidno do polya zagolovka From ADSP bulo znizheno do istorichnogo v listopadi 2013 roku VBR VBR dodaye garantiyu do vzhe autentifikovanoyi osobi Dlya cogo metodu potribni vsesvitno viznani organi yaki sertifikuyut reputaciyu domeniv Vidpravnik mozhe podati zayavku na otrimannya dovidki do vauchernogo organu Posilannya yaksho vono prijnyate publikuyetsya u gilci DNS yakim keruye cej organ Garantovanij vidpravnik povinen dodati pole zagolovka VBR Info do povidomlen yaki vin nadsilaye Vin takozh povinen dodati pidpis DKIM abo vikoristovuvati inshij metod avtentifikaciyi napriklad SPF Oderzhuvach pislya pidtverdzhennya osobi vidpravnika mozhe pereviriti garantiyu zayavlenu v VBR Info shlyahom poshuku posilannya iprev Programi povinni unikati vikoristannya cogo metodu yak zasobu avtentifikaciyi Nezvazhayuchi na ce jogo chasto vikoristovuyut a jogo rezultati yaksho taki ye zapisuyut u pole zagolovka Received okrim informaciyi TCP yaka vimagayetsya specifikaciyeyu SMTP Zvorotnya IP adresa pidtverdzhena poshukom IP adresi shojno znajdenogo imeni ye lishe oznakoyu togo sho IP adresu bula pravilno nalashtovano v DNS Zvorotne virishennya diapazonu IP adres mozhe buti delegovano ADMD yakij yih vikoristovuye abo mozhe zalishatisya pid keruvannyam provajdera merezhi V ostannomu vipadku nemozhlivo otrimati korisnu identifikacijnu informaciyu pov yazanu z povidomlennyam DNSWL Pereglyad DNSWL bilogo spisku na osnovi DNS mozhe nadati ocinku vidpravnika mozhlivo vklyuchayuchi jogo identifikaciyu Avtentifikaciya rezultatiRFC 8601 viznachaye pole zagolovka trasuvannya Authentication Results de oderzhuvach mozhe zapisati rezultati perevirok avtentifikaciyi elektronnoyi poshti yaki vin vikonav Kilka rezultativ dlya kilkoh metodiv mozhna povidomiti v odnomu poli rozdilivshi yih krapkoyu z komoyu ta obernuvshi vidpovidnim chinom Napriklad take pole nibito stvoreno receiver example org i povidomlyaye pro rezultati SPF ta DKIM Authentication Results receiver example org spf pass smtp mailfrom example com dkim pass header i example com Pershij marker pislya nazvi polya receiver example org ye identifikatorom servera avtentifikaciyi markerom vidomim yak authserv id Prijmach sho pidtrimuye RFC 8601 nese vidpovidalnist za vidalennya abo perejmenuvannya bud yakogo hibnogo zagolovka yakij stverdzhuye sho vin nalezhit do jogo domenu shob filtri nizhnogo potoku ne zaplutalisya Odnak ci filtri vse odno potribno nalashtuvati oskilki voni mayut znati yaki identifikatori mozhe vikoristovuvati domen Dlya poshtovogo agenta koristuvacha MUA trohi vazhche diznatisya yakim identifikatoram vin mozhe doviryati Oskilki koristuvachi mozhut otrimuvati elektronnu poshtu z kilkoh domeniv napriklad yaksho u nih ye kilka adres elektronnoyi poshti bud yakij z cih domeniv mozhe propuskati polya Authentication Results oskilki voni viglyadayut nejtralnimi Takim chinom zlovmisnij vidpravnik mozhe pidrobiti identifikator authserv yakomu koristuvach doviryav bi yakbi povidomlennya nadijshlo z inshogo domenu Spravzhni Authentication Results zazvichaj z yavlyayutsya vidrazu nad polem Received tim samim domenom z yakogo bulo peredano povidomlennya Dodatkovo Received polya mozhut z yavlyatisya mizh cim i verhnoyu chastinoyu zagolovka oskilki povidomlennya bulo peredano vnutrishno mizh serverami sho nalezhat tomu samomu dovirenomu ADMD Organ z prisvoyennya nomeriv Internetu vede reyestr parametriv avtentifikaciyi elektronnoyi poshti 7 kvitnya 2022 u Wayback Machine Odnak ne vsi parametri potribno reyestruvati Napriklad mozhut isnuvati lokalni znachennya politiki rozrobleni lishe dlya vnutrishnogo vikoristannya sajtu yaki vidpovidayut lokalnij konfiguraciyi i ne potrebuyut reyestraciyi Div takozhDMARC tehnologiya sho dozvolyaye otrimuvachu elektronnoyi poshti pereviriti spravzhnist yiyi vidpravnika Shifruvannya elektronnoyi poshti Ident protokol opisanij v RFC 1413 priznachenij dlya identifikaciyi koristuvacha yakij vstanovlyuye TCP z yednannya PrimitkiZapovnit propusheni parametri nazvu i abo avtoriv arXiv 1 kerner Sean Michael DMARC Email Security Adoption Grows in U S Government eWeek Procitovano 24 listopada 2018 workshop Federal Trade Commission November 9 10 2004 Arhiv originalu za 3 June 2012 Procitovano 4 lyutogo 2013 The Report however identified domain level authentication as a promising technological development Hang Hu Gang Wang 15 serpnya 2018 27th Security Symposium Arhiv originalu za 19 lyutogo 2022 Procitovano 19 lyutogo 2022 Shablon Cite IETF makelink Simple Mail Transfer Protocol Shablon Cite IETF makelink Sender Policy Framework SPF for Authorizing Use of Domains in E Mail Version 1 doi 10 17487 RFC7208 Shablon Cite IETF makelink Simple Mail Transfer Protocol doi 10 17487 RFC5321 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 Scott Kitterman 21 listopada 2009 spf help gossamer threads com Arhiv originalu za 7 travnya 2016 Procitovano 19 lyutogo 2022 I think it s generally fine as long as you offer a mechanism for whitelisting of non SRS forwarders Shablon Cite IETF makelink DomainKeys Identified Mail DKIM Signatures doi 10 17487 RFC6376 Dave Crocker 16 zhovtnya 2007 DKIM org Arhiv originalu za 29 veresnya 2017 Procitovano 17 lyutogo 2013 Shablon Cite IETF makelink DomainKeys Identified Mail DKIM Author Domain Signing Practices ADSP Barry Leiba 25 listopada 2013 IETF Arhiv originalu za 5 bereznya 2016 Procitovano 19 lyutogo 2022 Shablon Cite IETF makelink Vouch By Reference doi 10 17487 RFC5518 Shablon Cite IETF makelink Message Header Field for Indicating Message Authentication Status Shablon Cite IETF makelink Classless IN ADDR ARPA delegation doi 10 17487 RFC2317