Хабр, привет! Этой статьёй я продолжаю цикл, посвящённый разным аспектам администрирования Организаций Яндекс 360 для бизнеса. Она будет интересна администраторам почтовой инфраструктуры, которые настраивают миграцию или сосуществование текущей почтовой инфраструктуры с Яндекс 360.

В этой статье:

• Дам немного теории

• Приведу пример настройки с Microsoft Exchange Server, который может совмещать роли наземного почтового сервера и шлюза

• Поясню, как настроить исключения, чтобы сервис «Спамооборона» не отправлял письма в спам

Бонус: расскажу о настройке ящика для несуществующих адресов на Exchange Server в паре с Яндекс 360.

Как говорил мой бывший шеф: «Идеальная сеть — это сеть без пользователей». Если у вас абсолютно новая Организация Яндекс 360 для бизнеса и нет старой почты, то ничего никуда переносить не нужно. Просто создаёте организацию, и можно начинать работать. Единственное, что потребуется, — направить MX-запись вашего домена на серверы Яндекса. Подробнее об этом в Справке в разделе «Настройка вручную».

Но раз вы читаете эту статью, то у вас, скорее всего, уже есть почтовая инфраструктура с пользователями, ящиками, группами. И в этом всём появляется Яндекс 360 для бизнеса.

Чтобы перейти к интеграции почты, сначала нужно создать Организацию Яндекс 360 для бизнеса, настроить домены и добавить пользователей. Подробные инструкции к этим шагам читайте в предыдущих статьях:

• Управление доменами в облачной Организации Яндекс 360 для бизнеса

• Синхронизация учётных записей пользователей в Организацию Яндекс 360 для бизнеса

Начнём с небольшой теоретической справки

В каких ситуациях может потребоваться настроить сосуществование:

• Самое частое — продолжительная миграция или невозможность перенести часть ящиков с наземного сервера в облако. Приходится растягивать SMTP-пространство между землёй и облаком.

• Есть своё антивирусное и (или) антиспам-решение, которое устраивает по функционалу. Важно продолжить его использование, даже когда все ящики переедут в Яндекс 360.

• Есть своя DLP-система, которая контролирует почтовый поток. Независимо от расположения ящиков требуется продолжить её использовать.

Во всех этих случаях нужно будет сделать следующие шаги:

1. Не изменять MX-запись. Важно, чтобы она продолжала указывать на ваш SMTP-шлюз, который принимает почту из интернета.

2. Настроить в вашей почтовой инфраструктуре переадресацию на серверы Яндекс 360 для ящиков, которые мигрировали в облако.

3. Настроить TLS-шифрование на почтовом потоке между Яндекс 360 и шлюзом входящей почты.

4. Настроить исключения для Спамообороны, чтобы она на входе не считала письма с вашего шлюза спамом.

Какие письма будут направляться по MX-записи:

• Весь входящий почтовый поток — из интернета в направлении вашего SMTP-домена

• Весь почтовый поток от почтовых ящиков, расположенных на Яндекс 360, в направлении почтовых ящиков, которые расположены на наземной почтовой инфраструктуре

• Весь почтовый поток между почтовыми ящиками пользователей, расположенных внутри Яндекс 360

Как настроить сосуществование с Microsoft Exchange Server

Допустим, у вас есть Microsoft Exchange Server 2019 с именем ex2019.example.com. На сервере настроен почтовый домен example.com. Этот домен назначен авторитативным, чтобы Exchange Server никуда не пересылал входящие письма для несуществующих адресов домена example.com.

MX-запись во внешней зоне настроена напрямую на Exchange Server. В этом случае она выглядит так: MX=ex2019.example.com. Да, не следует публиковать Exchange Server таким образом, но мы рассматриваем его и как самостоятельный шлюз, и вместе с почтовыми ящиками пользователей.

На этом сервере есть три пользователя с почтовыми ящиками, так называемые Mailbox User (MU):

• User1.onprem@example.com

• User2.y360@example.com

