Схема переопределения отправителей (SRS) в Microsoft 365
Примечание.
В августе 2023 г. изменения будут развернуты для сообщений SMTP или почтовых ящиков. В дальнейшем SRS будет использоваться для перезаписи этих сообщений вместо почтового ящика переадресации. Это позволит объединить методы перенаправления для всех пользователей, использующих SRS в Exchange Online. Хотя служба SRS предназначена для предотвращения переадресации сообщений, в некоторых особых случаях могут возникать проблемы. Это изменение связано с тем, что сообщения, передаваемые в Интернет через локальные серверы, не будут переписаны с помощью SRS. Чтобы избежать этого изменения поведения, см. новый параметр, описанный здесь: Схема перезаписи отправителей Предстоящие изменения.
Функция пула ретрансляторов появилась в Microsoft 365, которая влияет на поведение перезаписи SRS. Сообщения, подходящие для этого пула ретрансляторов, не перезаписываются службами SRS и отправляются с IP-адресов, которые не являются частью записи SPF Microsoft 365. Это в основном влияет на сообщения, которые не выполняют проверки SPF при входе в Exchange Online, чтобы службы SRS не исправили эти сбои. Дополнительные сведения см. в документации по пулу ретранслятора здесь: Пулы исходящей доставки.
Функция схемы перезаписи отправителей (SRS) была добавлена в Microsoft 365, чтобы устранить проблему, из-за которой автозапись была несовместима с SPF. Функция SRS перезаписывает адрес P1 From (также известный как адрес конверта) для всех применимых сообщений, которые отправляются изВне из Microsoft 365.
Примечание.
Заголовок From , также известный как адрес отображения или адрес P2 From, отображаемый почтовыми клиентами, остается неизменным.
Функция SRS улучшает доставку применимых сообщений, которые проходят проверки платформы политики отправителей (SPF), когда они поступают от исходного отправителя, но не выполняют проверки SPF в конечном внешнем назначении после их пересылки.
SRS перезаписывает адрес P1 From в следующих сценариях:
- Сообщения в Microsoft 365, которые автоматически отправляются (или перенаправляются) внешнему получателю с помощью любого из следующих методов:
- Перенаправление SMTP
- Перенаправление правила почтового ящика (или правила папки "Входящие")
- Перенаправление правил потока обработки почты (транспорта)
- Группы или списки DLs с внешними элементами
- Переадресация почтовых контактов
- Пересылка почтовых пользователей
- Сообщения, которые автоматически передаются (или перенаправляются) из локальной среды клиента и ретранслируются через Exchange Online.
Важно отметить, что перезапись SRS используется для предотвращения подделывания непроверенных доменов. Сообщения следует отправлять только из доменов, которыми вы владеете и для которых вы проверили свою собственность в списке Принятые домены. Дополнительные сведения о принятых доменах в Microsoft 365 см. в статье Управление принятыми доменами в Exchange Online.
Примечание.
Перезапись SRS не устраняет проблему передачи DMARC для пересылаемых сообщений. Хотя проверка SPF теперь будет пройдена из-за перезаписного адреса P1 From , DMARC также требует проверки выравнивания для передачи сообщения. Для пересылаемых сообщений DKIM всегда завершается сбоем, так как подписанный домен DKIM не соответствует домену заголовка From . Если исходный отправитель задает политику DMARC для отклонения перенаправленных сообщений, пересылаемые сообщения отклоняются агентами передачи сообщений (MTA), которые учитывают политики DMARC. Стандарт ARC был разработан для решения проблем DKIM с пересылкой и был реализован в нашей службе для решения этих проблем.
Этот сценарий сбоя вместе с другими сбоями доставки приводит к тому, что отчеты о недоставке (NDR) возвращаются в Exchange Online, а не исходному отправителю, если перезапись SRS не используется. Таким образом, часть реализации SRS заключается в перенаправле возврата NDR исходному отправителю, если сообщение не может быть доставлено.
В следующих разделах представлены различные сценарии автоматического включения и сведения о том, как SRS обрабатывает их.
Автоматическая отправка сообщений электронной почты для почтового ящика, размещенного в Microsoft 365
Для сообщения, которое отправляется в размещенный почтовый ящик и автоматически передается с помощью таких механизмов, как перенаправление SMTP, перенаправление правил почтового ящика или перенаправление правила транспорта, адрес P1 From перезаписывается, прежде чем сообщение покинет Exchange Online. Адрес переписывается по следующему шаблону:
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
В следующем примере сообщение отправляется из Боба (bob@fabrikam.com) в почтовый ящик Джона в Exchange Online (john.work@contoso.com). У Джона настроена автоматическая отправка из этого почтового ящика на домашний адрес электронной почты (john.home@example.com). Обратите внимание, что адрес P1 From переписывается SRS.
| Исходное сообщение | Автоматическое сообщение | |
|---|---|---|
| Получатель | john.work@contoso.com |
john.home@example.com |
| P1 из | bob@fabrikam.com |
john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com |
| Из заголовка | bob@fabrikam.com |
bob@fabrikam.com |
Когда служба SRS перезаписывает адрес P1 From , увеличивается длина части имени пользователя адреса электронной почты. Однако адрес электронной почты имеет ограничение в 64 символа. Таким образом, если длина перезаписного адреса электронной почты превышает 64 символа, он принимает следующую форму:
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
где <Default Accepted Domain> — имя принятого домена по умолчанию, настроенного для клиента.
Ретрансляция с локального сервера клиента
Когда сообщение, поступающее из непроверенного домена, ретранслируется с локального сервера клиента или приложения через Exchange Online, адрес P1 From перезаписывается перед выходом из Exchange Online. Адрес переписывается по следующему шаблону:
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
В следующем примере сообщение отправляется из Боба (bob@fabrikam.com) в почтовый ящик Джона (john.onprem@contoso.com), который находится на сервере его компании под управлением Exchange Server. У Джона настроена автоматическая отправка из этого почтового ящика на домашний адрес электронной почты (john.home@example.com). Обратите внимание, что адрес P1 From переписывается службой SRS в этом сценарии. Клиентам рекомендуется задать для принятого по умолчанию домена один из собственных доменов.
| Тип | Исходное сообщение | Ретрансляемое сообщение, полученное Exchange Online | Ретрансляемое сообщение, отправленное из Exchange Online |
|---|---|---|---|
| Получатель | john.onprem@contoso.com |
john.home@example.com |
john.home@example.com |
| P1 из | bob@fabrikam.com |
bob@fabrikam.com |
bounces+SRS=44ldt=IX@contoso.com |
| Из заголовка | bob@fabrikam.com |
bob@fabrikam.com |
bob@fabrikam.com |
В некоторых ситуациях ретрансляционные сообщения, переписанные службой SRS, могут не доставляться, и может быть создано NDR.
Чтобы получить эти недоставки, администратор клиента должен создать почтовый ящик с именем "bounces", размещенный в Exchange Online или локально. Домен для этого почтового ящика должен быть задан в качестве принятого домена по умолчанию для клиента.
Перенаправленные сообщения, отправленные на локальный сервер клиента
По умолчанию служба SRS считает локальные серверы в пределах границы доверия и не перезаписывает пересылаемые сообщения, привязанные к локальной среде. Однако для сложных конфигураций маршрутизации, использующих локальные серверы для маршрутизации сообщений в Интернет, пересылаемые сообщения без перезаписи SRS могут быть отклонены из-за сбоя SPF. Чтобы устранить эту проблему, администраторы могут включить SRS для трафика, проходящего через локальный исходящий соединитель. Для этого можно использовать параметр SenderRewritingEnabled, который можно настроить с помощью командлетов New-OutboundConnector или Set-OutboundConnector.
Этот параметр не применяется к соединителям партнеров, которые обрабатывают сообщения внешним получателям, и при необходимости к этим сообщениям обязательно применяется SRS. Параметр SenderRewritingEnabled будет отображаться как true для соединителей партнеров, а при любых попытках задать его значение возвращается ошибка.
Сообщения, перенаправленные потоком обработки почты (транспорт)
Учитывая, что сообщение может быть перенаправлено правилом по любой причине, а не только из-за определенного получателя, понятия почтового ящика пересылки не существует. Учитывая это, перезаписанный адрес SRS имеет следующую форму:
bouncesEtr+SRS=<Hash>=<Timestamp>=<OrigSenderDomain>=<OrigSenderUser>@<Default Accepted Domain>
Чтобы получать NDR, клиент должен иметь возможность получать сообщения, адресованные пользователю с именем bouncesETR, чтобы мы могли перенаправить сообщение исходному отправителю. Например, блокировка Directory-Based Edge может помешать возврату NDR, если в клиенте такого почтового ящика не существует.
Пул ретранслятора и пропуск SRS
Функция пула ретрансляторов появилась в Microsoft 365, которая влияет на поведение перезаписи SRS. Сообщения, подходящие для этого пула ретрансляторов, не перезаписываются службами SRS и отправляются с IP-адресов, которые не являются частью записи SPF Microsoft 365. Это в основном влияет на сообщения, которые не выполняют проверки SPF при первой отправке в Exchange Online, так как службы SRS не должны устранять эти сбои с помощью перезаписи. Дополнительные сведения см. в документации по пулу ретранслятора здесь: Пулы исходящей доставки