Как EOP проверяет адрес from для предотвращения фишинга

Совет

Знаете ли вы, что можете бесплатно опробовать функции в Microsoft Defender XDR для Office 365 плана 2? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

Фишинговые атаки представляют постоянную угрозу для любой организации электронной почты. Помимо использования подделанных (поддельных) адресов электронной почты отправителя злоумышленники часто используют значения в адресе "От", которые нарушают интернет-стандарты. Чтобы предотвратить фишинг такого типа, Exchange Online Protection (EOP) и Outlook.com требуют, чтобы входящие сообщения включали соответствующий RFC адрес From, как описано в этой статье.

  • Если вы регулярно получаете сообщения электронной почты от организаций с неправильными адресами, как описано в этой статье, рекомендуется обновить свои почтовые серверы в соответствии с современными стандартами безопасности.

  • Эти требования не влияют на связанное поле Отправитель (используется в списке отправки от имени и рассылки). Дополнительные сведения см. в следующей записи блога: Что мы имеем в виду, когда мы ссылаемся на "отправителя" сообщения электронной почты?.

Общие сведения о стандартах сообщений электронной почты

Стандартное SMTP-сообщение электронной почты состоит из конверта сообщения и его содержимого. Конверт сообщения содержит сведения, необходимые для передачи и доставки сообщения между SMTP-серверами. Содержимое сообщения разделяется на поля заголовка сообщения, которые в совокупности называются заголовком сообщения, и текста сообщения. Конверт сообщения описан в документе RFC 5321, а заголовок сообщения — в документе RFC 5322. Получатели никогда не видят фактический конверт сообщения, так как он создается процессом передачи сообщения и на самом деле не является частью сообщения.

  • Адрес MAIL FROM (также известный 5321.MailFrom как адрес, отправитель P1 или отправитель конверта) — это адрес электронной почты, используемый при передаче сообщения SMTP. Этот адрес электронной почты обычно записывается в поле Заголовок Return-Path в заголовке сообщения (хотя отправитель может назначить другой адрес электронной почты Return-Path ).

  • Адрес от (также известный 5322.From как адрес или отправитель P2) — это адрес электронной почты в поле От заголовка и адрес электронной почты отправителя, который отображается в почтовых клиентах. Адрес From является основной частью требований, приведенных в этой статье.

Адрес From подробно определен в нескольких RFC (например, в разделах RFC 5322 3.2.3, 3.4 и 3.4.1 и RFC 3696). Существует много вариантов адресации и того, что считается допустимым или недопустимым. Чтобы упростить процесс, рекомендуется использовать следующие форматы и определения:

From: "Display Name" <EmailAddress>

  • Отображаемое имя: необязательная фраза, описывающая владельца адреса электронной почты.

    • Рекомендуется всегда заключать отображаемое имя в двойные кавычки ("), как показано ниже. Если отображаемое имя содержит запятую, необходимо заключить строку в двойные кавычки в соответствии с RFC 5322.
    • Если адрес From содержит отображаемое имя, значение EmailAddress должно быть заключено в угловые скобки (<>), как показано ниже.
    • Корпорация Майкрософт настоятельно рекомендует вставить пробел между отображаемым именем и адресом электронной почты.

  • EmailAddress: адрес электронной почты использует формат local-part@domain:

    • local-part: строка, идентифицирующая почтовый ящик, связанный с адресом. Это значение уникально в пределах домена. Часто используется имя пользователя или GUID владельца почтового ящика.
    • domain: полное доменное имя (FQDN) почтового сервера, на котором размещен почтовый ящик, определенный локальной частью адреса электронной почты.

    Кроме того:

    • Только один адрес электронной почты.
    • Рекомендуется не разделять угловые скобки пробелами.
    • Не включайте текст после адреса электронной почты.

Примеры хороших и плохих адресов из

В следующей таблице приведены примеры допустимых адресов from:

Address Comments
From: sender@contoso.com OK
From: <sender@contoso.com> OK
From: < sender@contoso.com > Хорошо, но не рекомендуется, так как между угловыми скобками и адресом электронной почты есть пробелы.
From: "Sender, Example" <sender.example@contoso.com> OK
From: "Microsoft 365" <sender@contoso.com> OK
From: Microsoft 365 <sender@contoso.com> Хорошо, но не рекомендуется, так как отображаемое имя не заключено в двойные кавычки.

В следующей таблице приведены примеры недопустимых адресов from:

Address Comments
Нет по адресу Когда сообщение поступает в Microsoft 365 или Outlook.com без адреса From, мы пытаемся назначить адрес MAIL FROM адресу From, чтобы убедиться, что сообщение будет доставлено. В настоящее время эти сообщения принимаются службой, даже если исходный адрес From имеет значение From: <>.
From: <firstname lastname@contoso.com> Адрес электронной почты содержит пробел.
From: Microsoft 365 sender@contoso.com Отображаемое имя присутствует, но адрес электронной почты не заключен в угловые скобки.
From: "Microsoft 365" <sender@contoso.com> (Sent by a process) Текст после адреса электронной почты.
From: Sender, Example <sender.example@contoso.com> Отображаемое имя содержит запятую, но не заключено в двойные кавычки.
From: "Microsoft 365 <sender@contoso.com>" Все значение неправильно заключено в двойные кавычки.
From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com Отображаемое имя присутствует, но адрес электронной почты не заключен в угловые скобки.
From: Microsoft 365<sender@contoso.com> Между отображаемым именем и левой угловой скобкой нет пробела.
From: "Microsoft 365"<sender@contoso.com> Между закрывающей двойной кавычки и левой угловой скобкой нет пробела.

Подавление автоматических ответов на личные домены

Значение From: <> нельзя использовать для подавления автоответов. Вместо этого необходимо настроить запись MX null для личного домена. После настройки нулевой записи MX все ответы, естественно, подавляются, так как нет опубликованного адреса для отправки сообщений на сервере-ответе.

Для записи MX null выберите домен электронной почты, который не может получать электронную почту. Например, если основным доменом является contoso.com, можно выбрать noreply.contoso.com. Запись MX null для этого домена состоит из одной точки. Например:

noreply.contoso.com IN MX .

Дополнительные сведения о настройке записей MX см. в статье Create записей DNS в любом поставщике услуг размещения DNS для Microsoft 365.

Дополнительные сведения о публикации NULL MX см. в статье RFC 7505.

Принудительное переопределение из адреса

Чтобы обойти требования к адресам from для входящей электронной почты, можно использовать список разрешенных IP-адресов (фильтрация подключений) или правила потока обработки почты (также известные как правила транспорта), как описано в Create списках надежных отправителей в Microsoft 365. Outlook.com не разрешает переопределения любого рода, даже через запросы в службу поддержки.

Нельзя переопределить требования к адресу from для исходящей электронной почты, отправляемой из Microsoft 365 или Outlook.com.

Другие способы предотвращения и защиты от киберпреступлений в Microsoft 365

Дополнительные сведения о том, как укрепить организацию в борьбе с фишингом, спамом, нарушениями безопасности данных и другими угрозами, см. в статье Рекомендации по защите Microsoft 365 для бизнес-планов.