dxdt.blog: занимательный интернет-журнал

Air gap (“воздушный зазор”) – это ситуация, когда между двумя узлами не просто отсутствует сетевое соединение, но оно отсутствует на физическом уровне: например, защищаемый компьютер не подключен к сетям проводами, а может даже и к сети электропитания подключен через специальную развязку. Главное: предполагается, что, из-за отсутствия физического подключения к сети передачи данных, данные не утекают, а также и не могут “притечь” зловреды снаружи. Есть разные современные техники преодоления “воздушных зазоров”, но нередко забывают про то, что, исторически, всякие зловреды, как раз, долгое время только через “воздушный зазор” и распространялись массово – это “классические” компьютерные вирусы, ходившие от ПК к ПК на дискетах.

Часто попадаются в публикациях СМИ утверждения, что, якобы, это особенность “open source” в том, что в такие библиотеки и другое ПО включают “вредоносные возможности”. Но это не так. Модель распространения ПО никак не связана с возможностью добавления “вредоносного кода”: добавить такой код можно и в исходники, и в скомпилированный исполняемый код, а добавить что-то такое в скомпилированный код даже может быть проще, поскольку исходники ещё собирать кто-то будет и “зловредная нагрузка” может не собраться, собраться не так или не попасть в исполняемый код.

В подобных сообщениях СМИ, конечно, перепутаны подходы и термины. Открытый исходный код (Open Source) – это открытый исходный код. ПО, поставляемое с открытым исходным кодом, может быть проприетарным и коммерческим. Проблемы, о которых изначально шла речь, связаны с моделями и способами разработки кода, под открытостью тут подразумевается даже не свободная лицензия, а то, что, потенциально, любой желающий может предложить доработки и изменения. Но не факт, что предложенное будет принято безо всякой проверки. При этом в разных проектах устроены различные процессы проверки, той или иной степени защиты.

Естественно, трудности вызывает современное разделение по библиотекам и направлениям, которое приводит к тому, что возникает “развесистая” система зависимостей, за которой очень сложно, – даже невозможно, – уследить. Хрестоматийным примером тут является “экосистема” Node.js, где едва ли не под каждую элементарную подпрограмму делается отдельный “модуль”, а количество “вложенных зависимостей” очень велико. Но, естественно, речь не только про Node.js. Источники могут использовать самые разные правила добавления кода, а бывает так, что одиночная небольшая библиотека встроена в тысячи продуктов, которые тянут её код с собой. И вот, предположим, исходный репозиторий этот библиотеки оказался заброшен, а потом был взломан. Взломавший теперь получает возможность потенциальной инъекции произвольного кода в те самые тысячи продуктов. Но такая инъекция всё же может быть обнаружена.

Самое интересное, что сейчас во многих и многих программных продуктах, распространяемых в “бинарном исполняемом коде”, даже с закрытыми (условно) исходниками, всё равно присутствуют различные библиотеки из Open Source. Это касается и операционных систем, да даже и Windows. Про то, как можно рассматривать открытые исходники и “бинарный код” с точки зрения ИБ – я недавно публиковал отдельную записку. Но главное, не нужно смешивать “открытые исходники” (Open Source) с проблемами неконтролируемого добавления кода в некоторых способах коллективной разработки, равно как и с самой возможностью добавления “вредоносного кода” – такой код добавить можно и в виде “бинарной” вставки (то есть, фрагмента машинного кода).

Немного киберпанка. Одним из направлений, связанных с перспективными системами управления “цифровыми финансами”, является ограничение платежей по месту “мгновенного” географического нахождения пользователя, который пытается что-то оплатить. Речь не об обнаружении “поддельных” попыток оплаты с чужими реквизитами, а о допусках для легитимного пользователя. То есть, если авторизованный пользователь находится за пределами, предположим, своего города, то он не может распоряжаться средствами (или частью средств) в данной цифровой платёжной системе. Как такое может быть реализовано? Понятно, что для управления финансами пользователю выдали устройство, – смартфон с приложением, предположим, – которое имеет встроенный навигационный модуль и определяет своё географическое положение. Для совершения транзакции геопривязку нужно подтвердить. Это, в принципе, можно сделать с использованием той или иной спутниковой навигационной системы. Почему ограничения должны вводиться именно на стороне пользователя? Потому что товары и услуги он может заказывать у организаций в режиме онлайн, а серверы организации могут находиться где угодно (это допускается). Конечно, ограничивать можно по месту получения товара/услуги – это место, допустим, указывается при заказе (доставка и пр.). Однако, во-первых, не всем товарам и услугам можно сопоставить место получения, во-вторых – получателем может быть другое лицо (ограничение на получателя покупок пока что не вводим).

