Долгожданная рассылка наконец-то состоялась! Microsoft отправляет своим пользователям сводные отчеты DMARC RUA, и есть вероятность, что вы этого не заметили. Сводные отчеты Microsoft DMARC отправляются со следующего адреса электронной почты: [email protected]. Необработанный файл сводного отчета Microsoft DMARC отправляется в стандартном формате XML. Microsoft наконец-то приняла DMARC-отчеты, что по сути означает, что теперь пользователи Hotmail, Outlook, Live и msn.com смогут воспользоваться различными преимуществами агрегированных данных Microsoft DMARC.

Обработка агрегированных данных Microsoft DMARC

Анализатор отчетов PowerDMARC анализирует агрегированные данные Microsoft DMARC в организованном формате, который поможет вам обрабатывать их более эффективно.  

Чтобы помочь пользователям воспользоваться преимуществами агрегированных данных отчетов, отправленных Microsoft, PowerDMARC's анализатор отчетов DMARC был предварительно настроен для получения отчетов непосредственно на платформе. Все, что нужно сделать пользователям, это добавить свои домены на платформу PowerDMARC вместе с настройкой DNS-записи DMARC, в то время как мы обрабатываем и представляем отчеты в простой и понятной форме. Здесь вы найдете:

  • Агрегированные данные DMARC, отправленные с адресов получателей Hotmail, Outlook, Live и msn.com, разобранные из необработанного формата файла XML в простую и читабельную информацию, организованную в таблицы
  • PowerDMARC предварительно настроен на обход нарушений RFC, что позволяет нам получать и анализировать ваши данные DMARC, отправленные серверами Microsoft, не беспокоясь об этом.
  • Регистрация нескольких доменов, мониторинг каналов электронной почты и внесение изменений в DNS непосредственно с приборной панели с кнопками действий под рукой.
  • Фильтруйте результаты по различным категориям, таким как по результатам, по источникам отправки, по организациям, по странам, геолокации, подробной статистике или результатам поиска по доменам в строке поиска.
  • Получите более глубокое представление о производительности вашей электронной почты и быстро обнаружите попытки подмены домена, самозванства или поддельных писем, отправляемых с использованием ваших бизнес-доменов Microsoft. Вы также сможете анализировать любые ошибки SPF, DKIM из ваших источников отправки.

Выше показан снимок экрана наших совокупных отчетов DMARC по организациям, отображающих данные DMARC RUA, отправленные Microsoft.

Проблемы, с которыми вы можете столкнуться при самостоятельной работе с Microsoft DMARC Aggregate Reports

Агрегированные электронные письма Microsoft DMARC не соответствуют требованиям RFC

Основная проблема, с которой столкнулись пользователи при отправке Microsoft этих писем с отчетами, заключается в том, что они не соответствуют спецификациям RFC для интернет-почты. Хотя в RFC 5322, глава 2.1.1, четко сказано, что строка символов не должна превышать 78 символов, данные вложения в формате BASE64 в этих электронных письмах с агрегацией Microsoft DMARC представляют собой непрерывную строку без надлежащих разрывов строки, превышающую ограничение в 78 символов. В результате нарушения RFC большинство этих писем попадают в журнал отказов пользователей, а не доставляются в их почтовый ящик. 

Необработанные XML-файлы трудно читать

Как и данные DMARC, отправляемые всеми отчитывающимися организациями, необработанный файл RUA представлен на расширяемом языке разметки (XML), который трудно прочитать и понять.

Необходимые условия для получения Microsoft DMARC RUA

Чтобы получать сводные отчеты для ваших доменов на outlook.com, вам необходимо убедиться, что на вашем DNS опубликована действительная запись PowerDMARC, а также определена политика DMARC. Затем организации, составляющие отчеты, будут отправлять данные сводных отчетов на указанный вами веб-сервер или адрес электронной почты. Это поможет вам получить видимость и соответствие DMARC для сторонних поставщиков электронной почты, которых вы в противном случае не можете контролировать. 

