Как развернуть почтовый сервер на windows

Почтовый сервер – это устройство, при помощи которого происходит доставка электронных сообщений от отправителя к получателю. Собственно, это и следует из его названия. В данной статье рассмотрим, как происходит установка и базовая настройка почтового сервера на VPS с операционной системой семейства Windows Server, а также на виртуальном сервере, работающем на Ubuntu 20.04.

Установка сервера SMTP на Windows Server

На серверах, работающих под управлением операционных систем Windows, для передачи почтовых сообщений часто используется протокол SMTP. В Windows Server служба SMTP является одним из компонентов операционной системы.

Для корректной отправки почтового сообщения от имени домена, к которому будет привязан сервер SMTP, нам необходимо иметь доменное имя. При этом в настройках домена должна быть указана A-запись, содержащая IP-адрес VPS. В нашем примере мы будем использовать имя домена my-domain.host.

Установку почтового сервера нужно будет начать именно с добавления необходимых компонентов. Для этого запустите Server Manager, перейдите Manage → Add Roles and Features.

В открывшемся окне нажмите Next.

Далее выберите опцию Role-based or feature-based installation, после чего нажмите Next.

В следующем окне укажите сервер, на который будет производиться установка новых компонентов, либо просто нажмите Next, если в вашем пуле серверов одна-единственная запись.

На следующем шаге активируйте строку Web Server (IIS), после чего нажмите Add Features.

Далее нажмите Next.

После чего отметьте строку SMTP Server и нажмите Add Features.

И нажмите Next.

Далее ещё раз нажмите Next.

В следующем окне снова нажмите Next.

Для запуска установки выбранных компонентов нажмите Install.

Настройка сервера SMTP

На следующем этапе необходимо будет настроить сервер SMTP. Для чего в Server Manager перейдите Tools → Internet Information Services (IIS) 6.0 Manager.

В открывшемся окне менеджера IIS раскройте ветку вашего сервера и на строке SMTP Virtual Server нажмите правую кнопку мыши, после чего перейдите в Properties.

Далее в строке IP address: необходимо выбрать IP-адрес вашего сервера и активировать опцию Enable logging.

Во вкладке Access нажмите кнопку Authentication...

В открывшемся окне активируйте опцию Anonymous access. Активация данной опции нужна, чтобы пользователи и приложения смогли бы использовать сервер SMTP анонимно. Позже можно будет настроить более безопасную аутентификацию, пока же нажмите OK.

Далее в разделе Connection control нажмите кнопку Connection...

В окне Connection установите переключатель на Only the list below и при помощи кнопки Add... добавьте IP-адрес вашего VPS. После чего нажмите OK.

Точно такую же настройку необходимо проделать в разделе Relay restrictions. Для чего нажмите кнопку Relay... и добавьте IP-адрес вашего сервера установив переключатель в Only the list below.

После чего перейдите во вкладку Delivery и нажмите Advanced...

Здесь в строку Fully-qualified domain name: необходимо внести имя вашего домена, в нашем примере это – my-domain.host.

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

Далее сохраните все внесённые в настройки изменения при помощи кнопки OK.

Также необходимо указать корректное имя домена в ветке Domains.

На следующем шаге нужно активировать функцию автоматического запуска сервера SMTP. Для этого запустите командную строку PowerShell и выполните следующие команды для запуска службы:

set-service smtpsvc -StartupType Automatic
start-service smtpsvc

Чтобы убедиться, что служба запущена, необходимо выполнить ещё одну команду:

get-service smtpsvc

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

Теперь там же, в командной строке PowerShell, при помощи следующей команды отправьте сообщение на свою электронную почту:

Send-MailMessage -SmtpServer my-domain.host -To your@email.address -From mail@my-domain.host -Subject "Message Subject" -Body "Message Body"

Здесь:

• my-domain.host – имя домена, с которого будет производиться отправка сообщения;
• your@email.address – адрес электронной почты, на который будет отправлено сообщение;
• mail@my-domain.host – этот электронный адрес будет указан в сообщении как адрес отправителя;
• Message Subject – тема письма;
• Message Body – тело письма.

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