Вернёмся к варианту с глобальной спутниковой навигационной системой. Для подтверждения местоположения в навигационный сигнал может быть встроен некий код аутентификации, конфигурация которого определяет местоположение приёмника. Это выглядит слишком сложно, тем более, например, в случае GPS: сигналы можно подделывать; можно записывать в одном месте, а транслировать в другое (что, кстати, снижает эффективность геопривязки по простым локальным радиомаякам, про которые тут можно подумать). Но если удастся на соответствующем уровне полностью объединить сетевой транспорт передачи данных с системой определения местоположения, то найти решение уже проще: сама доверенная сеть, доставляющая входные данные о финансовой транзакции, будет сопровождать их необходимой аутентифицированной геопривязкой.

Не подумайте, что ничего такого нет и это всё фантастика: тот же Starlink, например, использует такие технологии – они просто необходимы для того, чтобы сеть работала эффективно. Фактически, при предоставлении связи, такая сеть из многих низкоорбитальных спутников знает точное местоположение всех своих терминалов. (Это, например, означает, что подобная спутниковая система, предоставляющая доступ “через смартфоны”, в реальном времени видит местоположение всех пользователей; ну, с точностью до смартфона, конечно.) То есть, получаем спутниковый канал и для осуществления финансовых транзакций, и для доверенного подтверждения местоположения источника транзакции. Сочетание “смартфон-приложение-сеть” – имеет важное значение, но, в принципе, такие системы уже даже готовятся (с учётом того, что это наверняка потребует корректировки протоколов мобильной радиосвязи и обновления оборудования, но это детали).

Предположим, что пользователь оставил устройство, выданное для оплаты, в области, где использование финансовых средств разрешено, а сам куда-то переместился и пытается управлять устройством дистанционно, через те же самые “интернеты”. Что тут можно поделать? Напрашивается самый простой вариант: биометрическое подтверждение – чтобы предъявить свои биометрические показатели, предположим, пользователь должен быть рядом с устройством. Да, транслировать “через расстояния” сведения о биометрии можно, как можно и записать нужные “образцы” заранее. Однако, при правильной аппаратной архитектуре пользовательского устройства и при хорошей схеме протоколов авторизации платежей, сделать это станет весьма непросто: задача, скорее всего, перестанет иметь автоматическое решение для рутинных операций.

Многое зависит и от того, насколько хорошо контролируются сети передачи данных: понятно, что финансовое приложение и элементы системы, которые пользователь пытается обмануть, вполне себе могут получать сведения об источнике “обманывающего” подключения. Заметьте, что тривиальное использование средств удалённого доступа подобные приложения пытаются детектировать уже сейчас. Всё гораздо строже и точнее в конфигурации, где функции контроля встроены даже не на уровне операционной системы (это само собой), но на уровне аппаратного модуля радиоканала: понятно, что устройство-то видит входящие подключения, а сеть передачи данных, в общем случае, обладает информацией о том, откуда такое подключение происходит (в данном случае достаточно обнаружить сам факт подключения, то есть, какие-нибудь “сети перемешивания” – не эффективны). И, конечно, не стоит списывать со счетов не менее аппаратные внешние устройства “съёма” биометрических показателей, типа продвинутых “фитнес-браслетов”. Так что подобную географическую привязку “цифровых финансов” реализовать можно, да ещё и с несколькими слоями защиты.

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

