Я хочу определить наилучший практический подход к управлению функцией беспорядка в Office 365 на предприятии приличного размера в Office 365. Намерение состоит в том, чтобы предоставить решение, которое обеспечивает гибкость пользователей, но позволяет административному контролю обойти обработку беспорядка для некоторых «критически важных» Сообщения.
Это сочетание правил транспорта для принудительного обхода сообщений, которые вы никогда не хотите собирать, с помощью беспорядка, а также осведомленности и обучения пользователей.
Если пользователи не знают о беспорядке, они, как правило, возненавидят его и будут раздражаться, если не смогут найти сообщение. Когда они понимают, что это значит, я получаю изрядное количество бай-инов, и большинство пользователей оставляют его включенным (небольшой бит все равно отключит).
Я всегда начинаю с одного для новых клиентов, которые гарантируют, что внутренние сообщения не собираются. Раньше я делал это только для таких адресов, как «Руководители» и т. Д., Но обнаружил, что будет лучше, если вы просто оставите все внутренние сообщения в покое. Затем я накладываю сообщения от внешних служб по мере необходимости.
Создайте до четырех отдельных правил транспорта для обработки беспорядка в зависимости от потребностей организации. Выбирайте и выбирайте по мере необходимости!
Действия в правиле в каждом случае одинаковы. Отметьте заголовок сообщения и позвольте ему продолжить свой путь.
Заголовок: X-MS-Exchange-Organization-BypassClutter
Стоимость: true
а. Где находится отправитель: внутри организации
б. Отметьте заголовок, чтобы избежать беспорядка
а. Укажите диапазоны IP-адресов для отправки или отдельные адреса
б. Отметьте заголовок, чтобы избежать беспорядка
а. Где домен отправителя: (список)
б. Отметьте заголовок, чтобы избежать беспорядка
а. Где FromAddressMatchesPatterns = ‘@ domain.com $’
б. REGEX, можно использовать $ для обозначения конца строки. Дополнительные вещи (частичное совпадение) должны привести к сбою.
c. Использует поле От: а не домен отправителя, что может быть более «мягким» соответствием. RFC 5322
d. Этот менее явный и с большей вероятностью будет подделан и т. Д.
е. Этот тип может быть необходим для некоторых внешних сервисов, где SenderDomainIs не обнаруживает необходимых результатов.
f. Отметьте заголовок, чтобы избежать беспорядка.