Установка и настройка Postfix на Ubuntu 20.04

Для операционной системы Ubuntu существует довольно популярный почтовый сервер – Postfix. Для установки Postfix мы будем использовать виртуальный сервер, работающий на Ubuntu 20.04. При этом на VPS должны быть произведены работы по первоначальной настройке, описанные в соответствующей статье нашего справочника.

Также, для работы Postfix нужен домен с привязанной A-записью, которой является IP-адрес вашего виртуального сервера.

Плюс ко всему, необходимо соотнести имя домена с именем сервера и его IP-адресом. Для этого запустите следующую команду:

$ sudo hostnamectl set-hostname ubuntu-server

Здесь, ubuntu-server – имя нашего сервера, вместо которого вы можете использовать своё.

Теперь при помощи текстового редактора откройте файл /etc/hosts:

$ sudo nano /etc/hosts

В данный файл добавьте строку:

XXX.XXX.XXX.XXX my-domain.host ubuntu-server

В данном случае:

• XXX.XXX.XXX.XXX – IP-адрес вашего сервера;
• my-domain.host – имя вашего домена;
• ubuntu-server – имя вашего сервера.

Теперь запустите установку Postfix и почтового пакета mailutils:

$ sudo apt install postfix mailutils

В процессе установки система попросит вас выбрать тип конфигурации. Необходимо указать Internet Site:

Также установщик попросит согласиться с именем домена, в отношении которого производится настройка почтового сервера. В нашем случае это будет my-domain.host.

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

$ echo "Message Body" | mail -s "Message Subject" your@email.address

В данной команде:

• Message Body – тело письма;
• Message Subject – тема письма;
• your@email.address – адрес электронной почты, на который будет отправлено сообщение.

Проверьте свой почтовый ящик (в нашем примере это – your@email.address), на который должно прийти отправленное из Postfix сообщение.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общее устройство и принципы работы почтового сервера

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

Давайте рассмотрим схему ниже, она предельно упрощена и содержит только самые важные элементы, которые лежат в основе любой почтовой системы.

Их ровно три:

• Message transfer agent (MTA) — агент передачи сообщений. Данный компонент, собственно, и является почтовым сервером в узком понимании этого термина, он работает по протоколу SMTP и его основная задача прием и передача почтовых сообщений, как для внешних получателей, так и для внутренних. Взаимодействует как с внешними серверами, так и с почтовыми клиентами. И это единственный компонент почтового сервера, который имеет связь с внешним миром. Основная задача MTA — это отправка почты внешним получателям и получение почты для внутренних.
• Message delivery agent (MDA) — агент доставки сообщений. Он обеспечивает доставку полученных от MTA сообщений к месту прочтения клиентским приложением. Проще говоря, именно с помощью MDA почтовый клиент может получить доступ к собственной почте. Работает по протоколам POP3 и IMAP, также отдельные решения могут использовать проприетарные протоколы, такие как MAPI Exchange. MDA не взаимодействует с внешними системами и не принимает участие в отправке почты, его задача — доставка уже полученных сообщений клиенту почтовой системы.
• Хранилище почтовых ящиков — третий компонент почтового сервера, отвечающий за хранение полученных и отправленных сообщений. Различные системы могут использовать разные форматы хранения, в Linux системах наиболее распространены mbox и Maildir, но на этом варианты хранилищ не исчерпываются.

С почтовым сервером взаимодействует клиент электронной почты — Mail User Agent (MUA) — он может быть как в виде отдельного приложения, так и в виде популярного ныне веб-интерфейса. В любом случае это только разновидности почтового клиента, принцип их работы одинаков.

Когда пользователь хочет получить свою почту, он обращается к агенту доставки сообщений (MDA), сегодня MDA несут важную дополнительную функцию — ведение базы пользователей и их аутентификацию. Проверив, что пользователь тот, за кого себя выдает MDA предоставляет ему доступ к собственному ящику в хранилище при помощи выбранного пользователем протокола. Во всех современных решениях используется протокол IMAP, который позволяет гибко управлять собственным почтовым ящиком и не требует обязательного скачивания сообщений клиентом.