Бортовое ПО становится всё сложнее, оно уже полностью управляет движением автомобиля, при этом недокументированных возможностей там будет всё больше. Конечно, должны быть какие-то процедуры проверки при сертификации, но эффективность подобных мер в автомобильной индустрии, понятно, не велика; тем более, что обнаружить хорошо скрытые недокументированные возможности в сложном ПО сторонней разработки – не слишком-то реально. Поэтому дальше будет интереснее, в том числе, с автомобилями-такси: одно дело, если специалисту известна некоторая комбинация кнопок управления пассажирским лифтом, нажав которую можно избежать промежуточной остановки кабины, совсем другое – когда, подключившись по радиоканалу (WiFi, Bluetooth) к стоящему рядом в пробке самоуправляемому автомобилю-такси, можно будет направить этот автомобиль в какую-нибудь неожиданную точку на карте, прямо вместе с ничего не подозревающими пассажирами, запертыми внутри.

Со всем этим принятием решений по данным от ИИ (Искусственного Интеллекта) не радует вот какой момент: та или иная система ИИ – это необозримый набор коэффициентов, с миллиардами связей, который непонятно как устроен внутри. Конечно, уже есть направления исследований, предполагающие изучать “внутреннее распределение” этих коэффициентов, с прицелом на извлечение чего-то содержательного; может быть, даже с выдачей доказательного объяснения того или иного “решения”, сформированного ИИ. Но пока что больше заметен “хайп”, а что касается “доказательного объяснения” – ну, скорее всего, тут всё сведётся к генерированию автоматом очередного текста в ответ на запрос: “подскажи, как это всё мотивировать и объяснить”.

ИИ сидит в компьютере. Широко известно, что “компьютер не может ошибаться”. Инструменты поддержки принятия решений могли бы приводить к тому, что принимающая решение сторона процесса чему-то научится, так как сможет понять, почему именно такое решение принято (сможет – потому что на то и “поддержка принятия решений”, но это детали). Это приведёт к формированию крупицы опыта. Казалось бы. Но не в случае с ИИ: что там внутри набора коэффициентов – непонятно. Почему такие выводы – не известно, но “компьютер так посчитал”. Проблема с “обучением нейронок” и в том, что в результате как бы “обучения”, повышающего внутреннюю сложность “нейросетки”, не возникает нового знания, однако ещё хуже с выдачей, с результатами работы “обученных нейронок”: ИИ принципиально не делится опытом, потому что опыта там нет. А вот центральное управление принимаемыми решениями через бэкдор, заложенный в саму систему, это расклад весьма вероятный. Тем более, особых сомнений в том, что широта практического применения ИИ в условиях Нового средневековья будет увеличиваться – нет.

Рассказывают, что самоуправляемые автомобили-такси (например, “Яндекса”, но тут это не так важно) не зависят от помех GPS и “не подвержены кибератакам”, так как используют для навигации автономные системы, установленные непосредственно на автомобиль. Под “кибератаками”, судя по всему, имелось в виду дистанционное вмешательство через сети связи. Несомненно, идея обеспечить движение такого автомобиля без использования “внешней” спутниковой навигации – здравая и очень правильная. Инерциальная система и способность привязки к карте по окружающей конфигурации объектов – это гораздо надёжнее, чем спутниковый сигнал, который сегодня ещё есть, но уже в полдень начинает показывать на тыквенные поля, находящиеся далеко за пределами города.

Другое дело, далеко не факт, что конкретный самоуправляемый автомобиль-такси действительно умеет привязываться к карте по данным видеокамер и лидаров. Технически это реализовать можно, но вот на основе спутниковой системы, с минимальной локальной коррекцией по наличию туннелей и эстакад, а также по свежим бордюрам и другим автомобилям, двигаться проще. Однако эта записка о другом аспекте проблемы. Предположим, что самоуправляемый автомобиль-робот всё же имеет автономную навигацию, а кроме того – не подключен к сетям передачи данных общего пользования (типа Интернета). Какие направления кибератак остаются? А остаются самые интересные.

