Настройка ограничений размера сообщений для определенного клиента

Разрешения соединителя получения

Как правило, разрешения применяются к соединителям получения с помощью групп разрешений. Однако вы можете настраивать детализированные разрешения для соединителя получения с помощью командлетов Add-ADPermission и Remove-ADPermission.

Разрешения соединителя получения назначаются субъектам безопасности с помощью групп разрешений для соединителя. Когда клиент или сервер SMTP создает подключение к соединителю получения, разрешения этого соединителя определяют, принимается ли соединение и как оно обрабатывается.

Доступные разрешения соединителя получения представлены в приведенной ниже таблице.

Разрешение соединителя получения	Описание
	Управляет хранением заголовков лесов Exchange в сообщениях. Имена заголовков лесов начинаются с X-MS-Exchange-Forest-. Если разрешение не предоставлено, все заголовки лесов удаляются из сообщений.
	Управляет сохранением заголовков организаций Exchange в сообщениях. Имена заголовков организаций начинаются с X-MS-Exchange-Organization-. Если это разрешение не предоставлено, все заголовки организаций удаляются из сообщений.
	Управляет сохранением заголовков Received и Resent-* в сообщениях. Если разрешение не предоставлено, все эти заголовки удаляются из сообщений.
	Позволяет клиентам и серверам SMTP обходить фильтрацию спама.
	Позволяет клиентам и серверам SMTP отправлять сообщения больше максимального размера, настроенного для соединителя получения.
	Позволяет клиентам и серверам SMTP ретранслировать сообщения через соединитель получения. Если это разрешение не предоставлено, соединитель получения принимает только те сообщения, которые отправлены получателям в обслуживаемых доменах, настроенных для организации Exchange.
	Позволяет клиентам и серверам SMTP обходить проверку адреса отправителя на спуфинг, для которой обычно требуется, чтобы электронный адрес отправителя находился на обслуживаемом домене, настроенном для организации Exchange.
	Указывает, будут ли сообщения от клиентов и серверов SMTP рассматриваться как прошедшие проверку подлинности. Если это разрешение не предоставлено, то сообщения из этих источников определяются как внешние (непроверенные). Этот параметр важен для групп рассылки, настроенных для приема почты только от внутренних получателей (например, параметр RequireSenderAuthenticationEnabled для группы имеет значение ).
	Разрешает доступ к соединителю получения для отправителей, электронные адреса которых находятся на уполномоченных доменах, настроенных для организации Exchange.
	Позволяет клиентам и серверам SMTP отправлять команды XEXCH50 соединителю отправки. Большой двоичный объект X-EXCH50 использовался старыми версиями Exchange (Exchange 2003 и более ранними) для хранения данных Exchange в сообщениях (например, о вероятности нежелательной почты).
	Это разрешение необходимо для отправки сообщений соединителям получения. Если это разрешение не предоставлено, команды MAIL FROM и AUTH не будут выполняться.

Примечания.

Помимо задокументированных разрешений, существуют разрешения, которые назначаются всем субъектам безопасности в группе разрешений серверов Exchange (), кроме . Эти разрешения зарезервированы для внутреннего использования в корпорации Майкрософт и представлены здесь исключительно в справочных целях.
Имена разрешений, содержащиеся в составе функции брандмауэра заголовков . Дополнительные сведения см. в разделе Брандмауэр заголовков.

Действия с разрешениями соединителей получения

Чтобы просмотреть разрешения, назначенные субъектам безопасности соединителя получения, используйте следующий синтаксис в командной консоли Exchange:

Например, чтобы просмотреть разрешения, назначенные всем субъектам безопасности соединителя получения Client Frontend Mailbox01, выполните следующую команду:

Чтобы просмотреть разрешения, назначенные только субъекту безопасности в соединителе получения с именем Default Mailbox01, выполните следующую команду:

Чтобы добавить разрешения для субъекта безопасности, используйте следующий синтаксис:

