В некоторых случаях необходимо сделать маршрутизацию почты на основании отправителя. Англоязычный термин для данной задачи – Sender Based Routing. Эта задача может быть решена разными способами: различные внешние релеи для почтового сервера, специальные агенты в случае использования MS Exchange (например, Sender Based Routing Agent for Exchange Server) и т.д. В данной заметке хотел поделиться вариантом решения задачи средствами Cisco Email Security Appliance (далее ESA) – бывшим IronPort ESA.

Задача Sender Based Routing актуальна в том случае, когда на одном почтовом сервере необходимо использовать несколько доменов отправителей/получателей. А актуальна она по следующей причине. Подавляющее большинство антиспам-систем проверяет наличие PTR-записи для IP-адреса отправителя. Для одного IP-адреса крайне не рекомендуется иметь несколько PTR-записей. Поэтому, письма от каждого домена почтового сервера нужно отправлять со своего собственного IP-адреса, для которого существует единственная PTR-запись. В противном случае, велика вероятность, что антиспам-система на стороне получателя отбросит письмо. Вот тут и встаёт вопрос, а как же можно раскидывать письма от одного почтового сервера по разным IP-адресам (в частности, отправлять через разных Интернет-провайдеров) на основании домена отправителя?

В моём конкретном примере задача была поставлена следующим образом: нужно отправлять письма определённого домена MS Exchange с IP адреса стороннего провайдера. Другими словами, на сервере MS Exchange предполагалось использовать новый дополнительный домен отправителей/получателей, письма от которых нужно отправлять с IP-адреса удалённого офиса, находящегося в другой стране.

В центральном офисе, где находится сервер MS Exchange, для выхода в Интернет используется МСЭ Cisco ASA. В удалённо офисе также стоит Cisco ASA. Между офисами настроен VPN Site-to-Site по технологии IPsec.

Примерная схема отправки писем представлена ниже:


Письма от домена @ abc.ru должны отправляться через локального провайдера Main ISP с адреса 1.1.1.1, письма от домена @ xyz.ru должны уходить через VPN до удалённого офиса и там выходить в Интернет через локального провайдера Remote ISP с адресом 9.9.9.9. В данной заметке не будет рассматриваться построение VPN Site-to-Site на Cisco ASA и организацию выхода в Интернет через удалённого провайдера, так как данная тема подробно описана как в официальной документации на cisco.com, так и на многочисленных форумах.

Изначально в данной сети заказчика Cisco ESA использовался исключительно как анти-спам решение. Через Cisco ESA проходила только входящая корреспонденция. Отправление писем осуществляется в обход Cisco ESA: сервер MS Exchange слал письма напрямую, куда указывает шлюз по умолчанию, т.е. на Cisco ASA в нашем случае.

Сразу хочется заметить, в организации входящей почты для доменов @ abc и @ xyz никакой хитрости нет. Достаточно опубликовать MX запись для @ abc под адресом основного провайдера (Main ISP), MX запись для @ xyz под адресом удалённого провайдера (Remote ISP) и корректно настроить маршрутизацию и публикации Cisco ESA.

В описываемом примере в инфраструктуре заказчика уже был развёрнут Cisco ESA, который может быть использован как внешний релей для исходящей почты. Поэтому, в первую очередь, я задался вопросом, поможет ли он решить задачу Sender Based Routing? Как выяснилось – да. Данную задачу можно решить, используя фильтры исходящей почты на ESA – Outgoing Content Filters:



Cisco ESA даёт возможность настроить фильтр таким образом, чтобы определённые Email-сообщения отправлялись с другого IP-адреса. На скриншотах ниже представлена настройка Outgoing Content Filters:





Как видно из первого скриншота «Add Condition», Cisco ESA предоставляет широкие возможности отбора писем для применения к ним требуемого действия (из «Add Action»). Причём, можно создавать наборы условий и применять к ним логику AND или OR. Для решения моей задачи достаточно было указать в условии, чтобы в поле MAIL FROM письма содержалась фраза @ xyz. В качестве действия («Add Action») необходимо указать Deliver from IP Interface, и выбрать второй (пока не использующийся) интерфейс Cisco ESA с другим IP адресом. Этот интерфейс называется Data 2. Остаётся только сохранить созданный фильтр под именем, например, Redirect-Filter, и применить созданный фильтр к политике по умолчанию для исходящих писем в разделе Outgoing Mail Policies:



Таким образом получилось настроить Cisco ESA так, чтобы письма от домена домена @ xyz отправлялись с IP-адреса интерфейса Data 2, в то время как письма от домена @ abc будут отправляться в IP-адреса первого интерфейса – Data 1. Для того, чтобы можно было отправлять письма через Cisco ESA, нужно не забыть указать IP-адреса MS Exchange в RELAYLIST таблицы HAT (Host Access Table):



Остаётся настроить MS Exchange для отправки всех писем через Cisco ESA (указать Cisco ESA в качестве Smart Host) и донастроить VPN между офисами для шифрования трафика между IP-адресом интерфейса Data 2 Cisco ESA (с которого отправляются письма домена @ xyz) и Интернет. Фактически, в настройках Cisco ASA нужно добавить IP-адрес интерфейса Data 2 в соответствующий crypto access-list и, при необходимости, поправить правила NAT.

Таким образом, в данной заметке рассмотрели на конкретном примере, как можно использовать Cisco ESA для решения задачи Sender Based Routing. Основная идея предлагаемого решения – отправлять письма первого домена с IP-адреса интерфейса Data 1 Cisco ESA, письма второго домена – c IP-адреса интерфейса Data 2. После присвоения письмам разных IP-адресов появляется возможность маршрутизировать такие письма на сетевом оборудовании любым удобным и доступным способом. В описанном случае, трафик маршрутизировался на Cisco ASA с помощью crypto access-lists, и пакеты заворачивались в VPN-туннель. На маршрутизаторах для этих целей можно использовать Policy Based Routing или VRF.

В заключении хотелось бы отметить, что для реализации описанного функционала на Cisco ESA не требуется приобретение никакой дополнительной лицензии. Достаточно наличия самой обычной лицензии Cisco Email Security Inbound, которая необходима для обеспечения функций антиспама.