Если же мы хотим отправить почту, то почтовый клиент связывается с MTA, либо с дополнительным компонентом — Message submission agent (MSA) — агентом отправки почты, он использует отдельный порт — 587 и его задача получение сообщений от почтового клиента и передача их MTA для отправки по назначению. Вне зависимости от наличия MSA клиент всегда может отправить почту непосредственно через MTA.

Мы не стали добавлять MSA на основную схему, чтобы не плодить дополнительных сущностей, но о его существовании надо знать, чтобы не удивляться наличию дополнительного порта на почтовом сервере. Его появление во многом обусловлено ограниченностью протокола SMTP, тогда как для взаимодействия с клиентами нужны были дополнительные функции, поэтому MSA работает через протокол ESMTP (Extended SMTP) и поддерживает, например, такие возможности, как аутентификацию пользователей. Чаще всего функции MTA и MSA выполняет один и тот же пакет.

Теперь, читая, скажем, про связку Postfix + Dovecot + Roundcube вы будете четко понимать, что речь идет про MTA (Postfix), MDA (Dovecot) и веб-клиента MUA (Roundcube), представлять назначение каждого компонента и не путаться во взаимодействии с ними.

Обязательные DNS-записи: MX и PTR

Итак, мы хотим отправить почту. Пользователь открывает MUA, быстро создает сообщение и нажимает кнопку Отправить. Дело сделано, но мало кто задумывается о том, что происходит после, все мы привыкли что уже через считанные секунды наше сообщение будет в почтовом ящике получателя.

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

Первым в дело вступает MTA, он анализирует поле адреса назначения в заголовках письма, допустим мы видим там:

To: Maria Smirnova <MSmirnova@example.org>
From: Ivanov Ivan <IIvaniov@example.com>

Если домен получателя отличается от обслуживаемого MTA домена, то он должен каким-то образом узнать, кому именно отправлять почту. Для этого он использует систему DNS, запросив специальную запись — MX. MX — Mail Exchanger — особая DNS-запись, указывающая на адрес почтового шлюза домена, таких записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.

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

@ IN MX 10 srv-mx-01
srv-mx-01 IN A 203.0.113.25

Первая запись — это MX-запись для домена, которая говорит кому отправлять почту. Вторая запись сопоставляет имя srv-mx-01.example.com и действительный IP-адрес узла.

Часто администраторы предпочитают использовать псевдонимы — CNAME — для указания на отдельные почтовые узлы. Это удобно, но в любом случае MX-запись должна содержать реальное имя узла, а не псевдоним, поэтому правильно будет так:

@ IN MX 10 srv-mx-01
smtp IN CNAME srv-mx-01
imap IN CNAME srv-mx-01
srv-mx-01 IN A 203.0.113.25

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

@ IN MX 10 srv-mx-01
@ IN MX 20 srv-mx-02
srv-mx-01 IN A 203.0.113.25
srv-mx-02 IN A 198.51.100.25

Если сервер-отправитель не сможет отравить почту первому MX-серверу в списке, то он переключится на второй. Обратите внимание на разный приоритет серверов: 10 и 20, таким образом пока доступен сервер с приоритетом 10 почта никогда не будет направляться серверу с приоритетом 20.

А если мы укажем несколько серверов с одинаковым приоритетом? Почта будет направляться на все из них по принципу Round-robin, т.е., чередуясь по кругу, такое решение можно использовать для балансировки нагрузки.

C MX-записями разобрались, переходим к PTR. PTR — Pointer — соответствие адреса имени, позволяет на основании IP-адреса получить имя хоста этого узла. Какое это имеет отношение к отправке и получению почты? Да никакого, наличие или отсутствие PTR-записи никак не влияет на процесс отправки или получения почты. Но зачем же тогда она нужна?