Чтобы удалить разрешения субъекта безопасности, используйте следующий синтаксис:

Управление получателями, доменами и компаниями в Exchange Online Protection

защита Microsoft Exchange Online (EOP) предлагает несколько средств управления сведениями о получателях, домене и компании. Администратор может выполнять определенные задачи управления в Центре администрирования Exchange (EAC) и проверять другие задачи управления, выполняемые в Центр администрирования Microsoft 365.

Ищете сведения обо всех функциях EOP? См. описание службы Exchange Online Protection.

Mail recipients

Получатели почты классифицируются как почтовые пользователи или группы и могут управляться с помощью синхронизации каталогов, непосредственно в Центре администрирования Майкрософт или через удаленные Windows PowerShell. Если вы управляете получателями в локальной среде, необходимо запустить синхронизацию каталогов, чтобы получатели почты отображались в EAC. Пользователи, управляемые исключительно в Центр администрирования Microsoft 365, недоступны для просмотра в EAC, но их можно добавить или удалить из членства в группе ролей администратора в EAC. Дополнительные сведения о получателях в EOP см. в разделе Получатели в EOP.

Разрешения для группы ролей администраторов

В службе Exchange Online Protection можно настраивать только роли администраторов. Пользователей можно добавить в группы ролей администраторов по умолчанию и удалить из них непосредственно в Центре администрирования Exchange. Настройка RBAC недоступна. Дополнительные сведения см. в разделе Управление разрешениями Администратор группы ролей в EOP.

Управление доменами

Управляемые домены — это домены, защищенные EOP. Управляемые домены можно просматривать, а типы доменов можно изменять в Центре администрирования Exchange. Подготовка домена и управление ими происходит в Центр администрирования Microsoft 365, а изменения отражаются в EAC. Дополнительные сведения см. в разделе Просмотр или изменение управляемых доменов в EOP.

Функция пограничной блокировки на основе каталогов позволяет отклонять сообщения для недопустимых получателей в сети периметра службы. DBEB позволяет администраторам добавлять получателей с поддержкой почты в Корпорацию Майкрософт и блокировать все сообщения, отправляемые на адреса электронной почты, которые отсутствуют в корпорации Майкрософт. Если сообщение отправляется на допустимый адрес электронной почты, присутствующий в корпорации Майкрософт, оно продолжается через остальные уровни фильтрации службы (защита от вредоносных программ, защита от спама, правила транспорта). Если адрес отсутствует, служба блокирует сообщение еще до фильтрации, а отправителю отправляется отчет о недоставке сообщения.

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

Шаг 1. Настройка и публикация сертификатов S/MIME

Каждому пользователю в вашей организации требуется собственный сертификат, выданный для подписывания и шифрования. Эти сертификаты публикуются в локальная служба Active Directory для распространения. Служба Active Directory должна находиться на компьютерах в физическом расположении, которое вы контролируете, а не в удаленном объекте или облачной службе в Интернете.

Дополнительные сведения об Active Directory см. в доменные службы Active Directory Обзор.

Установите центр сертификации на основе Windows и настройте инфраструктуру открытых ключей для выдачи сертификатов S/MIME. Также поддерживаются сертификаты, выданные сторонними поставщиками сертификатов. Дополнительные сведения см. в статье Обзор служб сертификатов Active Directory.

Примечания.
- Сертификаты, выданные сторонним ЦС, имеют преимущество автоматического доверия для всех клиентов и устройств. Сертификаты, выданные внутренним частным ЦС, не являются автоматически доверенными клиентами и устройствами, и не все устройства (например, телефоны) могут быть настроены на доверие частным сертификатам.
- Рассмотрите возможность использования промежуточного сертификата вместо корневого сертификата для выдачи сертификатов пользователям. Таким образом, если вам когда-либо потребуется отозвать и перевыпускать сертификаты, корневой сертификат по-прежнему остается нетронутым.
- Сертификат должен иметь закрытый ключ, а расширение X509 «Идентификатор ключа субъекта» должно быть заполнено.
Опубликуйте сертификат пользователя в учетной записи локальная служба Active Directory в атрибутах UserSMIMECertificate и (или) UserCertificate.

