Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
DomainKeys Identified Mail (DKIM) — технологія, що об'єднує декілька існуючих методів антифішингу і антиспаму, з метою підвищення якості класифікації та ідентифікації легітимної електронної пошти. Замість традиційної IP-адреси, для визначення відправника повідомлення, DKIM додає в нього цифровий підпис, пов'язаний з іменем домену організації. Підпис автоматично перевіряється на стороні одержувача, після чого, для визначення репутації відправника, застосовуються «білі списки» і «чорні списки».
У технології DomainKeys для аутентифікації відправників використовуються доменні імена. DomainKeys використовує існуючу систему доменних імен (DNS) для передачі відкритих ключів шифрування.
Історія
Проект DomainKeys започаткувала компанія Yahoo (20 травня 2004 була опублікована перша версія специфікації DomainKeys), а проект Identified Internet Mail ініціювала Cisco Systems. Близько року неформальне об'єднання з десятка організацій, включаючи Yahoo, Cisco, , Microsoft Corp., PGP Corp., , VeriSign Inc. і ., працювало над створенням нової специфікації DKIM. У липні 2005 року вона була передана в IETF, для розгляду як нового стандарту e-mail для боротьби з фішингом і спамом.
Структура DKIM
DKIM використовує зовнішні модулі для пошуку ключів і пересилання листів. В даній схемі визначається основний набір компонентів, необхідний для розгортання, що включає в себе DNS і SMTP.
Як показано на рисунку, основний процес обробки листів розділений на дві частини: створення ЕЦП листа і його перевірка.
- Підпис листа
- Процес створення ЕЦП і його додавання в лист здійснюється внутрішнім довіреним модулем ADMD (Administrative Management Domain), який для створення ЕЦП використовує добутий зі сховища закритий ключ, створений на основі інформації про лист. Як ADMD можуть виступати поштовий клієнт (MUA — Mail User Agent) або поштовий сервер (MTA — Mail Transfer Agent).
- Перевірка ЕЦП листа
- Верифікація ЕЦП також виконується довіреним модулем ADMD. Даний процес може виконуватися як на сервері, так і на стороні клієнта. Цей модуль перевіряє дійсність за допомогою відкритого ключа і визначає, чи потрібен підпис взагалі. Якщо дійсність ЕЦП підтверджено, то лист разом з інформацією про «репутацію» автора передається у фільтр повідомлень, в якому приймається рішення про те, чи є даний лист спамом, чи ні. У разі, коли для даного домену в листі ЕЦП відсутній або не проходить перевірку автентичності, то разом з додатковими інструкціями (наприклад, штрафні бали для антиспам-фільтра), отриманими з локального або віддаленого сховища, лист передається у фільтр повідомлень.
Якщо трапляється, що лист має більш ніж один справжній ЕЦП, то порядок, в якому застосовуються інструкції на підставі інформації про домени, яким належать дані підписи, вже визначається поза технологією DKIM.
Опис
Кожному повідомленню, що циркулює в DKIM системі, присвоюється ЕЦП, що не тільки підтверджує відправника, але і гарантує, що підписана частина не була змінена. Сам же процес обміну схожий на роботу з PGP. Власник домену генерує пару ключів — відкритий і закритий. Закритий ключ використовується на SMTP-сервері для додавання у повідомлення ЕЦП, який передається в заголовку DKIM-Signature і містить в собі інформацію про домен відправника. Приклад вихідного повідомлення:
From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe.
Після процедури створення ЕЦП повідомлення, підготовлене до відправки, приймає наступний вигляд:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com; h=From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [192.0.2.1] by submitserver.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe.
Поштовий сервер, що виконує підпис цього повідомлення, повинен мати доступ до закритого ключа, який пов'язаний зі значенням «brisbane» тегу "s=". Відкритий ключ додається в TXT-поле DNS-записи.
В процесі перевірки ЕЦП, з заголовка «DKIM-Signature» добувається домен «example.com», що зберігається в тезі "d=", і значення тегу перемикання "s=" — «brisbane» для формування запиту на перевірку для «brisbane._domainkey.example.com» Перевірка починається з поля «From», потім «To» і так далі, в порядку зазначеному в тезі "h=". Результат запиту та перевірки в даному прикладі записується в заголовок «X-Authentication-Results». Після успішної перевірки ЕЦП повідомлення виглядає наступним чином:
X-Authentication-Results: shopping.example.net header.from=joe@football.example.com; dkim=pass Received: from mout23.football.example.com (192.168.1.1) by shopping.example.net with SMTP; Fri, 11 Jul 2003 21:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com; h=From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [192.0.2.1] by submitserver.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe.
У DKIM використовуються вже усталені криптографічні інструменти. На цей час для цифрового підпису автори DKIM пропонують два алгоритми: RSA-SHA256 і RSA-SHA1, але в майбутньому можливе розширення технології, для підтримки інших алгоритмів. Довжина ключа обмежена значенням 4096 біт, оскільки більший за довжиною ключ не поміститься у максимальний розмір DNS UDP-пакета — 512 байтів. Рекомендована довжина ключа становить від 1024 до 2048 біт. Занадто велика довжина створює обчислювальне навантаження на сервер, для обробки кожного повідомлення, а надто мала (384 або 512 біт) — зламується перебором за актуальний час за допомогою ПК або з використанням сервісу хмарних обчислень.
Дана технологія сумісна з існуючою структурою мереж і не вимагає докорінної зміни сервісів (крім налаштування SMTP) і зміни протоколів, тому може бути введена поступово. Повідомлення, підписане DKIM є повністю «автономномне», функціонування DKIM не залежить від PKI або яких-небудь служб, оскільки ключ береться безпосередньо з DNS-запису і не повинен підтверджуватися чим-небудь. Організація, яка використовує DKIM, повністю несе відповідальність за роботу свого сервера, наявність ЕЦП означає лише те, що хтось відповідає за конкретне повідомлення.
Обмеження
В описі даної технології розробники підкреслюють, що наявність ЕЦП в повідомленні ні до чого не зобов'язує приймаючу сторону, не забезпечує захист після перевірки підпису і не може ніяк вплинути у разі повторної передачі повідомлення, якщо відправник і одержувач змінилися. Тому RFC рекомендують повідомлення зі звичайних серверів, які не підтримують DKIM, обробляти стандартним чином.
Слід зазначити, що ніхто не заважає спамеру створити свій SMTP-сервер, з підтримкою DKIM, і DNS-сервер, які з точки зору DKIM будуть легальними, але в цьому випадку домени з такого сервера швидко отримають «штрафні бали» і надалі будуть заблоковані спам-фільтром.
Див. також
- Sender Policy Framework (SPF)
- DMARC
- (S/MIME)
- PGP
Посилання
- Domain Keys Identified Mail (DKIM) [ 19 грудня 2020 у Wayback Machine.]
- IETF DKIM working group [ 17 липня 2017 у Wayback Machine.] (started 2006)
- RFC 4871 — The DKIM Base Specification [ 26 травня 2007 у Wayback Machine.]
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures [ 28 квітня 2013 у Wayback Machine.]
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
DomainKeys Identified Mail DKIM tehnologiya sho ob yednuye dekilka isnuyuchih metodiv antifishingu i antispamu z metoyu pidvishennya yakosti klasifikaciyi ta identifikaciyi legitimnoyi elektronnoyi poshti Zamist tradicijnoyi IP adresi dlya viznachennya vidpravnika povidomlennya DKIM dodaye v nogo cifrovij pidpis pov yazanij z imenem domenu organizaciyi Pidpis avtomatichno pereviryayetsya na storoni oderzhuvacha pislya chogo dlya viznachennya reputaciyi vidpravnika zastosovuyutsya bili spiski i chorni spiski U tehnologiyi DomainKeys dlya autentifikaciyi vidpravnikiv vikoristovuyutsya domenni imena DomainKeys vikoristovuye isnuyuchu sistemu domennih imen DNS dlya peredachi vidkritih klyuchiv shifruvannya IstoriyaProekt DomainKeys zapochatkuvala kompaniya Yahoo 20 travnya 2004 bula opublikovana persha versiya specifikaciyi DomainKeys a proekt Identified Internet Mail iniciyuvala Cisco Systems Blizko roku neformalne ob yednannya z desyatka organizacij vklyuchayuchi Yahoo Cisco Microsoft Corp PGP Corp VeriSign Inc i pracyuvalo nad stvorennyam novoyi specifikaciyi DKIM U lipni 2005 roku vona bula peredana v IETF dlya rozglyadu yak novogo standartu e mail dlya borotbi z fishingom i spamom Struktura DKIMDKIM vikoristovuye zovnishni moduli dlya poshuku klyuchiv i peresilannya listiv V danij shemi viznachayetsya osnovnij nabir komponentiv neobhidnij dlya rozgortannya sho vklyuchaye v sebe DNS i SMTP Yak pokazano na risunku osnovnij proces obrobki listiv rozdilenij na dvi chastini stvorennya ECP lista i jogo perevirka Pidpis lista Proces stvorennya ECP i jogo dodavannya v list zdijsnyuyetsya vnutrishnim dovirenim modulem ADMD Administrative Management Domain yakij dlya stvorennya ECP vikoristovuye dobutij zi shovisha zakritij klyuch stvorenij na osnovi informaciyi pro list Yak ADMD mozhut vistupati poshtovij kliyent MUA Mail User Agent abo poshtovij server MTA Mail Transfer Agent Perevirka ECP lista Verifikaciya ECP takozh vikonuyetsya dovirenim modulem ADMD Danij proces mozhe vikonuvatisya yak na serveri tak i na storoni kliyenta Cej modul pereviryaye dijsnist za dopomogoyu vidkritogo klyucha i viznachaye chi potriben pidpis vzagali Yaksho dijsnist ECP pidtverdzheno to list razom z informaciyeyu pro reputaciyu avtora peredayetsya u filtr povidomlen v yakomu prijmayetsya rishennya pro te chi ye danij list spamom chi ni U razi koli dlya danogo domenu v listi ECP vidsutnij abo ne prohodit perevirku avtentichnosti to razom z dodatkovimi instrukciyami napriklad shtrafni bali dlya antispam filtra otrimanimi z lokalnogo abo viddalenogo shovisha list peredayetsya u filtr povidomlen Yaksho traplyayetsya sho list maye bilsh nizh odin spravzhnij ECP to poryadok v yakomu zastosovuyutsya instrukciyi na pidstavi informaciyi pro domeni yakim nalezhat dani pidpisi vzhe viznachayetsya poza tehnologiyeyu DKIM OpisKozhnomu povidomlennyu sho cirkulyuye v DKIM sistemi prisvoyuyetsya ECP sho ne tilki pidtverdzhuye vidpravnika ale i garantuye sho pidpisana chastina ne bula zminena Sam zhe proces obminu shozhij na robotu z PGP Vlasnik domenu generuye paru klyuchiv vidkritij i zakritij Zakritij klyuch vikoristovuyetsya na SMTP serveri dlya dodavannya u povidomlennya ECP yakij peredayetsya v zagolovku DKIM Signature i mistit v sobi informaciyu pro domen vidpravnika Priklad vihidnogo povidomlennya From Joe SixPack lt joe football example com gt To Suzie Q lt suzie shopping example net gt Subject Is dinner ready Date Fri 11 Jul 2003 21 00 37 0700 PDT Message ID lt 20030712040037 46341 5F8J football example com gt Hi We lost the game Are you hungry yet Joe Pislya proceduri stvorennya ECP povidomlennya pidgotovlene do vidpravki prijmaye nastupnij viglyad DKIM Signature v 1 a rsa sha256 s brisbane d example com c simple simple q dns txt i joe football example com h From To Subject Date Message ID bh 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8 b AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr kHxt1IrE NahM6L LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp YzhwvcubU4 Received from client1 football example com 192 0 2 1 by submitserver example com with SUBMISSION Fri 11 Jul 2003 21 01 54 0700 PDT From Joe SixPack lt joe football example com gt To Suzie Q lt suzie shopping example net gt Subject Is dinner ready Date Fri 11 Jul 2003 21 00 37 0700 PDT Message ID lt 20030712040037 46341 5F8J football example com gt Hi We lost the game Are you hungry yet Joe Poshtovij server sho vikonuye pidpis cogo povidomlennya povinen mati dostup do zakritogo klyucha yakij pov yazanij zi znachennyam brisbane tegu s Vidkritij klyuch dodayetsya v TXT pole DNS zapisi V procesi perevirki ECP z zagolovka DKIM Signature dobuvayetsya domen example com sho zberigayetsya v tezi d i znachennya tegu peremikannya s brisbane dlya formuvannya zapitu na perevirku dlya brisbane domainkey example com Perevirka pochinayetsya z polya From potim To i tak dali v poryadku zaznachenomu v tezi h Rezultat zapitu ta perevirki v danomu prikladi zapisuyetsya v zagolovok X Authentication Results Pislya uspishnoyi perevirki ECP povidomlennya viglyadaye nastupnim chinom X Authentication Results shopping example net header from joe football example com dkim pass Received from mout23 football example com 192 168 1 1 by shopping example net with SMTP Fri 11 Jul 2003 21 01 59 0700 PDT DKIM Signature v 1 a rsa sha256 s brisbane d example com c simple simple q dns txt i joe football example com h From To Subject Date Message ID bh 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8 b AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr kHxt1IrE NahM6L LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp YzhwvcubU4 Received from client1 football example com 192 0 2 1 by submitserver example com with SUBMISSION Fri 11 Jul 2003 21 01 54 0700 PDT From Joe SixPack lt joe football example com gt To Suzie Q lt suzie shopping example net gt Subject Is dinner ready Date Fri 11 Jul 2003 21 00 37 0700 PDT Message ID lt 20030712040037 46341 5F8J football example com gt Hi We lost the game Are you hungry yet Joe U DKIM vikoristovuyutsya vzhe ustaleni kriptografichni instrumenti Na cej chas dlya cifrovogo pidpisu avtori DKIM proponuyut dva algoritmi RSA SHA256 i RSA SHA1 ale v majbutnomu mozhlive rozshirennya tehnologiyi dlya pidtrimki inshih algoritmiv Dovzhina klyucha obmezhena znachennyam 4096 bit oskilki bilshij za dovzhinoyu klyuch ne pomistitsya u maksimalnij rozmir DNS UDP paketa 512 bajtiv Rekomendovana dovzhina klyucha stanovit vid 1024 do 2048 bit Zanadto velika dovzhina stvoryuye obchislyuvalne navantazhennya na server dlya obrobki kozhnogo povidomlennya a nadto mala 384 abo 512 bit zlamuyetsya pereborom za aktualnij chas za dopomogoyu PK abo z vikoristannyam servisu hmarnih obchislen Dana tehnologiya sumisna z isnuyuchoyu strukturoyu merezh i ne vimagaye dokorinnoyi zmini servisiv krim nalashtuvannya SMTP i zmini protokoliv tomu mozhe buti vvedena postupovo Povidomlennya pidpisane DKIM ye povnistyu avtonomnomne funkcionuvannya DKIM ne zalezhit vid PKI abo yakih nebud sluzhb oskilki klyuch beretsya bezposeredno z DNS zapisu i ne povinen pidtverdzhuvatisya chim nebud Organizaciya yaka vikoristovuye DKIM povnistyu nese vidpovidalnist za robotu svogo servera nayavnist ECP oznachaye lishe te sho htos vidpovidaye za konkretne povidomlennya ObmezhennyaV opisi danoyi tehnologiyi rozrobniki pidkreslyuyut sho nayavnist ECP v povidomlenni ni do chogo ne zobov yazuye prijmayuchu storonu ne zabezpechuye zahist pislya perevirki pidpisu i ne mozhe niyak vplinuti u razi povtornoyi peredachi povidomlennya yaksho vidpravnik i oderzhuvach zminilisya Tomu RFC rekomenduyut povidomlennya zi zvichajnih serveriv yaki ne pidtrimuyut DKIM obroblyati standartnim chinom Slid zaznachiti sho nihto ne zavazhaye spameru stvoriti svij SMTP server z pidtrimkoyu DKIM i DNS server yaki z tochki zoru DKIM budut legalnimi ale v comu vipadku domeni z takogo servera shvidko otrimayut shtrafni bali i nadali budut zablokovani spam filtrom Div takozhSender Policy Framework SPF DMARC S MIME PGPPosilannyaDomain Keys Identified Mail DKIM 19 grudnya 2020 u Wayback Machine IETF DKIM working group 17 lipnya 2017 u Wayback Machine started 2006 RFC 4871 The DKIM Base Specification 26 travnya 2007 u Wayback Machine RFC 6376 DomainKeys Identified Mail DKIM Signatures 28 kvitnya 2013 u Wayback Machine