У меня вопрос по поводу нашего сервера Exchange: считаете ли вы хорошей идеей отказаться от входящих внешних писем, которые в конечном итоге имеют наш собственный домен?
Как внешний адрес электронной почты от fake@example.com?
Потому что, если это будет от реального отправителя в нашей компании, электронная почта никогда не будет приходить извне?
Если да, каков наилучший способ сделать это?
security
email-server
exchange-2013
Штеффен Майер
источник
источник
Ответы:
Да, если вы знаете, что электронная почта для вашего домена должна поступать только с вашего собственного сервера, вам следует заблокировать любую электронную почту для этого домена, отправленную с другого сервера. Даже если почтовый клиент отправителя находится на другом хосте, он должен войти на ваш сервер (или любой другой почтовый сервер, который вы используете) для отправки электронной почты.
Сделав этот шаг дальше, вы можете настроить свой сервер для проверки записей 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» From :.
3) Подписаны ли какие-либо из ваших пользователей на внешние списки рассылки, в которых в сообщениях в списке сохраняется оригинальный адрес «От:»? Например, если Боб подписывается на «foo-list@lists.apple.com» и отправляет сообщение, он получит входящее сообщение, похожее на: From: bob@mycompany.com To: foo-list@lists.apple. com Отправитель:
Если ваш сервер наивно смотрит на заголовок «From:» (вместо «Sender:»), он может отклонить это сообщение, потому что вы получаете его извне.
Из-за всего вышеперечисленного, наличие общей политики «... от реального отправителя в нашей компании, электронная почта никогда не пришла бы извне», не всегда осуществимо.
источник
Это можно сделать в PowerShell, обновив разрешения для коннектора получения, чтобы исключить отправку анонимными пользователями в качестве уполномоченного отправителя домена:
Однако проблема возникает, когда у вас есть удаленные серверы приложений, которым нужно отправлять вам электронные письма о состоянии, поскольку они обычно используют ваше доменное имя в своем адресе От. Можно создать дополнительный получающий соединитель для их определенных IP-адресов, чтобы вы случайно не исключили их.
источник
В GMail есть настройка, позволяющая отправлять электронные письма с доменами, не относящимися к GMail, при условии, что адрес электронной почты будет впервые подтвержден. Ваше решение заблокирует эти письма.
Есть ли у вас пользователи, которые могут использовать эту функцию GMail, и имеет ли смысл их обслуживать, во многом зависит от поведения в вашей компании.
источник
SPF не вылечит это, поскольку конверт вполне может иметь надлежащий проход SPF (то есть спаммеры, использующие взломанный сервер), в то время как они будут подделывать электронную почту внутри конверта. Что вам нужно, так это блокировка почтового сообщения на вашем домене с исходным почтовым сервером в конверте, который вам не подходит.
источник