• User3.y360@example.com

Как вы можете догадаться, почтовые ящики второго и третьего пользователей готовим к переносу в Яндекс 360 для бизнеса. О процессе переноса писем из Exchange Server в Яндекс 360 расскажу в другой статье.

Мы стремимся к архитектуре как на схеме ниже:

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

1. В Организации Яндекс 360 для бизнеса добавьте домен example.com, но не меняйте MX-запись. Не обращайте внимания на сообщение об ошибке, что MX-запись не настроена на Яндекс 360. Почта и все сервисы будут работать.

2. Во внешней DNS-зоне example.com добавьте DKIM-запись и модифицируйте SPF-запись, чтобы разрешить отправлять письма из Яндекс 360 для домена example.com.

3. На сервере Exchange измените тип домена с «authoritative/авторитативный» на «Internal relay / внутренней ретрансляции».

   Перейдите в Exchange Admin Center в раздел mail flow → accepted domains и на вашем домене измените настройки на internal relay как на экране ниже.

   

4. На сервере Exchange настройте на входящем коннекторе, который принимает почту из интернета, шифрование TLS. Это нужно, чтобы письма, которые приходят из Яндекс 360 в направлении наземных пользователей, шли по шифрованному каналу. Не забываем, что речь идёт о внутренней переписке между коллегами, которые расположены в облаке и на земле.

   Перейдите в Exchange Admin Center, в раздел mail flow → Receive connectors и на коннекторе проверьте, что TLS включён как на экране ниже.

5. На сервере Exchange настройте Send Connector в направлении смарт-хоста mx.yandex.net для домена example.com.

   Пример командлета:

   New-SendConnector -Name ToYandex360 -AddressSpaces example.com -smarthosts mx.yandex.net

6. В Яндекс 360 создайте пользователей user2.y360@example.com и user3.y360@example.com. Самый удобный способ — синхронизация, о которой я рассказал в прошлой статье.

7. На сервере Exchange конвертируйте пользователей user2.y360@example.com и user3.y360@example.com из Mailbox User (MU) в MailEnabledUser (MEU). Для этого нужно выполнить два командлета для каждого пользователя:

   Disable-Mailbox -Identity user3.y360@example.com -Confirm:$false

   Enable-MailUser -Identity user3.y360@example.com -ExternalEmailAddress user3.y360@example.com

Проверка корректности всех настроек

Проверять будем «научным» методом: отправим письмо и проанализируем headers. Ниже мы видим headers письма, которое отправил пользователь user2.y360@example.com из Яндекс 360 для бизнеса на адрес user3.y360@example.com, который тоже расположен в Яндекс 360 для бизнеса. Чтобы было удобнее ориентироваться, я добавил номера строк.

1. Received: from postback14b.mail.yandex.net (postback14b.mail.yandex.net [2a02:6b8:c02:900:1:45:d181:da14]) by pefay7p3l667xfgs.iva.yp-c.yandex.net (notsolitesrv/Yandex) with LMTP id bwm9l2T5HzKG-ADoR375C for <user3.y360@example.com>; Mon, 12 Feb 2024 22:35:04 +0300

2. Received: from mail-nwsmtp-mxfront-production-main-80.sas.yp-c.yandex.net (mail-nwsmtp-mxfront-production-main-80.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:6709:0:640:d796:0]) by postback14b.mail.yandex.net (Yandex) with ESMTPS id C5FC05E4B for <user3.y360@example.com>; Mon, 12 Feb 2024 22:35:04 +0300 (MSK)

3. Received: from ex2019.example.com (unknown [Х.Х.Х.Х]) by mail-nwsmtp-mxfront-production-main-80.sas.yp-c.yandex.net (mxfront/Yandex) with ESMTPS id 4ZsAOo2L9a60-ubNAJopQ; Mon, 12 Feb 2024 22:35:04 +0300