Основное ее назначение — это защита от спама. Уже давно существует соглашение, что добросовестный отправитель почты имеет PTR-запись. Это позволяет сразу отсечь огромный пласт взломанных и инфицированных систем, потому как прописать PTR-запись может только владелец IP-адреса, т.е. хостер или провайдер. Поэтому даже получив полный доступ к инфраструктуре, включая DNS-сервер, злоумышленник все равно не сможет добавить или изменить PTR-запись.

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

25.113.0.203 IN PTR srv-mx-01.example.com.

Обращаем внимание на то, что в PTR всегда указывается полное доменное имя FQDN и обязательно с точкой на конце. Но это знание более академическое, так как обратной зоной будет управлять ваш провайдер и прямого доступа туда у вас не будет.

Еще один интересный момент, это обратные записи для нескольких каналов одного сервера, ошибкой будет прописать:

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-02.example.com.

Почему? Да потому что сервера srv-mx-02 у нас физически не существует, мы придумали его как второе имя для основного сервера srv-mx-01 и в заголовках писем в качестве отправителя будет присутствовать именно это имя. Кроме того, как мы уже говорили, MX-сервера не имеют никакого отношения к процессу отправки почты.

Поэтому правильно будет сделать PTR-записи так:

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-01.example.com.

И еще раз предупредим, все записи выше даны сугубо в академических целях, в реальности вам нужно будет только сообщить провайдеру (или провайдерам) для какого узла им нужно сделать PTR-запись.

SPF — Sender Policy Framework

SPF — это специальный тип DNS-записи в формате TXT, позволяющий владельцу домена указать те узлы, которые имеют право отправлять почту от имени домена. Эта запись не является обязательной, но ее наличие резко снижает вероятность попадания вашей корреспонденции в спам.

Чаще всего содержимое SPF сводится к стандартному:

@ IN TXT "v=spf1 +a +mx ~all"

Запись состоит из списка тегов и значений, теги в SPF-записи называются механизмами и могут иметь следующие значения:

• v — версия SPF, это обязательный механизм, сейчас доступно единственное значение v=spf1
• a — определяет узлы на основе доменного имени (A-записи), формат a:example.com, если домен не указан, то применяется текущий домен
• mx — определяет узлы на основе MX-записей домена, если домен не указан, то применяется текущий домен
• ip4/ip6 — определяет узлы на основе IPv4 или IPv6 адреса
• all — все остальные узлы
• include — включает в состав SPF-записи указанного домена, например, include:_spf.yandex.net
• redirect — использовать для домена SPF-записи указанного домена.

Для уточнения действий к механизмам применяются квалификаторы (префиксы):

• + — Аутентификация пройдена. Узлу разрешена отправка почты от имени домена.
• — — Аутентификация не пройдена. Узлу запрещена отправка почты от имени домена.
• ~ — Аутентификация с неполным отказом. Скорее всего, узлу запрещена отправка почты от имени домена.
• ? — Нейтральный квалификатор, обозначает что для узла нет явных указаний, обычно используется как ?all

Таким образом стандартная запись читается как: разрешено отправлять почту узлам перечисленным в A и MX записях домена, остальным, скорее всего запрещено. При аутентификации с неполным отказом письма от прочих узлов обычно не отвергаются получателем, а помечаются как подозрительные. Квалификатор «+» подразумевается по умолчанию и его можно не указывать. Если нам нужно указать несколько узлов, то используем несколько механизмов. Например:

@ IN TXT "v=spf1 a a:mail.example.org mx -all"

Здесь мы указали, что отправлять почту можно с узлов указанных в A и MX записях текущего домена, а также с узла mail.example.org.

Если у вас есть домены с которых никогда не должна отправляться почта, то не будет лишним указать для них следующую SPF-запись:

@ IN TXT "v=spf1 -all"

Теперь немного об include и redirect, может показаться, что они делают одно и тоже, но есть тонкости. Механизм redirect просто перенаправляет вас к записям указанного в нем домена. Это удобно, если сервер обслуживает сразу несколько доменов, это позволяет иметь одну единственную запись, которую будут использовать все остальные. Также это применяется при использовании своего домена совместно c публичными почтовыми системами:

