✖


Jump to content

Структура политики отправителей

Sender Policy Framework ( SPF ) — это метод аутентификации электронной почты , который гарантирует, что отправляющий почтовый сервер имеет право отправлять почту из домена отправителя электронной почты. [1] [2] Эта аутентификация применяется только к отправителю электронной почты, указанному в поле «Конверт от» во время первоначального SMTP-соединения. Если электронное письмо не будет возвращено, на этот адрес будет отправлено сообщение, [2] а для нисходящей передачи он обычно появляется в заголовке «Return-Path». Для аутентификации адреса электронной почты, который фактически виден получателям в строке «От:», другие технологии, такие как DMARC необходимо использовать . Подделка этого адреса известна как подмена электронной почты . [3] и часто используется для фишинга и спама в электронной почте .

Список авторизованных отправляющих хостов и IP-адресов для домена публикуется в записях DNS для этого домена. Структура политики отправителей определена в RFC 7208 от апреля 2014 года как «предлагаемый стандарт». [4]

История

[ редактировать ]

Первое публичное упоминание концепции произошло в 2000 году, но осталось практически незамеченным. [5] Эта концепция больше не упоминалась до тех пор, пока в 2002 году в списке рассылки IETF «namedroppers» Дана Валери Риз не опубликовала первую попытку создания спецификации, подобной SPF. [6] [3] [5] который не знал об упоминании этой идеи в 2000 году. Уже на следующий день Пол Викси разместил в том же списке свою собственную спецификацию, подобную SPF. [7] [5] Эти сообщения вызвали большой интерес, привели к формированию IETF Anti-Spam Research Group (ASRG) и их списка рассылки, где идея SPF получила дальнейшее развитие. Среди предложений, представленных ASRG, были «Reverse MX » (RMX) Хадмута Даниша и «Designated Mailer Protocol» (DMP) Гордона Фесика. [8]

В июне 2003 года Мэн Вен Вонг объединил спецификации RMX и DMP. [9] и запросил предложения от других. В течение следующих шести месяцев было внесено большое количество изменений, и над SPF начало работать большое сообщество. [10] Первоначально SPF расшифровывался как Sender Permit From и иногда также назывался SMTP+SPF ; но в феврале 2004 года его название было изменено на Sender Policy Framework .

В начале 2004 года IETF создал рабочую группу MARID и попытался использовать SPF и предложение Microsoft CallerID в качестве основы для того, что сейчас известно как Sender ID ; но это рухнуло из-за технических и лицензионных конфликтов. [11]

Сообщество SPF вернулось к исходной «классической» версии SPF. В июле 2005 года эта версия спецификации была одобрена IESG как IETF эксперимент , предложив сообществу наблюдать за SPF в течение двух лет после публикации. 28 апреля 2006 г. SPF RFC был опубликован как экспериментальный RFC 4408.

В апреле 2014 года IETF опубликовала SPF в RFC 7208 как «предлагаемый стандарт».

Принципы работы

[ редактировать ]
Дополнительная информация: Схема перезаписи отправителя (SRS).
Пример сценария

Простой протокол передачи почты позволяет любому компьютеру отправлять электронную почту, утверждая, что она отправлена ​​с любого исходного адреса. Этим пользуются спамеры и мошенники, которые часто используют поддельные адреса электронной почты . [12] что затрудняет отслеживание источника сообщения и позволяет спамерам скрыть свою личность, чтобы избежать ответственности. Он также используется в методах фишинга , когда пользователей можно обманом заставить раскрыть личную информацию в ответ на электронное письмо, предположительно отправленное такой организацией, как банк.

