Видео: DMARC - Технически преглед

Събрали сме кратка технически преглед на DMARC:

Този видеоклип е част от по-голяма видео серия за всички неща DMARC.

Преписът следва:


Този кратък видеоклип е технически преглед на DMARC - Удостоверяване на съобщения на базата на домейни, отчитане и съответствие.

DMARC се опитва да създаде връзка между съдържанието на имейл и домейн, като се използва едно от двете SPF or DKIM, За любопитния зрител, SPF и DKIM са обхванати в отделни видеоклипове.

Съдържанието на имейла, което DMARC загрижен е домейнът, намерен в заглавката From: Заглавката From: е почти единствената група информация, която показва кой или къде идва имейл, който трябва да бъде в това, което се счита за „добре оформен имейл“. Заради това, DMARC ключове от домейна, намерен в заглавката From:

DMARC не изключва никое друго заглавие, включително заглавката Sender:. Оказва се, че допускането на множество ключове на политиката причинява много объркване и дори може да подкопае полезността на DMARC себе си и така DMARC изключва само домейна, намерен в заглавката From:

SPF и DKIM са двете технологии, които произвеждат стабилни идентификатори на ниво домейн. SPF и DKIM са свободно достъпни технически спецификации, които са имали широко приложение при много различни доставчици на имейл. Въпреки че работят по различни начини, DMARC се интересува само от резултатите, които те произвеждат, и ако тези резултати имат нещо общо с домейна, намерен в заглавката From: Резултатите, които са произведени от SPF и DKIM се наричат ​​„удостоверени идентификатори“ в света на DMARC.

Ключова концепция за DMARC е „Подравняване на идентификатора“. Това е просто фантастичен начин да се каже, че резултатите от SPF и DKIM трябва да са свързани с DMARC домейн, за да бъде полезен. Основната причина за това е, че приемниците се нуждаят от прост начин да разберат дали резултатите от SPF и DKIM са от значение за домейна, който DMARC ключове от.

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

В този първи пример получател на имейл получи част от имейла, където DMARC домейн (който е домейнът, намерен в заглавката From:) е „bank.com“. Освен това SPF чекът даде домейн от „bank.com“. Нямаше DKIM подпис върху имейла, така че нашият ред е маркиран с „няма“. Получателят на имейл търси всякакъв положителен сигнал, че имейлът може да бъде проследен до домейна на bank.com и имейл приемникът не се интересува дали този сигнал идва от SPF or DKIM - само докато сигналът е там. В този пример автентифицираният идентификатор, дошъл от SPF беше „bank.com“ и това съвпада точно с DMARC домейн и така имейлът е съвместим DMARC.

В този следващ пример всичко е почти същото, с изключение на удостоверения идентификатор, който SPF добив е поддомен на bank.com - mail.bank.com. За човешкото същество плът, двете области са очевидно свързани. Оказва се обаче, че в Интернет няма стандартен начин да се разбере дали bank.com е домейн от най-високо ниво като .com или .org или дали неговият домейн от второ ниво. Няма стандартен начин да разберем това. Друг пример е bank.co.uk. Няма начин да се каже, че „co.uk“ е домейн от най-високо ниво. В света на DMARC, нещото, което е домейн от второ ниво, се нарича Организационен домейн. Чрез изтегляне на някои ресурси от Интернет - по-специално публичния списък с наставки, поддържан от Mozilla Foundation - получател на имейл може да разбере, че bank.com е домейнът на организацията и че mail.bank.com е поддомен, който споделя същият организационен домейн като bank.com. В този случай имейлът е съвместим DMARC.

Този пример на 3rd показва нещо интересно. Вместо SPF давайки удостоверен идентификатор на bank.com или поддомен на bank.com, удостовереният идентификатор е banknewsletter.com. За всичко, което знаем, banknewsletter.com е истински домейн, собственост на и управляван от същото предприятие, което е собственик на bank.com. ИЛИ…. banknewsletter.com е собственост и се управлява от престъпници, които искат да подмамят хората да мислят, че са законни. Просто няма начин за надеждно поддържане и комуникация на такива асоциации между домейните - или от самите изпращачи, създаващи бази данни на асоциации, или от приемници, поддържащи свои собствени - и двете са задачи, които биха били изпълнени с неточности и в основата си подкопават полезността на DMARC, И така, този имейл НЕ е съвместим DMARC и ще бъдат засегнати от публикувано DMARC политика.