Защитите свои домены на Microsoft Office365 и других платформах, начав свой путь аутентификации электронной почты уже сегодня. Приступайте к работе с бесплатной пробная версия DMARC или запланируйте демонстрация DMARCи оцените преимущества внедрения надежной защиты электронной почты в вашей организации!

Если вы столкнулись с проблемой "Политика MTA-STS отсутствует: STSFetchResult.NONE " при использовании онлайн-инструментов, вы попали по адресу. Сегодня мы обсудим, как исправить это сообщение об ошибке и избавиться от нее, включив политику MTA-STS для вашего домена.

Простой протокол передачи почты, он же SMTP, - это стандартный протокол передачи электронной почты, используемый большинством поставщиков услуг электронной почты. Не чуждое понятие, что SMTP сталкивается с проблемами безопасности с начала времен, с проблемами, которые они до сих пор не смогли решить. Это связано с тем, что для обеспечения обратной совместимости электронной почты SMTP ввел оппортунистическое шифрование в виде команды STARTTLS. По сути, это означает, что в случае, если зашифрованное соединение не может быть согласовано между двумя взаимодействующими SMTP-серверами, соединение сворачивается до незашифрованного, и сообщения отправляются в открытом виде. 

Это делает электронную почту, передаваемую по протоколу SMTP, уязвимой для повсеместного мониторинга и кибернетических подслушивающих атак типа Man-in-the-middle. Это опасно как для отправителя, так и для получателя и может привести к утечке конфиденциальных данных. Именно здесь MTA-STS вступает в дело и делает шифрование TLS обязательным в SMTP, чтобы предотвратить доставку писем по незащищенным соединениям. 

Что такое политика MTA-STS?

Чтобы повысить безопасность электронной почты SMTP и максимально использовать протоколы аутентификации, такие как MTA-STS, сервер-отправитель должен иметь поддержку этого протокола, а сервер-получатель электронной почты должен иметь политику MTA-STS, определенную в их DNS. Режим принудительной политики также рекомендуется для дальнейшего усиления стандартов безопасности. Политика MTA-STS определяет почтовые серверы, использующие MTA-STS в домене получателя. 

Чтобы включить MTA-STS для вашего домена в качестве получателя электронной почты, вам необходимо разместить файл политики MTA-STS в вашем DNS. Это позволит внешним отправителям электронной почты отправлять на ваш домен электронные письма, которые аутентифицированы и зашифрованы TLS с помощью обновленной версии TLS (1.2 или выше). 

Отсутствие опубликованного или обновленного файла политики для вашего домена может быть основной причиной появления сообщений об ошибках типа "Политика MTA-STS отсутствует: STSFetchResult.NONE", что означает, что сервер отправителя не смог получить файл политики MTA-STS, когда он запрашивал DNS получателя и обнаружил, что он отсутствует.

Предварительные условия для MTA-STS:

Серверы электронной почты, для которых будет включена функция MTA-STS, должны использовать TLS версии 1.2 или выше, а также иметь сертификаты TLS, соответствующие текущим стандартам и спецификациям RFC, не просроченные, и сертификаты сервера, подписанные доверенным корневым центром сертификации.

Шаги по устранению "Политика MTA-STS отсутствует"

1. Создание и публикация TXT-записи DNS MTA-STS 

Первый шаг - создание записи MTA-STS для вашего домена. Вы можете создать запись мгновенно, используя генератор записей MTA-STS, который обеспечит вам индивидуальную запись DNS для вашего домена. 

2. Определение режима политики MTA-STS

MTA-STS предлагает пользователям два режима политики для работы.

  • Режим тестирования: Этот режим идеально подходит для новичков, которые ранее не настраивали протокол. Режим тестирования MTA-STS позволяет вам получать отчеты SMTP TLS о проблемах в политиках MTA-STS, проблемах в установлении зашифрованных SMTP-соединений или сбоях в доставке электронной почты. Это поможет вам реагировать на существующие проблемы безопасности, относящиеся к вашим доменам и серверам, не применяя шифрование TLS.
  • Режим принудительного исполнения: Пока вы все еще получаете отчеты о TLS, со временем пользователям будет оптимально внедрить политику MTA-STS, чтобы сделать шифрование обязательным при получении электронной почты с помощью SMTP. Это предотвращает изменение или подделку сообщений во время их пересылки.