Шаг 2. Настройка коллекции виртуальных сертификатов в Exchange Online

Коллекция виртуальных сертификатов отвечает за проверку сертификатов S/MIME. Настройте коллекцию виртуальных сертификатов, выполнив следующие действия.

Экспортируйте корневые и промежуточные сертификаты, необходимые для проверки пользовательских сертификатов S/MIME, с доверенного компьютера в файл сериализованного хранилища сертификатов (SST) в Windows PowerShell. Например:

Подробные сведения о синтаксисе и параметрах см. в разделе Export-Certificate.
Импортируйте сертификаты из SST-файла в Exchange Online, выполнив следующую команду в Exchange Online PowerShell:

Подробные сведения о синтаксисе и параметрах см. в разделе Set-SmimeConfig.

Export Process

Step 2: Let’s create a .SST file from our trusted Root CA / Intermediate of the certificate issued.

Easiest way to create / export a certificate form Windows MMC feature if you not familiar with PowerShell to convert .SST.

Depending on CA maybe some of Trusted Root Certificate are installed in Intermediate Certificate Authority or Personal folder. Find the right folder and move to all in Trusted Root Certificate Authorities to export all together in .SST file.

Below: So select multiple certificates than Select Microsoft Serialized Certificate Store (.SST) > Click Next and save the SST file in c:\ drive

Проверка использования TLS 1.2

После включения TLS 1.2 может быть полезно проверить успешность работы и система сможет согласовать TLS 1.2 для входящих (серверных) и исходящих (клиентских) подключений. Существует несколько методов, доступных для проверки этого, некоторые из них рассматриваются в разделах ниже.

Многие протоколы, используемые в Exchange Server, основаны на HTTP и, следовательно, проходят процессы IIS на сервере Exchange Server. MAPI/HTTP, Outlook Anywhere, Веб-службы Exchange, Exchange ActiveSync, REST, OWA & EAC, автономная адресная книга и автообнаружение — это примеры протоколов на основе HTTP, используемых Exchange Server.

Windows Server 2016 и Windows Server 2012 R2

Команда IIS добавила возможности для Windows Server 2016 и Windows Server 2012 R2 для регистрации настраиваемых полей, связанных с версиями протокола шифрования и шифрами. Рекомендуем ознакомиться с документацией по включению этих настраиваемых полей в блоге и начать синтаксический анализ журналов для получения сведений о входящих подключениях в вашей среде, связанных с протоколами на основе HTTP.

Эти настраиваемые поля IIS не существуют для Windows Server 2012. Эти сведения могут предоставляться в журналах подсистемы балансировки нагрузки или брандмауэра. Запросите рекомендации у поставщиков, чтобы определить, могут ли их журналы предоставлять эту информацию.

Заголовки сообщений (Exchange Server 2016 или более поздней версии)

Данные заголовков сообщений в Exchange Server 2016 г. предоставляют протокол, согласованный и используемый, когда отправляющий и принимающий узел обменивался частью почты. Вы можете использовать анализатор заголовков сообщений , чтобы получить четкий обзор каждого прыжка.

Примечание.

Существует одно известное исключение из примера заголовков сообщений. Когда клиент отправляет сообщение путем подключения к серверу с использованием протокола SMTP с проверкой подлинности (также известного как протокол отправки КЛИЕНТА SMTP), версия TLS в заголовках сообщений не отображает правильную версию TLS, используемую клиентом или устройством клиента. Корпорация Майкрософт изучает возможность добавления этой информации в будущем обновлении.

Поток обработки почты через ведение журнала SMTP