Автомобиль-робот так или иначе вынужден действовать под управлением (с некоторой степенью эффективности) внешних, дистанционных сигналов. Просто, сигналы эти поступают через видеокамеры, лидары/радары и прочие датчики. Так, автомобиль, предположим, использует системы машинного зрения, чтобы определять собственное положение и даже скорость (как вектор), а также и наблюдать окружающую обстановку. Злоумышленник может попытаться эти системы обмануть. Вполне себе кибератака. Описано множество вариантов, начиная от человека в футболке с нарисованным дорожным знаком и вплоть до контрастных рисунков вдоль дороги, которые активируют “недокументированные возможности”. Второй вариант, кстати, вовсе не выглядит фантастичным – скажем, автомобиль, обнаружив соответствующий рисунок на стене дома, начинает двигаться прямо на этот самый рисунок. Естественно, в последний момент его останавливает встроенная аварийная система. Или не останавливает. Впрочем, основным полезным свойством всякого автопилота в автомобиле, действующего в помощь водителю, должно являться противодействие попыткам “врезаться в стену”. Вот только в самоуправляемом автомобиле нет водителя.

Лидары и радары, установленные на самоуправляемом автомобиле, тоже представляют собой канал для внешних кибератак. Помеха для радара (лидара) может быть простой пассивной, например, внезапно раскрываемый на том или ином направлении отражатель необычной конфигурации (в теории, можно имитировать фантомный автомобиль или пешехода). Возможны и хитрые активные помехи, ничуть не хуже случая с GPS. Активные помехи сложнее формировать, однако составляющий их сигнал будет доставляться в системы автомобиля и, сколь бы странным это сейчас ни казалось, не очень-то трудно поверить даже в RCE-атаки (удалённое исполнение кода) на этом направлении в не столь отдалённом будущем (если, конечно, развитие систем продолжится). Кстати, куда более вероятным транспортом для RCE тут являются разнообразные радиосигналы, которые планируется использовать для обмена информацией между самоуправляемыми автомобилями. Само направление кибератак по радиоканалам – ничем не отличается от старинной темы автомобильных сигнализаций и систем “бесключевого” доступа. Впрочем, последние сейчас уже прошли соответствующие этапы эволюции и позволяют организовать взлом через каналы связи, предназначенные для приложений в смартфоне, а значит, не подходят под ограничение, установленное в начале этой заметки – не использовать подключение к Интернету. Если, конечно, “бесключевой” доступ не реализован при помощи bluetooth-соединения. И этот второй аспект приводит нас к очередному направлению кибератак на автомобили-роботы, особенно, на такси.

Сети есть внутри автомобиля. Кто сказал, что взломанный смартфон пассажира не может сыграть роль узла-прокси, открыв доступ “из Интернета”? Никто такого не скажет: вполне возможно, что подобный проксирующий бот, действующий через подключение к системе развлечения (“хочу свою музыку ставить”) внутри автомобиля-робота, как раз и обеспечит нужный канал для злоумышленников. Дальше, конечно, предстоит оценивать возможности по проникновению из “развлекательного” сегмента в сети управления. Согласно различным рекомендациям, сети эти должны быть разделены на физическом уровне. Соблюдается ли данное правило? Не факт.

Сообщают, что “Яндекс” в своих навигационных приложениях начал как-то учитывать влияние спуфинга GPS, используя дополнительные данные (WiFi и пр.). Кстати, я в 2018 году писал, что “центральный сервер мог бы определять наличие GPS-спуфинга на основе анализа данных, поступающих от множества устройств”. Вообще, не ясно, занимается ли чем-то таким сервис “Яндекса”, но если у вас есть множество устройств и центральная точка сбора данных, то можно разные интересные вещи измерять.