За да продължите с примера на 4th, имейлът е същият, с изключение на сега, когато виждаме DKIM подпис за първи път. В този пример, DKIM даде автентифициран идентификатор на bank.com, което прави примера съвместим с DMARC, Тоест, получателят на имейла разглежда автентифицирания идентификатор, който е дошъл SPF и вижда, че banknewsletter.com няма нищо общо с bank.com и просто го игнорира. Тъй като получателят търси какъвто и да е положителен сигнал, че съобщението наистина е дошло от bank.com и DKIM предоставя такъв сигнал, имейлът предава DMARC проверите.

Този пример 5th показва имейл, който е DMARC по целия път. И двете SPF и DKIM издава удостоверени идентификатори на bank.com. Приемникът се интересува само от намирането на положителен сигнал, така че наличието на положителни сигнали 2 е двойно по-добро, но не означава нищо повече от „положителен сигнал“. Причината за изпращане на имейл, където и двете SPF и DKIM дават правилни резултати, защото наличието на двете технологии на разположение дава възможност имейл да продължи да бъде DMARC съвместими, дори ако едно или друго - по някаква причина - не е на разположение или се провали.

Този пример на 6th показва едно и също нещо с разликата, че „news.bank.com“ е удостовереният идентификатор и за двете SPF и DKIM, Доста често срещана практика е големите организации да делегират поддомен на доставчик на имейл услуги, така че доставчикът на услуги да може да изпраща имейл от името на организацията. В този пример собствениците на bank.com може да са делегирали поддомейн „news“ на своя маркетинг доставчик, така че доставчикът да може да изпрати DMARC съвместим имейл с помощта на bank.com.

Този измислен пример показва, че всеки може да регистрира домейни и да постави SPF и DKIM на място. Не би ли било хубаво, ако лошите използват такива очевидни домейни? И все пак, просто защото SPF и DKIM преминаване и предаване на удостоверен идентификатор не означава, че имейлът е добър или желан.

Последният пример тук показва това SPF даде автентифициран идентификатор на "bark.com" ... както в звука, който издава кучето. Това е добре известна атака, която някои измамници използват, за да подмамят хората, които ръчно инспектират имейли за да определят легитимността. Един бърз поглед може да измами окото и да накара някой да си помисли, че кората наистина е банка. Още по-лошото е, че е възможно да се използват някои трикове за кодиране на символи, така че изобразените глифи да изглеждат точно като предвидения домейн. Машините не се заблуждават от този вид tom-foolery, поради което машините трябва да извършват проверки за подравняване на идентификаторите, а не хората.

Преди да влезем в какво DMARC записите изглеждат и какво могат да направят, ще се спрем накратко как DMARC са открити записи.

Когато получател на имейл обработва част от имейла в контекста на DMARC, получателят ще извлече домейна, намерен в заглавката From: Този домейн представлява основата на това, в което получателят търси всяко съответно DMARC запис. Приемникът ще извади префикс на underbar-dmarc към домейна и ще поиска DNS за TXT запис.

В показания тук пример извлеченият домейн е EUROPE.ENG.EXAMPLE.ORG. Получателят ще добави underbar-dmarc към този домейн и ще поиска DNS да се опита да намери TXT запис. Но какво става, ако заявката води до нищо или до TXT запис, чието съдържание няма нищо общо DMARC, След това получателят ще извлече организационния домейн от домейна ... в този случай EXAMPLE.ORG и ще опита отново да намери DMARC запис, като затваряте под-dmarc пред домейна и запитвате за TXT запис.

По този начин, DMARC Откриването на записи е ограничено до търсене в 2 DNS. Поради това има и някои изящни последствия. Можете да публикувате сингъл DMARC запишете на ниво Организационен домейн и го накарайте да покрива всички и всички поддомейни. Няма значение дали спамърът създава свои поддомейни, пак можете да публикувате DMARC запис, който ги обхваща, без да е необходимо да се публикуват изрично DMARC записи за всички въображаеми поддомейни. Другото изящно нещо е, че можете да публикувате DMARC записи за всички ваши реални поддомейни и тези DMARC записи ще отменят публикуваното на ниво Организационен домейн.

