MS Exchange 2013. Пограничный сервер
документация smtp
2015-03-12
Содержание

Роль EDGE для Exchange 2013

Описание

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

Безопасность

Чёрные и белые списки серверов

Пожалуй, самый простой, но не самый надёжный способ обезопасить себя от писем с “левых” почтовых серверов. При получении письма проверяется, не присутствует ли IP отправителя в одном списков.

IP-адреса в списки можно добавлять вручную через powershell, также существуют сторонние сервисы, которые собирают информацию по доверенным и недоверенным IP-адресам.

Сначала IP ищется в вручную созданных списках и только затем в списках сторонних провайдеров

Чёрные списки

Если сервер в чёрных списках, письма отклоняются  с ошибкой SMTP 550, содержащей ответ с причиной отклонения письма.

Минус в том, что в списки случайно может попасть и нормальный почтовый сервер (например, неправильно сконфигурирован и действует как open-relay).

Поэтому хорошей практикой считается указать в ответной ошибке способ исключить себя из чёрного списка.

Также стоит осторожно подходить к выбору провайдера списков, чтобы случайно не заблокировать большинство нормальных отправителей (например, spam.dnsbl.sorbs.net не стоит выбирать)

Команда для просмотра действующего списка

Get-IPBlockListProvider

Белые списки

Если сервер доверенный, пропускаем

Команда для просмотра действующего списка

Get-IPAllowListProvider

SPF-записи

SPF позволяет владельцу домена, в TXT-записи, соответствующей имени домена, указать список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Агенты передачи почты, получающие почтовые сообщения, могут запрашивать SPF-информацию с помощью простого DNS-запроса, верифицируя таким образом сервер отправителя.

Пример SPF-данных в TXT-записи DNS:

example.org. IN TXT "v=spf1 +a +mx -all"

v= определяет используемую версию SPF. Далее следует перечисление механизмов верификации: в данном случае “a” разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; “mx” разрешает прием писем, если отправляющий узел указан в одной из MX-записей для example.org. Строка завершается “-all” — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться “~all” — в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).

Просмотреть настройки SPF в Exchange 2013 можно следующей командой

Get-SenderIdConfig

Параметр отвечающий за то, как обрабатывать spf записи при получении писем с других доменов - SpoofedDomainAction

У него может быть 3 разных значения:

  • StampStatus - Помечает сообщение. Затем метаданные оцениваются агентом фильтра содержимого при вычислении уровня вероятности нежелательной почты. Кроме того, функция “репутация отправителя” использует метаданные сообщения при вычислении уровня репутации отправителя (SRL) сообщения.

  • Reject - Данное действие отклоняет сообщение и посылает ответ об ошибке 5XX SMTP  отправляющему серверу, который соответствует состоянию идентификации отправителя.

  • Delete - Данное действие удаляет сообщение без информирования отправляющего сервера об удалении. В действительности компьютеры с установленной ролью пограничного транспортного сервера посылают ложную SMTP-команду “OK” отправляющему серверу, а затем удаляет сообщение. Так как отправляющий сервер предполагает, что сообщение было доставлено, он не будет пытаться отправить сообщение в том же сеансе.

Цифровые подписи DKIM

Описание

Вместо традиционного IP-адреса, для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Подпись автоматически проверяется на стороне получателя, после чего, для определения репутации отправителя, применяются “белые списки” и “чёрные списки”.

В технологии DomainKeys для аутентификации отправителей используются доменные имена. DomainKeys использует существующую систему доменных имен (DNS) для передачи открытых ключей шифрования.

Требования

  1. Поддержка DKIM почтовым сервером для подписывания отправляемой почты;
  2. Получение пары приватного и публичного ключа;
  3. Занесение в DNS домена необходимых записей о наличии поддержки DKIM.

Настройка DKIM в Exchange 2013

В Exchange 2013 нет нативной поддержки DKIM, однако на GitHub есть проект dkim-exchange, который активно развивается и поддерживает 2013 версию.

Настройка описана в статье на ХабраХабре. Также настройка подробна описана на сайте проекта

В DNS-зоне должны содержаться две txt-записи:

  • _domainkey.example.com. TXT “o=~;”

  • selector._domainkey.example.com. TXT “k=rsa; p={REPLACE_WITH_PUBLIC_KEY_CONTENT}”

Первая запись - это “policy record”

Вторая запись - “public key record”

Поле selector в 2й записи — это селектор DomainKeys. Данное поле позволяет привязать к одному домену несколько DKIM записей для разных нужд (например для разных почтовых серверов). Т.е. его значение может быть любым, совпадающим с значением на сервере. (Например, key1, key2… )

“o=-” means “all e-mails from this domain are signed”, and “o=~” means “some e-mails from this domain are signed”. Additional fields for test (t), responsible e-mail address (r), and notes (n) may also be included - for example “o=-; n=some notes”.

Greylisting

Серые списки (англ. Greylisting) — способ автоматической блокировки спама, основанный на том, что “поведение” программного обеспечения, предназначенного для рассылки спама, отличается от поведения обычных серверов электронной почты. Если почтовый сервер получателя отказывается принять письмо и сообщает о “временной ошибке”, сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать. ru.wikipedia.org

Нативной поддержки такого функционала в Exchange нет, добавляется сторонним кодом на PowerShell.

Настройка соединителей

Чтобы посмотреть список соединителей, надо в Exchange Management Shell выполнить команду

Get-ReceiveConnector | fl

Чтобы посмотреть список разрешений на соединителе с отображенияем ExtendedRigths, выполняем (на примере соединителя Default internal receive connector EDGE и пользователя NT AUTHORITYAnonymous Logon)

Get-ReceiveConnector "Default internal receive connector EDGE" | Get-ADPermission -user "NT AUTHORITYAnonymous Logon" | ft identity,user,extendedrights,accessrights

Чтобы посмотреть разрешения всех пользователей на всех коннекторах:

Get-ReceiveConnector * | Get-ADPermission |ft identity,user,extendedrights,accessrights

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

Get-ReceiveConnector "Default internal receive connector EDGE" | Remove-ADPermission -user "NT AUTHORITYAnonymous Logon" -ExtendedRigths "ms-exch-smtp-accept-authoritative-domain-sender"

Список возможных разрешений можно посмотреть на Technet

Проблемы

Ошибка неправильной DKIM-подписи

При попытке делать массовые рассылки через php оказалось, что подпись становится некорректной, когда проверяется, например, на Яндексе или Gmail. Это связано с тем, что phpmailer по-умолчанию задавал параметр “Content-Transfer-Encoding: 8bit”. Т.е. некоторые данные кодировались 8bit, отправлялось письмо, которое на EDGE подписывалось DKIM, а вот уже принимающий почтовый сервер не читал 8bit, а перекодировал эти данные под себя, из-за чего письмо менялось и dkim оказывался некорректным.

В RFC DKIM сказано, что сообщения всегда должно быть 7bit / quoted-printable encoding

// lib/phpmailer/class.phpmailer.php
<?php
public $Encoding = 'quoted-printable';