Exchange 2010 – часть 3

Exchange 2010 LogoВыпускаем Microsoft Exchange 2010 в Интернеты

Не смотря на то, что функции по приему и отправки сообщений может выполнять Hub Transport Server (HTS) ведущие собаководы рекомендует для это специально отведенную роль – Edge Transport Server (ETS). Но перед тем, как бросаться грудью на амбразуру мы изучим информацию, которую надо знать прежде чем щелкать мышкой направо-налево.

В процессе подготовке к введению в эксплуатацию я подготовил себе небольшой implementation plan, первой стадией которого было выяснение следующих вещей:

  • Выяснить кто отвечает за публичные DNS сервера которые обслуживают ваш общедоступный домен.
  • Выяснить кто отвечает за DNS PTR записи.
  • Выяснить для каких доменов вы будете получать почту.
  • Определиться с MX, A, PTR и SPF записями для вашей компании.
  • Задокументировать IP адреса с которых будет отправляться и получаться почта.
  • Выяснить существует ли у вас один или более путей маршрутизации входящей и исходящей почты, что позволит осуществить миграцию с одного почтового сервера на другой в условиях нулевого maintenance window.
  • Выяснить существует ли сервера, которые используются для дальнейшей маршрутизации исходящей почты (SMTP Smart Host) или исходящая почта будет доставляться непосредственно получателям на основании DNS MX записей.
  • Самый важный момент, который вам спасет в будущем кучу нервов – задокументировать пути по которым поступает почта, оповестить администраторов ERP и других систем,  о предстоящих изменениях в топологии маршрутизации, а так же о возможных сбоях в работе почтовой системы.

Шаги, которые нужно предпринять для успешной обработки входящих сообщений

  • Определиться будет ли почта поступать на ваши публичные IP адреса или сервис провайдер будет для вас выполнять антивирусную/антиспам проверки, а лишь затем перенаправлять сообщения на ваши почтовые адреса.
  • Определиться с тем, будет ли сообщения доставляться напрямую на Exchange сервера (HTS роль в данном случае) или они должны будут проходить проверки на ETS и/или других SMTP серверах.
  • Для каждого хоста, который будет осуществлять прием сообщений должна существовать публичная DNS запись A, которая ему соответствует. Например mail1.company.ltd IN A 10.1.1.1
  • Для каждого домена, который будет осуществлять прием сообщений должна существовать MX запись, указывающая на A запись. Например company.ltd MX 10 mail1.company.ltd. Число 10 обозначает приоритет с которым отправитель будет пытаться достучаться до ваших MX серверов. Например запись:
company.ltd MX 10 mail1.company.ltd
company.ltd MX 20 mail2.company.ltd

говорит буквально следующее – попробуй доставить почту для домена company.ltd через сервер mail1.company.ltd, а если не выйдет, то через сервер mail2.company.ltd. Запись:

company.ltd MX 10 mail1.company.ltd
company.ltd MX 10 mail2.company.ltd

в теории будет осуществлять round-robin балансировку между двумя почтовыми серверами, однако на практике это редко происходит. Основываясь на моем опыте один из почтовых серверов всегда оказывается нагруженным сильно больше другого. Балансировку в таком случае лучше осуществлять на DNS серверах.

Шаги, которые нужно предпринять для успешной отправки сообщений

  • Убедиться в том, что ваши публичные IP адреса не занесены в real-time block lists (RBL). Попадание в RBL может быть следствие того, что прошлый администратор мудак и хостил на этих IP адресах open-replay сервера (common case). Или ваши клиенты усердно рассылали спам из-за NAT/PAT потому что прошлый администратор мудак и не обновлял антивирусы с 2009 года. Проверить это можно, например, на сайте www.dnsbl.info.
  • Убедиться в том, что каждый публичный адрес имеет действительную PTR запись. Идеальный вариант, это когда PTR запись соответствует тому, что ваши сервера отвечают в EHLO/HELO командах, но так как мы не живем в идеальном мире и /29 сетки выделенной провайдером на все может и не хватить, то хорошо бы по крайней мере видеть в PTR записи ваш домен. Проверить можно с помощью команды nslookup -q=ptr 8.8.4.4
  • Очень желательно, но отнюдь не обязательно иметь SPF запись, которая позволяет однозначно идентифицировать хосты, авторизованные для отправки сообщений от имени вашего домена. Прочитать о SPF можно на wiki. Создать ее можно воспользовавшись одним из бесчисленных визардов, например этим.

Концепция Accepted Domains, их типы

Accepted domains – есть пространство SMTP имен (SMTP Domain name/SMTP namespace), которое будет обслуживаться вашим почтовым сервером. У организации может появиться несколько таких пространств имен, например в результате слияния с другой компанией или из-за требований надзорных органов. При обработке писем, которые поступают на адресе, принадлежащих этим доменам ETS и HTS должны всегда принимать такие письма. В отличии от ситуации когда ваш SMTP сервер используется для отправки писем на адреса, находящиеся в другом домене. Правильный SMTP сервер в таком случае всегда попросит вас пройти аутентификацию, иначе он – open relay и кандидат в RBL. HTS, по умолчанию имеет accepted domain эквивалентный имени домена AD. ETS по умолчанию имеет пустой список accepted domains.

Такие домены называются authoritative domains.

Домены, которые позволяют пропускать через сервера сообщения, которые затем передаются третьим SMTP серверам называются relay domains, которые, в свою очередь, бывают внутренними (internal relay domain) и внешними (external relay domain).

Internal Relay Domain

Когда вы настраиваете Internal Relay Domain несколько или, даже, все получатели этого домена не имеют почтовых ящиков на Exchange сервере. Допустим у вас есть две почтовые системы и вы находитесь в процессе миграции с одну на другую. В таком случае пользователи в каждой почтовой системе будут иметь одинаковый суффикс (shared address space) – @company.ltd, как часть их почтового адреса some.user@company.ltd.

В таком случае вам следует создать accepted domain с типом internal relay domain. Так же вам следует добавить Send Connector на HTS/ETS и настроить его отправлять письма серверам, разделяющим один shared address space. В случае если accepted domain настроен как authoritative и получатель не будет найдет в AD отправитель получит non-delivery report (NDR). В случае если accepted domain имеет тип internal relay domain сперва будет предпринята попытка доставить сообщение получателю в AD и если она провалится, то будет произведена маршрутизация сообщения по направлению к Send Connector’у, входящему в shared address space.

External Relay Domain

Разница состоит лишь в том, что предполагается передача сообщений снаружи периметра вашей организации.

exchange 2010 relay domains

Remote Domains

О чем еще стоит поговорить в контексте отправления писем в интернеты, так это о Remote Domains. Remote domains позволяют настроить политику касательно отправления Out-Of-Office сообщений, а так же о форматировании сообщений.

Out-Of-Office (OOOf) опции:

  • Allow none – для указанных доменов OOOf сообщения отправляться не будут.
  • Allow External Out-Of-Office Messages Only – позволяет отправлять OOOf только в том случае, если пользователь настроил внешнее сообщение в OWA или Outlook 2007+
  • Allow External Out-Of-Office Messages And Legacy Out-Of-Office Messages – позволяет отправлять OOOf вне зависимости от того настроил ли пользователь внешние сообщения в OWA/Outlook 2007+ или в Outlook 2003.
  • Allow External Out-Of-Office Messages And Legacy Out-Of-Office Messages – позволяет отправлять внутренние OOOf сообщения вне зависимости от типа клиента, используемого пользователем.

С форматированием сообщений проблем возникнуть не должно, все опции предельно наглядны as it is.