Журналы SMTP в Exchange Server 2013 и Exchange Server 2016 годах будут содержать протокол шифрования и другую информацию, связанную с шифрованием, используемую при обмене электронной почтой между двумя системами.

Если сервер является принимающей системой SMTP, в журнале существуют следующие строки в зависимости от используемой версии TLS:

протокол TLS SP_PROT_TLS1_0_SERVER
протокол TLS SP_PROT_TLS1_1_SERVER
протокол TLS SP_PROT_TLS1_2_SERVER

Если сервер является системой отправки SMTP, в журнале существуют следующие строки в зависимости от используемой версии TLS:

Протокол TLS SP_PROT-TLS1_0_CLIENT
Протокол TLS SP_PROT-TLS1_1_CLIENT
Протокол TLS SP_PROT-TLS1_2_CLIENT

POP & IMAP

Не существует ведения журнала, которое будет предоставлять версию протокола шифрования, используемую для клиентов POP & IMAP. Чтобы захватить эти сведения, может потребоваться записать журналы Netmon с сервера или проверить трафик по мере его прохождения через подсистему балансировки нагрузки или брандмауэр, где выполняется мостовая передача HTTPS.

Параметры

-AzureKeyIDs

Параметр AzureKeyIDs задает значения URI ключей azure Key Vault, которые необходимо связать с политикой шифрования данных. Необходимо указать по крайней мере два ключа Key Vault Azure, разделенных запятыми. Например, .

Чтобы найти значение URI для Key Vault Azure, замените именем хранилища и выполните следующую команду в Azure Rights Management PowerShell: . Дополнительные сведения см. в статье Сведения об Azure Key Vault.

Type:	MultiValuedProperty
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

-Confirm

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

Деструктивные командлеты (например, командлеты Remove-*) имеют встроенную паузу, которая заставляет вас подтвердить команду перед продолжением. Можно пропускать запросы на подтверждение этих командлетов, используя следующий синтаксис: .
Большинство других командлетов (например, командлеты New-* и Set-*) не имеют встроенной приостановки. Для этих командлетов указание переключателя Confirm без значения вводит паузу, которая заставляет вас подтвердить команду перед продолжением.

Type:	SwitchParameter
Aliases:	cf
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

-Description

Параметр Description задает необязательное описание политики шифрования данных. Если значение содержит пробелы, его необходимо заключить в кавычки.

Type:	String
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

-DomainController

Этот параметр зарезервирован для внутреннего использования корпорацией Майкрософт.

Type:	Fqdn
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

-Enabled

Параметр Enabled включает или отключает политику шифрования данных. Допустимые значения:

$true. Политика включена. Это значение используется по умолчанию.
$true. Политика включена. Это значение задается по умолчанию.

Type:	Boolean
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

-Name

Параметр Name задает уникальное имя политики шифрования данных. Если значение содержит пробелы, его необходимо заключить в кавычки.

Type:	String
Position:	1
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Online

Включение расшифровки вложений электронной почты на стороне службы для почтовых клиентов веб-браузера

Как правило, при использовании Office 365 сообщений вложения шифруются автоматически. Администратор может применять расшифровку на стороне службы для вложений электронной почты, скачиваемых пользователями из веб-браузера.

При использовании расшифровки на стороне службы служба отправляет расшифрованную копию файла на устройство. Сообщение по-прежнему шифруется. Вложение электронной почты также сохраняет сведения о правах на использование, даже если браузер не применяет к пользователю права на использование на стороне клиента. Пользователь может копировать или печатать вложение электронной почты, даже если у них изначально нет прав на это. Однако если пользователь попытается выполнить действие, требующее от почтового сервера Microsoft 365, например пересылку вложения, сервер не разрешит действие, если пользователь изначально не имеет права на использование.

Независимо от того, настроена ли расшифровка вложений на стороне службы, пользователи не могут просматривать вложения в зашифрованную почту и почту, защищенную правами, в почтовом приложении iOS.