3. Создание файла политики MTA-STS

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

Стандартный формат файла политики MTA-STS приведен ниже: 

Имя файла: mta-sts.txt

Максимальный размер файла: 64 КБ

версия: STSv1

режим: тестирование

mx: mail.yourdomain.com

mx: *.yourdomain.com

max_age: 806400 

Примечание: Файл политики, показанный выше, является просто примером.

4. Публикация файла политики MTA-STS

Далее необходимо опубликовать файл политики MTA-STS на публичном веб-сервере, доступном для внешних серверов. Убедитесь, что сервер, на котором вы размещаете файл, поддерживает HTTPS или SSL. Процедура для этого проста. Предположим, что ваш домен предварительно сконфигурирован с публичным веб-сервером:

  • Добавьте к существующему домену поддомен, который должен начинаться с текста: mta-sts (например, mta-sts.domain.com). 
  • Ваш файл политики будет указывать на этот созданный вами поддомен, который должен храниться в файле .well-known директории
  • URL-адрес файла политики добавляется в запись DNS при публикации DNS-записи MTA-STS, чтобы сервер мог запрашивать DNS для получения файла политики во время передачи электронной почты.

5. Активируйте MTA-STS и TLS-RPT

Наконец, вам необходимо опубликовать ваши MTA-STS и TLS-RPT DNS-записи в DNS вашего домена, используя TXT в качестве типа ресурса, размещенные на двух отдельных поддоменах (_smtp._tls и _mta-sts). Это позволит только TLS-шифрованным сообщениям достигать вашего почтового ящика, проверенным и несанкционированным. Более того, вы будете ежедневно получать отчеты о проблемах доставки и шифрования на настроенный вами адрес электронной почты или веб-сервер с внешних серверов.

Вы можете проверить действительность своих DNS-записей, выполнив поиск записи MTA-STS после того, как запись будет опубликована и начнет работать.  

Примечание: Каждый раз, когда вы вносите изменения в содержимое файла политики MTA-STS, вы должны обновлять его как на публичном веб-сервере, на котором вы размещаете свой файл, так и на DNS-записи, содержащей URL вашей политики. То же самое относится и к каждому обновлению или добавлению доменов или серверов.

Как хостируемые службы MTA-STS могут помочь в решении проблемы "Политика MTA-STS отсутствует"?

Ручная реализация MTA-STS может быть трудной и сложной и оставлять место для ошибок. PowerDMARC размещенные MTA-STS помогает ускорить процесс для владельцев доменов, делая развертывание протокола легким и быстрым. Вы можете:

  • Публикация записей CNAME для MTA-STS с помощью нескольких щелчков мыши
  • Передайте на аутсорсинг тяжелую работу, связанную с обслуживанием и размещением файлов политики MTA-STS и веб-серверов
  • Изменяйте режим политики, когда захотите, прямо с индивидуально настроенной приборной панели, без необходимости доступа к DNS.
  • Мы отображаем JSON-файлы отчетов SMTP TLS в организованном и человекочитаемом формате, удобном и понятном как для технических, так и для нетехнических специалистов.

Самое лучшее? Мы совместимы с RFC и поддерживаем последние стандарты TLS. Это поможет вам начать безошибочную настройку MTA-STS для вашего домена и наслаждаться его преимуществами, оставив все хлопоты и сложности на наше усмотрение! 

Надеюсь, эта статья помогла вам избавиться от подсказки "Политика MTA-STS отсутствует: STSFetchResult.NONE", а также правильно настроить протоколы для вашего домена, чтобы уменьшить лазейки и проблемы в безопасности SMTP. 

Включите MTA-STS для своей электронной почты сегодня, пройдя бесплатную проверку аутентификация электронной почты испытание DMARCдля улучшения защиты от MITM и других кибернетических подслушивающих атак!