SPF позволяет владельцу интернет-домена указать, какие компьютеры имеют право отправлять почту с адресами конверта в этом домене, используя системы доменных имен записи (DNS). Получатели, проверяющие информацию SPF в записях TXT, могут отклонять сообщения из неавторизованных источников до получения тела сообщения. Таким образом, принципы работы аналогичны принципам работы списков черных дыр на основе DNS ( DNSBL ), за исключением того, что SPF использует схему делегирования полномочий системы доменных имен. Текущая практика требует использования записей TXT. [13] так же, как это делали ранние реализации. Некоторое время новый тип записи (SPF, тип 99) был зарегистрирован и стал доступен в обычном программном обеспечении DNS. В то время использование записей TXT для SPF задумывалось как переходный механизм. В экспериментальном RFC, RFC 4408, раздел 3.1.1, предлагалось, что «доменное имя, совместимое с SPF, ДОЛЖНО иметь записи SPF обоих типов RR». [14] В предлагаемом стандарте RFC 7208 говорится, что «использование альтернативных типов DNS RR поддерживалось на экспериментальной стадии SPF, но было прекращено». [13]

Адрес отправителя конверта передается в начале диалога SMTP. Если сервер отклоняет домен, неавторизованный клиент должен получить сообщение об отклонении, и если этот клиент был агентом ретрансляционной передачи сообщений (MTA), может быть сгенерировано сообщение о возврате на исходный адрес отправителя конверта. Если сервер принимает домен, а затем также принимает получателей и тело сообщения, он должен вставить поле Return-Path в заголовок сообщения, чтобы сохранить адрес отправителя конверта. Хотя адрес в Return-Path часто соответствует другим адресам отправителя в заголовке письма, например, header-from , это не обязательно так, и SPF не предотвращает подделку этих других адресов, таких как заголовок отправителя .

Спамеры могут отправлять электронную почту с результатом SPF PASS, если у них есть учетная запись в домене с политикой отправителя или они злоупотребляют взломанной системой в этом домене. Однако это упрощает отслеживание спамера.

Основное преимущество SPF — для владельцев адресов электронной почты, подделанных в Return-Path. Они получают большое количество нежелательных сообщений об ошибках и других автоматических ответов. Если такие получатели используют SPF для указания своих законных IP-адресов источника и указывают результат FAIL для всех остальных адресов, получатели, проверяющие SPF, могут отклонять подделки, тем самым уменьшая или устраняя количество обратного рассеяния .

SPF имеет потенциальные преимущества, помимо помощи в выявлении нежелательной почты. В частности, если отправитель предоставляет информацию SPF, получатели могут использовать результаты SPF PASS в сочетании со списком разрешений для идентификации известных надежных отправителей. Сценарии, подобные взломанным системам и почтовым программам совместной отправки, ограничивают такое использование.

Причины внедрения

[ редактировать ]

Если домен публикует запись SPF, спамеры и фишеры с меньшей вероятностью будут подделывать электронные письма, выдавая себя за отправленные из этого домена, поскольку поддельные электронные письма с большей вероятностью попадут в спам-фильтры, которые проверяют запись SPF. Таким образом, домен, защищенный SPF, менее привлекателен для спамеров и фишеров. Поскольку домен, защищенный SPF, менее привлекателен в качестве поддельного адреса, он с меньшей вероятностью попадет в список запрещенных спам-фильтрами, и поэтому в конечном итоге законная электронная почта из домена с большей вероятностью пройдет. [15]

FAIL и пересылка

[ редактировать ]

SPF нарушает обычную пересылку сообщений . Когда домен публикует политику SPF FAIL, законные сообщения, отправленные получателям, пересылающим почту третьим лицам, могут быть отклонены и/или возвращены, если происходит все следующее:

  1. Перенаправитель не переписывает Return-Path , в отличие от списков рассылки.
  2. Следующий переход не включает сервер пересылки в белый список.
  3. Этот переход проверяет SPF.

Это необходимая и очевидная особенность SPF — проверки за «границей» MTA ( MX ) получателя не могут работать напрямую.

Издатели политик SPF FAIL должны принять риск того, что их законные электронные письма будут отклонены или возвращены. Им следует тестировать (например, с помощью политики SOFTFAIL) до тех пор, пока они не будут удовлетворены результатами. Ниже приведен список альтернатив простой пересылке сообщений.

HELO-тесты

[ редактировать ]

