У меня вопрос о нашем сервере Exchange: как вы думаете, это хорошая идея - отказываться от входящих внешних сообщений электронной почты, в конце которых указан наш собственный домен?
Как внешняя электронная почта от fake@example.com?
Потому что, если бы оно было от настоящего отправителя в нашей компании, письмо никогда не пришло бы извне?
Если да, то как лучше всего это сделать?
Да, если вы знаете, что электронная почта для вашего домена должна поступать только с вашего собственного сервера, вам следует заблокировать любую электронную почту для этого домена, исходящую с другого сервера. Даже если почтовый клиент отправителя находится на другом хосте, он должен войти на ваш сервер (или любой другой почтовый сервер, который вы используете) для отправки электронной почты.
Сделав еще один шаг, вы можете настроить свой сервер для проверки записей SPF. Вот сколько хостов предотвращают подобную активность электронной почты. Записи SPF - это запись DNS, запись TXT, которая дает правила о том, каким серверам разрешено отправлять электронную почту для вашего домена. Как включить проверку записей SPF, будет зависеть от вашей почтовой службы и выходить за рамки того, о чем мы будем говорить здесь. К счастью, в большинстве сред хостинга и программного обеспечения есть документация по работе с записями SPF. Возможно, вы захотите узнать больше о SPF в целом. Вот статья в Википедии: https://en.wikipedia.org/wiki/Sender_Policy_Framework
Для этого уже существует стандарт. Это называется DMARC. Вы реализуете это с помощью подписи DKIM (что в любом случае неплохо реализовать).
Общий обзор состоит в том, что вы подписываете каждое электронное письмо, покидающее ваш домен, с заголовком DKIM (что в любом случае является хорошей практикой). Затем вы настраиваете DMARC, чтобы отклонять каждое электронное письмо, которое попадает на ваш почтовый сервер из вашего домена, не подписанного действительным заголовком DKIM.
Это означает, что у вас по-прежнему могут быть внешние службы, доставляющие электронную почту в ваш домен (например, размещенное программное обеспечение службы поддержки и т. Д.), Но вы можете блокировать попытки целевого фишинга.
Еще одна замечательная вещь в DMARC - это то, что вы получаете отчеты об ошибках, так что вы можете управлять обработкой исключений по мере необходимости.
Обратной стороной является то, что вам нужно убедиться, что вы все тщательно разобрали, иначе вы можете начать отбрасывать законные электронные письма.
Такая блокировка, вероятно, уменьшит количество спама и, возможно, усложнит социальную инженерию, но может также заблокировать легальную почту. Примеры включают службы пересылки почты, списки рассылки, пользователей с неправильно настроенными почтовыми клиентами, веб-приложения, которые отправляют почту прямо с веб-хоста без использования вашего основного почтового сервера и т. Д.
Dkim может в некоторой степени смягчить это, предоставив способ идентифицировать сообщение, которое было отправлено из вашей сети, прошло через список рассылки или пересылку, а затем было получено по вашей почте, но это не идеальное лекарство, некоторые списки рассылки нарушают подписи dkim и у вас все еще есть проблема с отслеживанием всех законных точек отправления почты и проверкой того, что они проходят через подписывающего dkim.
Действуйте осторожно, особенно при реализации этого в существующем домене.
Возможно, но есть некоторые случаи, которые вам необходимо рассмотреть, прежде чем вносить такие изменения.
1) Использует ли кто-нибудь в вашей компании какие-либо внешние службы (например, Survey Monkey, Constant Contact и т. Д.) Для рассылки электронных писем, которые кажутся "из" вашего домена? Даже если они не делают этого сегодня, могут ли они сделать это в будущем?
2) Есть ли какие-нибудь внешние адреса, которые пересылают вашим пользователям? Например, предположим, что учетная запись gmail «mycompany.sales@gmail.com» перенаправляет на «sales@mycompany.com», а ваш пользователь «bob@mycompany.com» отправляет на «mycompany.sales@gmail.com». В этом случае сообщение будет приходить "извне", но с адресом "@ mycompany.com" От:.
3) Подписаны ли какие-либо из ваших пользователей на внешние списки рассылки, которые сохраняют исходный адрес «От:» в сообщениях в списке? Например, если Боб подписывается на «foo-list@lists.apple.com» и отправляет сообщение, он получит входящее сообщение примерно такого вида: From: bob@mycompany.com To: foo-list@lists.apple. com Отправитель:
Если ваш сервер наивно смотрит на заголовок «От:» (вместо «Отправитель:»), он может отклонить это сообщение, потому что вы получаете его извне.
Из-за всего вышесказанного не всегда возможно иметь общую политику «... от настоящего отправителя в нашей компании электронное письмо никогда не будет приходить извне».
Это можно сделать в PowerShell, обновив разрешения коннектора получения, чтобы исключить анонимных пользователей из возможности отправки в качестве полномочного отправителя домена:
Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender
Однако проблема возникает, когда у вас есть удаленные серверы приложений, которым необходимо отправлять вам электронные письма о статусе, поскольку они обычно используют ваше доменное имя в своем адресе От. Можно создать дополнительный коннектор получения для их конкретных IP-адресов, чтобы случайно не исключить их.
В GMail есть настройка, позволяющая отправлять электронные письма с доменом, отличным от GMail, при условии, что адрес электронной почты будет сначала проверен. Ваше решение заблокирует эти электронные письма.
Есть ли у вас пользователи, которые могут использовать эту функцию GMail, и имеет ли смысл обслуживать их, во многом зависит от поведения в вашей компании.
SPF не вылечит это, поскольку конверт вполне может иметь надлежащий проход SPF (то есть спамеры, использующие скомпрометированный сервер), пока они будут подделывать электронное письмо внутри конверта. Что вам нужно, так это блокировать сообщение электронной почты в вашем собственном домене, в конверте которого указан исходный почтовый сервер, который вам не подходит.