Так, навигационное поле, формируемое гражданским сигналом GPS, можно достаточно точно рассчитывать для произвольной точки поверхности Земли, в том числе, с опережением или отставанием по времени. Для этого не нужно устанавливать приёмник в той точке, для которой выполняется моделирование. Да, тут необходимо подчеркнуть, что это всё за вычетом искажений, вносимых постройками и пр. – но, собственно, в этом и состоит интересная часть. К сожалению, от обычного смартфона не удастся получить детальной информации о сигнале GPS, как его видит приёмник, но, тем не менее, часть данных, коррелирующих с сигналом, всё же приходит. Смартфон может дополнительно собирать сведения о сигналах WiFi, о GSM, о передатчиках Bluetooh (и не только). Так вот, если у вас есть устройства “на местах”, которые приносят дополнительную информацию, а не только “координатные данные” GPS, то можно на центральном сервере выстраивать динамику изменения реального навигационного поля по сравнению с моделью, учитывающей только положение и состояние спутников. Это позволяет не просто получить корректирующую величину для всех участников системы, но также увидеть возникающие на местах пространственные дефекты и искажения с развёрткой по времени (то есть, не просто спуфинг), что весьма ценно.

Кстати, метки (“водяные знаки”), которые позволят определять тексты, сгенерированные системами ИИ (LLM), прежде всего полезны самим разработчикам этих систем: так они смогут избежать “обучения” новых “моделей из нейросетей” на текстах, сгенерированных другими системами ИИ (ну, или предыдущими итерациями одной и той же ветки). Подобное “обучение” второго и третьего порядка может привести к нежелательным результатам. Если всё направление раньше не развалится. Естественно, это относится не только к текстам, в традиционном понимании, но и к изображениям, звукам. Однако, с точки зрения такого подхода к обучению ИИ, всё – текст.

На скриншоте ниже – результат работы нехитрой программы на языке Python, которая вычисляет в точке x == i (мнимая единица) значение функции, известной как j-инвариант – j(x).

j(x) – это модулярная функция, которая важна, например, в теории эллиптических кривых, но в настоящей заметке теоретические детали не играют существенной роли. Значение j(x) для мнимой единицы – это целое число 1728 (в каком-то смысле, по определению). А 1728 == 12^3, что тоже не является простым совпадением, так как 12 == 2^2 * 3. Можно j(x) записать в виде бесконечной суммы (разложение Фурье или q-expansion, если хотите, где q == exp(2*π*i*x)), что и используется в программе: j(x) == q^(-1) + 744*q^(0) + 196884*q^1 + 21493760*q^2 + 864299970*q^3 +… Коэффициенты – целые числа.

Поскольку модулярные формы имеют большое значение в арифметике, коэффициенты из разложения j-инварианта проявляются в математике довольно неожиданным образом, порождая даже отдельные направления (как в случае “Чудовищной бурды” – Monstrous Moonshine, самогон, который в русскоязычной “Википедии” едва не превратился в “Монструозный отблеск”). Но это тема для другой записки, более подробной. Здесь же отметим, что так как коэффициенты – целые числа, можно взять их побольше (например, 42) и посчитать значение j(x) “численными методами”, проверив, сойдётся ли, и насколько быстро, результат. Понятно, что если в выражение для q (см. выше) подставить x == i, вместо i*i получится -1, что и делает каждый очередной элемент суммы всё меньше и меньше, несмотря на увеличивающиеся коэффициенты.

Однако здесь есть хитрости. Если использовать обычные настройки Python, то точности для вычислений не хватает, результат не сходится. Если взять math.exp() и math.pi, точность по умолчанию, получаем 1728.000000000000014825929946, причём ещё на 13 шаге суммирования – не очень-то хороший результат: больше чем 1728. Увеличение точности само по себе тут не помогает, нужно использовать модуль decimal и ввести достаточно длинные значения для π и e, заменив math.exp() и math.pi на Decimal(E**(Decimal(-2)*Pi))**n, где E и Pi – значения со многими знаками после запятой. Точность в decimal устанавливается при помощи getcontext().prec. Результат со скриншота получен для prec = 81 в Python 3.5. Всё это хорошо иллюстрирует, что компьютеры не считают в действительных числах.

Исходный код (проверьте, что символы табуляции не были “съедены” так же, как и некоторые цифры десятичного разложения):