Для пустого Return-Path, используемого в сообщениях об ошибках и других автоматических ответах, проверка SPF идентификатора HELO является обязательной.

При поддельном идентификаторе HELO результат NONE не поможет, но для действительных имен хостов SPF также защищает идентификатор HELO. Эта функция SPF всегда поддерживалась как опция для приемников, и в более поздних проектах SPF, включая окончательную спецификацию, рекомендуется всегда проверять HELO.

Это позволяет получателям включать в список разрешенных отправителей почтовые программы на основе HELO PASS или отклонять все письма после HELO FAIL. Его также можно использовать в системах репутации (любой список разрешений или запретов — это простой случай системы репутации).

Выполнение

[ редактировать ]

Соблюдение SPF состоит из трех слабо связанных друг с другом задач:

  • Публикация политики : домены и хосты идентифицируют машины, которым разрешено отправлять электронную почту от их имени. Они делают это, добавляя дополнительные записи к существующей информации DNS: каждое доменное имя или хост, имеющий запись A или запись MX, должна иметь запись SPF, определяющую политику, если она используется либо в адресе электронной почты, либо в качестве аргумента HELO/EHLO. Хосты, которые не отправляют почту, должны иметь опубликованную запись SPF, указывающую на это («v=spf1 -all»).
  • Проверка и использование информации SPF . Получатели используют обычные DNS-запросы, которые обычно кэшируются для повышения производительности. Затем получатели интерпретируют информацию SPF, как указано, и действуют в соответствии с результатом.
  • Пересмотр пересылки почты : SPF не разрешает пересылку обычной почты. Альтернативы:
    • Повторная рассылка (т. е. замена исходного отправителя на отправителя, принадлежащего локальному домену)
    • Отказ (например, отвечать 551 User not local; please try <[email protected]>)
    • Внесение в белый список на целевом сервере, чтобы он не отклонял пересылаемое сообщение.
    • Sender Rewriting Scheme — более сложный механизм, который обрабатывает маршрутизацию уведомлений о недоставке исходному отправителю.

Таким образом, ключевым вопросом в SPF является спецификация новой информации DNS, которую устанавливают домены и используют получатели. Записи, представленные ниже, имеют типичный синтаксис DNS, например: 

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

"v=" определяет используемую версию SPF. Следующие слова предоставляют механизмы , которые можно использовать для определения того, имеет ли домен право отправлять почту. «ip4» и «a» указывают системы, которым разрешено отправлять сообщения для данного домена. «-all» в конце указывает, что если предыдущие механизмы не совпали, сообщение должно быть отклонено.

Механизмы

[ редактировать ]

восемь механизмов Определены :

ВСЕ Всегда совпадает; используется для результата по умолчанию, например -all для всех IP-адресов, не сопоставленных предыдущими механизмами.
А Если в доменном имени есть адресная запись (A или AAAA), которая может быть преобразована в адрес отправителя, она будет совпадать.
IP4 Если отправитель находится в заданном диапазоне адресов IPv4 , совпадите.
IP6 Если отправитель находится в заданном диапазоне адресов IPv6 , совпадите.
МХ Если имя домена имеет запись MX, разрешающую адрес отправителя, оно будет совпадать (т. е. почта поступает с одного из серверов входящей почты домена).
ПТР Если доменное имя ( запись PTR ) для адреса клиента находится в данном домене и это доменное имя разрешается в адрес клиента ( обратный DNS с прямым подтверждением ), сопоставьте. Этот механизм не рекомендуется, и его следует избегать, если это возможно. [13]
СУЩЕСТВУЕТ Если данное доменное имя разрешается в любой адрес, оно соответствует (независимо от того, в какой адрес оно разрешается). Это используется редко. Наряду с языком макросов SPF он предлагает более сложные сопоставления, такие как DNSBL -запросы.
ВКЛЮЧАТЬ Ссылается на политику другого домена. Если политика этого домена пройдет, этот механизм пройдет. Однако если включенная политика дает сбой, обработка продолжается. Чтобы полностью делегировать политику другого домена, перенаправления необходимо использовать расширение .