@ IN TXT "v=spf1 redirect=_spf.yandex.net"

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

Если же вместе с публичными сервисами вы используете собственные сервера, то вам нужно использовать механизм include, который подгрузит записи указанного домена к вашим собственным.

@ IN TXT "v=spf1 ip4:203.0.113.25 include=_spf.yandex.net ~all"

Данная запись говорит о том, что отправлять почту имеет право узел с адресом 203.0.113.25, а также все остальные, которые перечислены в записях указанного домена.

DKIM — DomainKeys Identified Mail

Если говорить коротко, то DKIM — это технология электронно-цифровой подписи, которая позволят получателю убедиться, что письмо действительно принадлежит отправителю. Для этого на каждом почтовом сервере, которые отправляют почту в нашем домене мы генерируем ключевую пару RSA. Закрытый ключ мы добавляем в конфигурацию почтового сервера и теперь он будет подписывать все исходящие письма.

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

Для того, чтобы проверить подлинность подписи мы публикуем открытый ключ и используем для этого систему DNS, сформировав специальную запись типа TXT:

m1._domainkey TXT "v=DKIM1; k=rsa; p=<публичный ключ>"

Где m1 — селектор, он выбирается произвольно и должен быть уникальным для каждого почтового сервера, также селектор указывается в конфигурации почтового сервера при настройке подписи DKIM. Он нужен для того, чтобы получатель мог получить открытый ключ именно того сервера, который отправил данное письмо.

Механизм предельно прост, при подписи письма сервер отправитель добавляет в заголовки селектор, сервер получатель извлекает селектор и ищет в DNS запись DKIM для этого селектора, после чего извлекает оттуда открытый ключ и проверяет подлинность подписи.

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

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC — это техническая спецификация, обеспечивающая единые механизмы проверки почты по SPF и DKIM, а также формирование и отправку отчетов. На первый взгляд выглядит сложно и непонятно, но на самом деле позволяет отправителю не только дать прямые указания что делать с почтой, но и получать обратную связь от получателей, что очень важно если вы только тестируете отправку почты.

В простейшем случае DMARC запись выглядит так:

_dmarc TXT "v=DMARC1; p=none; rua=mailto:report@example.com"

Запись состоит из тегов:

• v — версия DMARC, обязательный тег, в настоящее время единственное значение v=DMARC1
• p — правило для домена, указывает какое действие следует предпринять если письмо не прошло проверку, может иметь значения: none — ничего не делать, quarantine — поместить письмо в карантин, reject — отклонить письмо.
• sp — правило для субдоменов, принимает такие же значения, как и p.
• aspf и adkim — позволяют указать строгость проверки, по умолчанию используется мягкая проверка, при которой результат будет провален только при провале и SPF и DKIM, с помощью данных опций и значения s (strict) мы можем ужесточить проверку, и она будет провалена при провале только одной из указанных опций.
• pct — процент писем, подлежащих фильтрации DMARC, удобно для постепенного внедрения проверки, например, мы можем для начала указать 10% и потом по отчетам анализировать правильность настройки почтовой для отправляемых нами писем.
• rua и ruf — адреса для направления ежедневных отчетов о применении политик DMARC, при этом ruf используется для отчета только о письмах, не прошедших проверку.
• fo — определяет о каких не пройденных проверках сообщать владельцу домена, по умолчанию значение 0 — сообщать только если не пройдены проверки SPF и DKIM, 1 — если не пройдена хотя бы одна проверка, s или d — если не пройдена SPF или DKIM.

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

Более сложная политика может выглядеть так:

_dmarc TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:report@example.com; ruf=mailto:admin@example.com; fo=1; pct=25"

Данная запись предписывает не прошедшие проверку письма основного домена отправлять в карантин, поддоменов — отклонять, сообщать если не пройдена даже одна из проверок и фильтровать 25% входящей почты. Отчеты присылать на указанные адреса, в нашем случае они разные. Общий отчет направляется в один почтовый ящик, отчет о не прошедших проверку письмах в другой.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.