Если вы решили не разрешать расшифрованные вложения электронной почты (по умолчанию), пользователи получат сообщение о том, что у них нет прав на просмотр вложения.

Дополнительные сведения о том, как Microsoft 365 реализует шифрование для сообщений электронной почты и вложений электронной почты с помощью параметра Encrypt-Only, см. в разделе «Шифрование только для сообщений

Управление расшифровка вложений электронной почты при скачии из веб-браузера

Используйте рабочую или учебную учетную запись с разрешениями глобального администратора в организации и подключитесь к Exchange Online PowerShell. Инструкции см. в статье Подключение к Exchange Online PowerShell.
Выполните командлет Set-IRMConfiguration с параметром DecryptAttachmentForEncryptOnly:

Например, чтобы настроить службу для расшифровки вложений электронной почты, когда пользователь скачивает их из веб-браузера:

Чтобы настроить службу на то, чтобы оставить зашифрованные вложения электронной почты в том виде, в котором они находятся при скачии:

Отмена ключей и запуск процесса очистки данных

Вы управляете отзывом всех корневых ключей, включая ключ доступности. Ключ клиента обеспечивает контроль над аспектом планирования выхода из нормативных требований. Если вы решите отозвать ключи для очистки данных и выхода из службы, служба удалит ключ доступности после завершения процесса очистки данных. Это поддерживается для клиентов, которые назначаются отдельным почтовым ящикам.

Microsoft 365 выполняет аудит и проверяет путь очистки данных. Дополнительные сведения см. в отчете SSAE 18 SOC 2, доступном на портале Service Trust Portal. Кроме того, корпорация Майкрософт рекомендует следующие документы:

Очистка DEP с несколькими рабочими нагрузками не поддерживается для ключа клиента. DeP с несколькими рабочими нагрузками используется для шифрования данных в нескольких рабочих нагрузках для всех пользователей клиента. Очистка такого DEP приведет к недоступности данных из нескольких рабочих нагрузок. Если вы решили полностью выйти из служб Microsoft 365, вы можете выбрать путь удаления клиента в соответствии с задокументированным процессом. Узнайте , как удалить клиент в Azure Active Directory.

Отмените ключи клиента и ключ доступности для Exchange Online и Skype для бизнеса

При запуске пути очистки данных для Exchange Online и Skype для бизнеса запрос на постоянную очистку данных в DEP. При этом зашифрованные данные в почтовых ящиках, которым назначен этот DEP, удаляются без возможности восстановления.

Так как командлет PowerShell можно запускать только для одного deP за раз, рассмотрите возможность переназначения одного DEP всем почтовым ящикам, прежде чем инициировать путь очистки данных.

Предупреждение

Не используйте путь очистки данных для удаления подмножества почтовых ящиков. Этот процесс предназначен только для клиентов, которые выйдите из службы.

Чтобы инициировать путь очистки данных, выполните следующие действия:

Удалите разрешения на перенос и распаковку для O365 Exchange Online из хранилищ ключей Azure.
Используя рабочую или учебную учетную запись с правами глобального администратора в вашей организации, подключитесь к Exchange Online PowerShell.
Для каждого dep, содержащего почтовые ящики, которые необходимо удалить, выполните командлет Set-DataEncryptionPolicy следующим образом.

Если команда завершается сбоем, убедитесь, что вы удалили разрешения Exchange Online обоих ключей в Azure Key Vault как указано выше в этой задаче. После настройки параметра PermanentDataPurgeRequested с помощью Set-DataEncryptionPolicy вы больше не сможете назначать этот dep почтовым ящикам.
Обратитесь в службу поддержки Майкрософт и запросите eDocument для очистки данных.