4. X-Yandex-Fwd: 2
   Authentication-Results: mail-nwsmtp-mxfront-production-main-80.sas.yp-c.yandex.net; spf=softfail (mail-nwsmtp-mxfront-production-main-80.sas.yp-c.yandex.net: transitioning domain of example.com does not designate Х.Х.Х.Х as permitted sender, rule=[~all]) smtp.mail=user2.y360@example.com; dkim=pass header.i=@example.com
   X-Yandex-Spam: 1

5. Received: from ex2019.example.com (10.129.0.11) by ex2019.example.com (10.129.0.11) with Microsoft SMTP Server (version=TLS1_2, cipher=
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Mon, 12 Feb 2024  22:34:15 +0300

6. Received: from forward103b.mail.yandex.net (178.154.239.150) by ex2019.example.com (10.129.0.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Mon, 12 Feb 2024 22:34:15 +0300

7. Received: from mail-nwsmtp-mxback-production-main-46.sas.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-46.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:8312:0:640:a7ae:0]) by forward103b.mail.yandex.net (Yandex) with ESMTPS id 0CA9E608F4 for <user3.y360@example.com>; Mon, 12 Feb 2024 22:35:04 +0300 (MSK)

8. Received: from mail.yandex.ru (2a02:6b8:c08:7f27:0:640:7993:0 [2a02:6b8:c08:7f27:0:640:7993:0]) by mail-nwsmtp-mxback-production-main-46.sas.yp-c.yandex.net (mxback/Yandex) with HTTP id lYsDmYHOuiE0-p9hkMirJ; Mon, 12 Feb 2024 22:35:03 +0300

9. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail; t=1707766503; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= h=Message-Id:Date:Subject:To:From; b=DvKVDB04BTYh8k0K2EuA2YJ8FjYO6KueH7f+thYPc/zJB/HaE08Hl51ovJUTYajuc  UOHwr/eLzlqHgFO0RLzP9beTYGXCzvf7fyd75evOKlvfB25TCvWgM9YjfPiFOv1cCf I35APunTf9dLFBB0QczP6pLvB2J4j7BRzvCiugoo=

10. Received: by 2kmipagb6w7jjvhg.sas.yp-c.yandex.net with HTTP; Mon, 12 Feb 2024 22:35:03 +0300

11. From: =?utf-8?B?0J/QvtC70YzQt9C+0LLQsNGC0LXQu9GMINCe0LHQu9Cw0YfQvdGL0Lk=?= <user2.y360@example.com>

12. To: =?utf-8?B?0J/QvtC70YzQt9C+0LLQsNGC0LXQu9GMINCe0LHQu9Cw0YfQvdGL0Lk=?= <user3.y360@example.com> Subject: =?utf-8?B?0YfQtdGA0LXQtyDRiNC70Y7QtyDQstGF0L7QtNGP0YnQtdC5INC/0L7Rh9GC0Ys=?= MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 12 Feb 2024 22:35:03 +0300
    Message-Id: <69351707766484@mail.yandex.ru>
    Content-Type: text/plain
    X-CrossPremisesHeadersFilteredBySendConnector: ex2019.example.com
    X-OrganizationHeadersPreserved: ex2019.example.com

13. Return-Path: user2.y360@example.com
    X-Yandex-Forward: 1cb25fedcd9858404baf49ae1e06e807

Давайте разбираться, что видно из headers.

Строки 11 и 13 говорят, что письмо ушло с адреса user2.y360@example.com без какой-либо подмены, спуфинга и т. п.

Строка 12 показывает поле «To:» и что предназначалось адресу user3.y360@example.com.

Строка 10 говорит, что письмо было сформировано и отправлено из веб-интерфейса почты Яндекс 360.

Строка 8 говорит, что письмо сначала принял SMTP-транспорт почты Яндекс 360.

Строка 6 говорит, что письмо получил Exchange Server. А информация (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) указывает на то, что было успешно применено TLS-шифрование.

Строка 3 говорит, что транспорт почты Яндекс 360 принял письмо от Exchange, используя ESMTPS (тоже с шифрованием).