Квалификации

[ редактировать ]

Каждый механизм можно комбинировать с одним из четырех квалификаторов :

  • + для результата PASS. Это можно опустить; например, +mx то же самое, что mx.
  • ? для НЕЙТРАЛЬНОГО результата, интерпретируемого как НЕТ (нет политики).
  • ~ (тильда) для SOFTFAIL, средства отладки между НЕЙТРАЛЬНЫМ и FAIL. Обычно сообщения, возвращающие SOFTFAIL, принимаются, но помечаются тегами.
  • - (минус) в случае FAIL письмо должно быть отклонено (см. ниже).

Модификаторы

[ редактировать ]

Модификаторы допускают будущие расширения платформы. только два модификатора, На сегодняшний день широкое распространение получили определенные в RFC 4408:

  • exp=some.example.com дает имя домена с записью DNS TXT (интерпретируемое с помощью языка макросов SPF), чтобы получить объяснение результатов FAIL — обычно URL-адрес , который добавляется к коду ошибки SMTP. Эта функция используется редко.
  • redirect=some.example.com может использоваться вместо механизма ALL- для связи с записью политики другого домена. Этот модификатор легче понять, чем несколько похожий механизм INCLUDE .

Обработка ошибок

[ редактировать ]

Как только реализации SPF обнаруживают синтаксические ошибки в политике отправителя, они должны прервать оценку с результатом PERMERROR. Пропуск ошибочных механизмов не может работать должным образом, поэтому include:bad.example и redirect=bad.example также вызывает ошибку PERMERROR.

Другая гарантия — это максимум десять механизмов, запрашивающих DNS, то есть любой механизм, кроме IP4, IP6 и ALL. Реализации могут прервать вычисление с результатом TEMPERROR, если оно занимает слишком много времени или время ожидания DNS-запроса истекло, или они могут продолжать делать вид, что запрос не вернул никаких данных — это называется «пустым поиском». Однако они должны вернуть PERMERROR, если политика прямо или косвенно требует более десяти запросов к механизмам . Кроме того, они должны возвращать PERMERROR, как только обнаружено более двух «пустых поисков». Любой redirect= также учитывается в рамках этих ограничений обработки . [16]

Типичная политика SPF HELO v=spf1 a mx ip4:192.0.2.0 -all может выполнять четыре или более DNS-запросов: (1) запись TXT (тип SPF устарел согласно RFC 7208), (2) A или AAAA для механизма a, (3) запись MX и (4+) A или AAAA для каждого имени MX, для механизма mx. За исключением первого, все эти запросы учитываются до предела 10. Кроме того, если, например, отправитель имеет адрес IPv6, а его имя и два его имени MX имеют только адреса IPv4, то оценка первых двух механизмов уже приводит к более чем двум пустым поискам и, следовательно, к ошибке PERMERROR. Механизмы ip4, ip6 и all не нужен поиск DNS.

Проблемы

[ редактировать ]

DNS-записи SPF

[ редактировать ]

Чтобы обеспечить быстрое тестирование и развертывание, первоначальные версии SPF проверяли его настройку в записи DNS TXT отправляющего домена, хотя традиционно предполагалось, что эта запись будет текстом в свободной форме без какой-либо семантики. [17] Хотя в июле 2005 года IANA присвоило SPF конкретный тип записи ресурсов 99, популярность которого никогда не была высокой, а наличие двух механизмов сбивало с толку пользователей. В 2014 году использование этой записи было прекращено после того, как рабочая группа SPFbis пришла к выводу, что «…значительный переход на тип RR SPF в обозримом будущем очень маловероятен и что лучшим решением для решения этой проблемы совместимости было бы прекратить поддержку Тип SPF RR». [13]

Ограничения заголовка

[ редактировать ]