По вашему запросу корпорация Майкрософт отправляет вам юридический документ для подтверждения и авторизации удаления данных. Пользователь в вашей организации, зарегистрировавшийся в качестве утверждающего в предложении FastTrack во время подключения, должен подписать этот документ. Как правило, это руководитель или другой назначенный сотрудник в вашей компании, который имеет юридические права подписывать документы от имени вашей организации.
После того как ваш представитель подписал юридический документ, верните его в корпорацию Майкрософт (обычно с помощью подписи eDoc).

Когда корпорация Майкрософт получит юридический документ, корпорация Майкрософт запускает командлеты для активации очистки данных, которая сначала удаляет политику, помечает почтовые ящики для окончательного удаления, а затем удаляет ключ доступности. После завершения процесса очистки данных данные были очищены, недоступны для Exchange Online и не могут быть восстановлены.

Как работает EOP

Чтобы понять, как работает EOP, будет полезным взглянуть, как эта служба обрабатывает входящую электронную почту.

Когда входящее сообщение поступает в EOP, оно сначала проходит фильтрацию подключений, которая проверяет репутацию отправителя. Большая часть спама останавливается на этом этапе и отклоняется EOP. Дополнительные сведения см. в статье Настройка фильтрации подключений.
Затем сообщение проверяется на наличие вредоносных программ. Если в сообщении или вложениях обнаружена вредоносная программа, сообщение доставляется в карантин. По умолчанию только администраторы могут просматривать сообщения, помещенные в карантин, и взаимодействовать с ними. Но администраторы могут создавать и использовать политики карантина , чтобы указать, что пользователям разрешено делать с сообщениями, помещенными в карантин. Дополнительные сведения о защите от вредоносных программ см. в статье Защита от вредоносных программ в EOP.
Сообщение продолжается с помощью фильтрации политик, где оно вычисляется по всем созданным правилам потока обработки почты (также называемым правилами транспорта). Например, правило может отправлять уведомление руководителю, когда сообщение поступает от определенного отправителя.

В локальной организации с Exchange Enterprise CAL с лицензиями на службы проверки Майкрософт защиты от потери данных (DLP) Purview в EOP также выполняются на этом этапе.

Получатели доставляют сообщение, которое успешно проходит все эти уровни защиты.

Дополнительные сведения см. в разделе Порядок и приоритет защиты электронной почты.

Центры обработки данных службы EOP

Служба EOP работает во всемирной сети центров данных, которые предназначены для обеспечения лучшей доступности. Например, если центр данных недоступен, сообщения электронной почты автоматически направляются в другой центр данных без остановки работы службы. Серверы в каждом центре обработки данных принимают сообщения от вашего имени, обеспечивая уровень разделения между вашей организацией и Интернетом, тем самым уменьшая нагрузку на серверы. Благодаря этой высокой доступности сети корпорация Майкрософт может гарантировать, что электронная почта достигнет вашей организации в установленные сроки.

Служба EOP выполняет балансировку нагрузки между центрами обработки данных, но только в пределах одного региона. Если вы подготовлены в одном регионе, все сообщения будут обрабатываться с помощью маршрутизации почты для этого региона.

Функции EOP

В этом разделе представлен общий обзор основных функций, доступных в EOP.

Сведения о требованиях, важных ограничениях и доступности компонентов во всех планах подписки EOP см. в описании службы Exchange Online Protection.

Примечания.

Служба EOP использует несколько списков блокировок URL-адресов, которые помогают обнаруживать известные вредоносные ссылки в сообщениях.
EOP использует обширный список доменов, которые, как известно, отправляют спам.
EOP использует несколько модулей защиты от вредоносных программ, которые помогают автоматически защищать наших клиентов в любое время.
EOP проверяет активные полезные данные в тексте сообщения и все вложения сообщений на наличие вредоносных программ.
Рекомендуемые значения для политик защиты см. в разделе Рекомендуемые параметры для EOP и Microsoft Defender для Office 365 безопасности.
Краткие инструкции по настройке политик защиты см. в разделе Защита от угроз.