Видим, что письмо, отправленное от одного сотрудника другому в Яндекс 360, прошло через наземный шлюз — в нашем случае им был Exchange Server. Всё успешно работает!

Если Exchange Server нужно будет переслать какое-то письмо от коллеги или извне в почту Яндекс 360, то в headers мы увидим строки 1–3, а строк 6–8 там не будет. Такое письмо сразу придёт в ящик пользователя почты Яндекс 360.

Как настроить исключения для Спамообороны

Интеграция работает, но это ещё не всё — могут быть нюансы с защитой от спама. Так как защита от спама — это всегда работа с вероятностью, надо помочь Спамообороне правильно классифицировать письма с земли в облако и не отправлять их в спам.

Нужно добавить в список allowlist IP-адрес вашего шлюза или, как в примере с Exchange, адрес сервера, через который Спамооборона принимает письма в Яндекс 360. Это можно сделать через API админки Яндекс 360. Подключиться к API админки можно по инструкции в статье.

Сама ручка управления исключениями доступна через метод POST по url: https://api360.yandex.net/admin/v1/org/IDОрганизации/mail/antispam/allowlist/ips/

Тело запроса в формате JSON:

{
    "allowList": [
        "172.15.0.0/23",
        "1.1.1.1"
    ]
}

Бонус: настройка ящика для потеряшек

При работе с Exchange Server многие сталкиваются с простой, на первый взгляд, задачей, которую на деле не так просто решить «из коробки». Как собирать все входящие письма, которые пришли на почтовый сервер на несуществующие адреса обслуживающего домена?

Такие письма часто появляются из-за обычной опечатки в адресе. Или когда в компании используется домен вида example.com, а отправляют на example.ru или другие. Exchange Server может переслать эти письма или отбросить, но не может положить в какой-нибудь отдельный ящик. Можно попробовать создать сложные транспортные правила, но у них свои подводные камни.

В Яндекс 360 для бизнеса есть шикарный способ: в конфигурации, когда вы настроили всё, что я описал выше, можно собирать письма на несуществующие адреса домена в безлимитный почтовый ящик. При этом не придётся перегружать локальную инфраструктуру.

Допустим, у вас настроена синхронизация, и вы хотите завести в Яндекс 360 для бизнеса ящик для потеряшек. Вот как это сделать:

1. Создайте mail enabled user на Exchange Server с маршрутизацией на его же адрес. Можно применить командлет:

   New-MailUser -name no_users -ExternalEmailAddress no_users@example.com.

2. Запустите синхронизацию, чтобы пользователь появился в Яндекс 360 для бизнеса.

3. В Яндекс 360 для бизнеса перейдите на портал управления организацией admin.yandex.ru, откройте раздел «Настройка почты» и выберите адрес для потерянных писем.

   

После этого все входящие письма, в которых прописаны несуществующие в домене Exchange адреса и которые пересылают в Яндекс 360, будут падать на адрес, указанный в настройках. Помним, что это происходит из-за того, что домен мы сделали internal relay.

Теперь вы сможете быстро найти и просмотреть такие письма, даже если кто-то опечатался в адресе сотрудника.

Что имеем в итоге

В этой статье мы с вами разобрались, как можно подружить свой шлюз входящей почты с Яндекс 360 для бизнеса. В нашем примере в качестве шлюза использовался Exchange Server, но на его месте должен был быть я может быть любой шлюз или почтовый сервер — логика останется такой же.

Ещё разобрались с headers: увидели, как письмо «пробежалось по кругу» и дошло до пользователей. Обсудили, как можно настроить в такой конфигурации ящик для потеряшек — попробуйте это сделать. А если возникнут вопросы, задавайте в комментариях, я буду рад ответить.

Оставляю вопрос для знатоков. Зачем я соорудил конструкцию в виде конвертации Mailbox User в MailEnabledUser? Скажите, что будет или чего не будет, если вместо конвертации просто удалить Mailbox пользователей?