Добре, сега на какво DMARC записи изглеждат и какво могат да направят.

DMARC записи са прости списъци на двойки тагове / стойност. В този пример, домейнът, който публикува това DMARC запис ... можем да му кажем a DMARC запис, защото започва с „v =DMARC1; ”… публикува политика“ няма ”и иска да бъдат изпратени всички обобщени отчети на базата на XML до reports@example.org за обработка. DMARC е създаден, за да позволи на домейните да събират информация, без да се засяга имейл ... и това е направено - чрез публикуване на p=none политика.

По отношение на какво DMARC записи могат да се правят, опциите са доста прости. всичко DMARC записите трябва да започват с маркер за версия на протокола. След това политиката може да бъде конфигурирана, можете да конфигурирате политика, която ще се прилага към всички поддомейни…. например, ако знаете, че вашият домейн никога не използва поддомейни, можете да публикувате sp=reject правите веднага, докато само използвате данни за вашия домейн на организацията p=none, Pct тагът е като плъзгач, който преминава от 0 към 100, така че всяка публикувана политика може да бъде бавно разгърната ... ако кажете pct = 1, тогава само 1 от всеки имейл на 100, който в противен случай би бил засегнат DMARC политиката ще бъде засегната.

Можете също да конфигурирате дали удостоверените идентификатори, предоставени от или не SPF и DKIM се изисква точно да съответстват на DMARC домейн. По подразбиране „спокоен“ се предпочита почти във всички случаи, но в „строг режим“ можете да забраните Подравняване на идентификатора, което се основава на поддомейни, може би ако сте в среда, в която нямате контрол върху изпратения имейл използване на делегирани поддомейни.

Следващите два маркера, rua и ruf, се използват, за да кажат на света къде да изпращат отчети за домейна. Тъй като отчетите са различни, хората изпращат отчетите на различни имейл адреси за събиране и анализ.

Последните тагове са свързани с конфигурирането на формати за отчитане, интервали и кога да се изпращат редактирани копия на отделни имейли, които не са успешни DMARC, Първите два маркера имат само 1 стойност и следователно са малко безполезни, а последната опция се появява, за да деактивирате генерирането на отчети от някои доставчици на отчети поради програмни грешки, така че може би ги оставете, ако искате да ги съберете.

Добре, ще завършим този преглед с различните правила, които DMARC позволява и с кратък поглед към 2 различни отчети за обратна връзка, които DMARC осигурява.

DMARCОпциите за политика са много прости. Можете да публикувате политика „няма“, която просто означава „моля, изпратете ми отчети, без да действате по имейл, който не успява DMARC проверете ". Можете да публикувате политика за „карантина“, която насочва приемниците към папка със спам всеки имейл, който не успява DMARC проверите. Ако папка със спам не съществува, приемникът може да направи всичко възможно, за да третира съобщението с по-висока степен на подозрение, като повишаване на агресивността на сканиране срещу спам.

Последната политика, която може да се приложи, е политиката „отхвърляне“, която насочва приемниците да блокират - или отказват да приемат - имейл, който не успява да DMARC проверите. В един от екраните ще видите малко повече за pct тага и как ако го използвате с вас има въведена политика за отхвърляне, тогава какъвто и процент на имейл, който не е отхвърлен поради процентния маркер, вместо това да бъде под карантина.

Последно нещо, 2 формите за обратна връзка съобщават това DMARC могат да предоставят са много различни. Обобщените отчети на базата на XML се генерират на часовия цикъл на 24 и включват изчерпателна статистика за това как даден имейл приемник вижда вашия домейн - включително всички имейли, които са преминали изцяло DMARC, Видът на обратна връзка на 2nd се състои от преработени копия на отделни имейли, които не са успешни SPF, DKIM или и двете. Тези отчети не винаги са достъпни поради опасения за поверителност, опасения за обем или мнение, че не се изисква да получават DMARC разположени точно.

dmarcian обработва и двата вида обратна връзка, за да направи DMARC лесен за разгръщане. Въпроси за DMARC или dmarcian услугата ще бъде отговорена с радост.

За да започнете DMARC, Посетете dmarcianДа.

Въпроси? свържете се с поддръжката @dmarcian. С
Социален? dmarcian е в Linked-in, G +, twitter и може би повече.
Благодаря ви, че гледахте!