Поскольку SPF все чаще предотвращает подделку спамерами адреса отправителя конверта, многие перешли к подделке только адреса в поле «От» заголовка письма, который фактически отображается получателю, а не только обрабатывается агентом передачи сообщений получателя (MTA). . Однако SPF (или DKIM ) можно использовать вместе с DMARC , чтобы также проверить поле «От» заголовка письма. Это называется «выравниванием идентификаторов».

Для защиты от такой подделки отображаемого имени необходимы специальные собственные реализации, которые не могут использовать SPF. [18] [19] [20]

Развертывание

[ редактировать ]

Программное обеспечение для защиты от спама, такое как SpamAssassin версии 3.0.0 и ASSP, реализует SPF. Многие агенты передачи почты (MTA) поддерживают SPF напрямую, например Courier , CommuniGate Pro, Wildcat , MDaemon и Microsoft Exchange , или имеют доступные патчи или плагины, поддерживающие SPF, включая Postfix , Sendmail , Exim , qmail и Qpsmtpd . [21] По состоянию на 2017 год более восьми миллионов доменов опубликовали SPF FAIL. -all политики. [22] Согласно опросу, опубликованному в 2007 году, 5% опрошенных .com и .net домены имели какую-то политику SPF. В 2009 году непрерывное исследование, проведенное Nokia Research, показало, что 51% протестированных доменов используют политику SPF. [23] Эти результаты могут включать тривиальные политики, такие как v=spf1 ?all. [24] [25] [ нужно обновить ]