from decimal import Decimal, getcontext
getcontext().prec = 81
Pi =	Decimal('3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982')
E =	Decimal('2.718281828459045235360287471352662497757247093699959574966967627724076630353547594571382178525166427427')
M = [
1, 744, 196884, 21493760, 864299970, 20245856256, 333202640600,
4252023300096, 44656994071935, 401490886656000, 3176440229784420,
22567393309593600, 146211911499519294, 874313719685775360,
4872010111798142520, 25497827389410525184, 126142916465781843075,
593121772421445058560, 2662842413150775245160, 11459912788444786513920,
47438786801234168813250, 189449976248893390028800, 731811377318137519245696,
2740630712513624654929920, 9971041659937182693533820, 35307453186561427099877376,
121883284330422510433351500, 410789960190307909157638144, 1353563541518646878675077500,
4365689224858876634610401280, 13798375834642999925542288376, 42780782244213262567058227200,
130233693825770295128044873221, 389608006170995911894300098560, 1146329398900810637779611090240,
3319627709139267167263679606784, 9468166135702260431646263438600, 26614365825753796268872151875584,
73773169969725069760801792854360, 201768789947228738648580043776000, 544763881751616630123165410477688,
1452689254439362169794355429376000
]
j = Decimal(0)
n = -1
for c in M:
	j = j + Decimal(c) * Decimal(E**(Decimal(-2)*Pi))**n
	print("j = ", j)
	n = n + 1
print("j^(1./3) =", float(j)**(1./3))

“Демультиплексирование” на общем номере порта TCP протоколов более высокого уровня (TLS/XMPP/SSH и т.п.) при помощи сигнатур начальных пакетов, описываемых регулярными выражениями, имеет и особенности “в другую сторону”: всё, что можно на уровне сокета разобрать (статическим) регулярным выражением на стороне сервера, можно быстро разобрать регулярным выражением и на стороне системы DPI. Естественно, в модели, приписывающей существенный вес номеру порта TCP в классификаторе протоколов, такой программный демультиплексор на серверной стороне был бы достаточно эффективен, но в более широком понимании – метод слишком далёк от стеганографического.

Технологии DKIM и DMARC предназначены для управления политиками доставки электронной почты, но подходят к этой задаче с разных сторон. DKIM (DomainKeys Identified Mail) – позволяет сопроводить сообщение электронной почты некоторым доказательством, что отправляющий сервер имеет отношение к домену, который указан в качестве источника сообщения, что этот сервер знает некоторый секретный ключ. Для предоставления доказательств используется цифровая подпись и публикация в DNS соответствующих открытых ключей для проверки подписи. Нужно учитывать, что это “техническая” подпись: она может, косвенно, подтверждать подлинность сервера-источника сообщения, целостность каких-то технических элементов сообщения (в том числе, целостность полезного содержания), однако используется в контексте серверов, то есть, это не подтверждение для конкретного адреса отправителя или пользователя почтовой системы.

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

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

Заметьте, что наличие или отсутствие DKIM не вводит каких-то технических обязательств на принимающей стороне: технически, DKIM – это дополнительные поля (заголовки) в не менее техническом конверте, сообщение всё равно приходит на принимающий сервер обычным способом, а этот принимающий сервер прекрасно может игнорировать заголовки DKIM. То есть, включение DKIM вовсе не влияет на базовые механизмы доставки почты, это протокол уровня политик, в его работе всё зависит от настроек, используемых сторонами.

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

Пример, хорошо иллюстрирующий ситуацию: администратор домена не планирует использовать этот домен в качестве почтового, поэтому требуется устроить так, чтобы принимающие серверы, поддерживающие DMARC (важная оговорка!), отбрасывали все сообщения с адресами из данного домена. В таком случае, администратор просто публикует строгую политику обработки DMARC (“reject”), но вовсе не размещает в DNS ключи DKIM и даже не настраивает почтовый сервер. То есть, администратор домена не предполагает отправки сообщений с адресами в этом домене, а такая конфигурация DMARC означает, что если какой-то другой сервер отправит такое сообщение, то оно может быть отброшено на принимающей стороне.

Ключевым моментом эффективности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.