В апреле 2007 года BITS, подразделение Круглого стола по финансовым услугам, опубликовало рекомендации по безопасности электронной почты для своих членов, включая развертывание SPF. [26] В 2008 году Рабочая группа по борьбе со злоупотреблением сообщениями (MAAWG) опубликовала документ об аутентификации электронной почты, охватывающей SPF, Sender ID и DomainKeys Identified Mail (DKIM). [27] В своих «Лучших практиках общения с отправителями» MAAWG заявила: «По крайней мере, отправители должны включать записи SPF для своих почтовых доменов». [28] В 2015 году Рабочая группа по борьбе со злоупотреблением сообщениями (MAAWG) пересмотрела документ об аутентификации электронной почты, охватывающий SPF, почту, идентифицируемую доменными ключами (DKIM) и DMARC (DMARC). В своей пересмотренной «Лучшей практике общения с отправителями» MAAWG заявила: «Аутентификация поддерживает прозрачность путем дальнейшей идентификации отправителя(ов) сообщения, а также способствует сокращению или устранению поддельных и поддельных адресов». [29]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Структура политики отправителей: Введение» . Архивировано из оригинала 22 февраля 2019 г.
  2. ^ Перейти обратно: а б Карранса, Пабло (16 июля 2013 г.). «Как использовать запись SPF для предотвращения подделки и повышения надежности электронной почты» . Цифровой Океан . Архивировано из оригинала 20 апреля 2015 года . Проверено 23 сентября 2019 г. Тщательно настроенная запись SPF снизит вероятность мошеннической подделки вашего доменного имени и предотвратит пометку ваших сообщений как спама до того, как они достигнут получателей. Подмена электронной почты — это создание сообщений электронной почты с поддельным адресом отправителя; это просто сделать, потому что многие почтовые серверы не выполняют аутентификацию. В спам- и фишинговых письмах такая подмена обычно используется, чтобы ввести получателя в заблуждение относительно происхождения сообщения.
  3. ^ Перейти обратно: а б Дэвид, Грин. «Почта-передатчик РР» . marc.info . Проверено 15 мая 2019 г.
  4. ^ Статус RFC7208
  5. ^ Перейти обратно: а б с «История СПФ» . ДМАРКиан . DMARCian.org. 18 марта 2019 г. Проверено 15 мая 2019 г.
  6. ^ письмо как Дэвид Грин
  7. ^ Пол, Викси. «Re: Почтовый передатчик RR» . marc.info . Проверено 15 мая 2019 г.
  8. ^ «SPF: История/Pre-SPF» . Проверено 16 мая 2009 г.
  9. ^ Сравнение RMX, DMP и SPF см. в разделе « Сравнение RMX и DMP ». Архивировано 25 апреля 2008 г. на Wayback Machine на историческом сайте openspf.
  10. ^ «СПФ: История/СПФ-2003» . Проверено 16 мая 2009 г.
  11. ^ Зельцер, Ларри (22 сентября 2004 г.). «Специальная группа по Интернету закрывает рабочую группу по борьбе со спамом» . электронная неделя . Проверено 15 мая 2019 г.
  12. ^ Дэн Шлитт (29 августа 2013 г.). «Последний звонок: <draft-ietf-spfbis-4408bis-19.txt> (структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1) в соответствии с предлагаемым стандартом» . Список обсуждений IETF . IETF . Проверено 16 декабря 2013 г.
  13. ^ Перейти обратно: а б с д Скотт Киттерман (апрель 2014 г.). «Записи ресурсов DNS» . Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1 . IETF . сек. 3.1. дои : 10.17487/RFC7208 . РФК 7208 . Проверено 26 апреля 2014 г.
  14. ^ Вонг, М. и В. Шлитт. RFC 4408. Апрель 2006 г. <rfc:4408>
  15. ^ «Почему мне следует использовать запись SPF в своем домене?» . Руководство по электронной почте. Май 2009. Архивировано из оригинала 29 января 2010 года . Проверено 1 января 2010 г.
  16. ^ Аткинс, Стив (14 марта 2016 г.). «SPF: Правило десяти» . wordtothewise.com . Проверено 23 сентября 2019 г.
  17. ↑ Стив Белловин выражает сомнения. Архивировано 13 апреля 2004 г. в Wayback Machine (январь 2004 г.).
  18. ^ «Создайте политику блокировки входящих сообщений MIMECAST, чтобы ПРЕКРАТИТЬ ПОДДЕЛКУ электронной почты» . Проверено 25 августа 2017 г.
  19. ^ «Предотвратите поддельные сообщения с помощью обнаружения поддельных отправителей» . Проверено 25 августа 2017 г.
  20. ^ «Как работает защита от спуфинга в Office 365» . 23 февраля 2016 года . Проверено 25 августа 2017 г.
  21. ^ «Плагин Qpsmtpd SPF» . Гитхаб . 2013. Архивировано из оригинала 29 июня 2013 г.
  22. ^ «Обследование SPF-всех доменов» . 2017 . Проверено 7 ноября 2017 г.
  23. ^ «Отчет об исследовании Nokia по внедрению SPF» . Fit.Nokia.com . Нокиа . 19 сентября 2011 г. Архивировано из оригинала 20 сентября 2011 г. Проверено 5 апреля 2016 г.
  24. ^ Лю, Крикет (январь 2007 г.). «Препятствование новым расширениям и приложениям DNS» . ONLamp . Проверено 4 октября 2007 г.
  25. ^ «Аутентификация SPF: SPF-all против ~all» . EasyDMARC . 04.12.2020 . Проверено 8 апреля 2021 г.
  26. ^ «Набор инструментов безопасности электронной почты BITS» (PDF) . БИТЫ. Апрель 2007 года . Проверено 13 июня 2008 г.
  27. ^ Крокер, Дэйв (март 2008 г.). «Доверие к электронной почте начинается с аутентификации» (PDF) . МААВГ. Архивировано из оригинала (PDF) 29 января 2013 г. Проверено 28 июля 2011 г.
  28. ^ «Резюме лучших практик связи MAWG Sender» (PDF) . МААВГ. 07.10.2011 . Проверено 27 апреля 2012 г.
  29. ^ «Рекомендации по отправке M3AAWG» (PDF) . МААВГ. 01 февраля 2015 г. Проверено 1 сентября 2016 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=1225772403"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: d5297b6328371b167955b3bc3d2d5630__1716729960
URL1:https://arc.ask3.ru/arc/aa/d5/30/d5297b6328371b167955b3bc3d2d5630.html
Заголовок, (Title) документа по адресу, URL1:
Sender Policy Framework - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)