Записки IT специалиста
Настраиваем свой почтовый сервер. Что нужно знать. Ликбез
- Автор: Уваров А.С.
- 08.12.2022
Последнее время мы уделяли мало внимания почтовым системам, но вновь возросший интерес заставил нас вернуться к этой теме. Основные затруднения начинающих при работе с почтой состоят в том, что почта — это сложная система, состоящая из нескольких компонентов, взаимодействующих как между собой, так и с внешними системами. Кроме того, почта крайне чувствительная к правильной настройке 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, он анализирует поле адреса назначения в заголовках письма, допустим мы видим там:
Если домен получателя отличается от обслуживаемого MTA домена, то он должен каким-то образом узнать, кому именно отправлять почту. Для этого он использует систему DNS, запросив специальную запись — MX. MX — Mail Exchanger — особая DNS-запись, указывающая на адрес почтового шлюза домена, таких записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.
MX-запись никак не связана с отправкой почты, но именно она указывает на узел, который уполномочен принимать почту в данном домене. Данная запись должна содержать именно имя узла, а не IP-адрес, после чего сервер-отправитель сделает еще один запрос, чтобы по имени хоста получить его IP-адрес. Данные записи прописываются администратором домена и в базовом варианте будут выглядеть так:
Первая запись — это MX-запись для домена, которая говорит кому отправлять почту. Вторая запись сопоставляет имя srv-mx-01.example.com и действительный IP-адрес узла.
Часто администраторы предпочитают использовать псевдонимы — CNAME — для указания на отдельные почтовые узлы. Это удобно, но в любом случае MX-запись должна содержать реальное имя узла, а не псевдоним, поэтому правильно будет так:
Принимать почту в домене могут несколько серверов, или один, но на разных каналах. Допустим у нас есть основной канал и есть резервный, тогда набор записей будет выглядеть так:
Если сервер-отправитель не сможет отравить почту первому MX-серверу в списке, то он переключится на второй. Обратите внимание на разный приоритет серверов: 10 и 20, таким образом пока доступен сервер с приоритетом 10 почта никогда не будет направляться серверу с приоритетом 20.
А если мы укажем несколько серверов с одинаковым приоритетом? Почта будет направляться на все из них по принципу Round-robin, т.е., чередуясь по кругу, такое решение можно использовать для балансировки нагрузки.
C MX-записями разобрались, переходим к PTR. PTR — Pointer — соответствие адреса имени, позволяет на основании IP-адреса получить имя хоста этого узла. Какое это имеет отношение к отправке и получению почты? Да никакого, наличие или отсутствие PTR-записи никак не влияет на процесс отправки или получения почты. Но зачем же тогда она нужна?
Основное ее назначение — это защита от спама. Уже давно существует соглашение, что добросовестный отправитель почты имеет PTR-запись. Это позволяет сразу отсечь огромный пласт взломанных и инфицированных систем, потому как прописать PTR-запись может только владелец IP-адреса, т.е. хостер или провайдер. Поэтому даже получив полный доступ к инфраструктуре, включая DNS-сервер, злоумышленник все равно не сможет добавить или изменить PTR-запись.
Для кого следует прописывать обратную запись? Для имени узла, фактически отправляющего почту, вне зависимости от того, какие домены он обслуживает. Так один почтовый сервер может обслуживать множество доменов, но PTR-запись мы должны прописать для фактического имени хоста. В классическом виде PTR-запись будет выглядеть так:
Обращаем внимание на то, что в PTR всегда указывается полное доменное имя FQDN и обязательно с точкой на конце. Но это знание более академическое, так как обратной зоной будет управлять ваш провайдер и прямого доступа туда у вас не будет.
Еще один интересный момент, это обратные записи для нескольких каналов одного сервера, ошибкой будет прописать:
Почему? Да потому что сервера srv-mx-02 у нас физически не существует, мы придумали его как второе имя для основного сервера srv-mx-01 и в заголовках писем в качестве отправителя будет присутствовать именно это имя. Кроме того, как мы уже говорили, MX-сервера не имеют никакого отношения к процессу отправки почты.
Поэтому правильно будет сделать PTR-записи так:
И еще раз предупредим, все записи выше даны сугубо в академических целях, в реальности вам нужно будет только сообщить провайдеру (или провайдерам) для какого узла им нужно сделать PTR-запись.
SPF — Sender Policy Framework
SPF — это специальный тип DNS-записи в формате TXT, позволяющий владельцу домена указать те узлы, которые имеют право отправлять почту от имени домена. Эта запись не является обязательной, но ее наличие резко снижает вероятность попадания вашей корреспонденции в спам.
Чаще всего содержимое SPF сводится к стандартному:
Запись состоит из списка тегов и значений, теги в 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-записи указанного домена.
Для уточнения действий к механизмам применяются квалификаторы (префиксы):
- + — Аутентификация пройдена. Узлу разрешена отправка почты от имени домена.
- — — Аутентификация не пройдена. Узлу запрещена отправка почты от имени домена.
Таким образом стандартная запись читается как: разрешено отправлять почту узлам перечисленным в A и MX записях домена, остальным, скорее всего запрещено. При аутентификации с неполным отказом письма от прочих узлов обычно не отвергаются получателем, а помечаются как подозрительные. Квалификатор «+» подразумевается по умолчанию и его можно не указывать. Если нам нужно указать несколько узлов, то используем несколько механизмов. Например:
Здесь мы указали, что отправлять почту можно с узлов указанных в A и MX записях текущего домена, а также с узла mail.example.org.
Если у вас есть домены с которых никогда не должна отправляться почта, то не будет лишним указать для них следующую SPF-запись:
Теперь немного об include и redirect, может показаться, что они делают одно и тоже, но есть тонкости. Механизм redirect просто перенаправляет вас к записям указанного в нем домена. Это удобно, если сервер обслуживает сразу несколько доменов, это позволяет иметь одну единственную запись, которую будут использовать все остальные. Также это применяется при использовании своего домена совместно c публичными почтовыми системами:
Такая запись указывает использовать для домена записи, указанные у публичной службы.
Если же вместе с публичными сервисами вы используете собственные сервера, то вам нужно использовать механизм include, который подгрузит записи указанного домена к вашим собственным.
Данная запись говорит о том, что отправлять почту имеет право узел с адресом 203.0.113.25, а также все остальные, которые перечислены в записях указанного домена.
DKIM — DomainKeys Identified Mail
Если говорить коротко, то DKIM — это технология электронно-цифровой подписи, которая позволят получателю убедиться, что письмо действительно принадлежит отправителю. Для этого на каждом почтовом сервере, которые отправляют почту в нашем домене мы генерируем ключевую пару RSA. Закрытый ключ мы добавляем в конфигурацию почтового сервера и теперь он будет подписывать все исходящие письма.
Если сервер обслуживает несколько доменов, то ключевые пары нужно создать для каждого домена.
Для того, чтобы проверить подлинность подписи мы публикуем открытый ключ и используем для этого систему DNS, сформировав специальную запись типа TXT:
Где m1 — селектор, он выбирается произвольно и должен быть уникальным для каждого почтового сервера, также селектор указывается в конфигурации почтового сервера при настройке подписи DKIM. Он нужен для того, чтобы получатель мог получить открытый ключ именно того сервера, который отправил данное письмо.
Механизм предельно прост, при подписи письма сервер отправитель добавляет в заголовки селектор, сервер получатель извлекает селектор и ищет в DNS запись DKIM для этого селектора, после чего извлекает оттуда открытый ключ и проверяет подлинность подписи.
Технология DKIM не является обязательной к применению, но значительно повышает вероятность доставки ваших писем получателям.
DMARC — Domain-based Message Authentication, Reporting and Conformance
DMARC — это техническая спецификация, обеспечивающая единые механизмы проверки почты по SPF и DKIM, а также формирование и отправку отчетов. На первый взгляд выглядит сложно и непонятно, но на самом деле позволяет отправителю не только дать прямые указания что делать с почтой, но и получать обратную связь от получателей, что очень важно если вы только тестируете отправку почты.
В простейшем случае DMARC запись выглядит так:
Запись состоит из тегов:
- 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.
В самом простом варианте мы говорим получателям ничего не делать с не прошедшими проверку письмами и слать нам отчеты на указанный адрес.
Более сложная политика может выглядеть так:
Данная запись предписывает не прошедшие проверку письма основного домена отправлять в карантин, поддоменов — отклонять, сообщать если не пройдена даже одна из проверок и фильтровать 25% входящей почты. Отчеты присылать на указанные адреса, в нашем случае они разные. Общий отчет направляется в один почтовый ящик, отчет о не прошедших проверку письмах в другой.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
Email моей мечты, или Как настроить корпоративную почту
На сегодняшний день электронная почта — наиболее востребованное средство корпоративного и делового общения в современном интернете, поэтому крайне важно обеспечить её бесперебойное функционирование.
Существует два основных способа организации корпоративной почты — это организация с использованием собственного сервера для принятия/отправки и с использованием стороннего сервиса. Оба эти способа имеют свои преимущества и недостатки, но, так как основной критерий для нас — это надёжность, мы будем рассматривать вариант использования стороннего сервиса.
Если у вас интернет-магазин или SaaS-сервис, email — must have канал вашей рекламной стратегии.
Решение для организации корпоративной почты предоставляется двумя крупными поисковыми системами — «Почта для домена» от Яндекса и Google Apps for Business от Google. Смысл работы обоих сервисов одинаков: регистрация главного аккаунта, настройка MX-записей, создание и управление корпоративными ящиками через специальный интерфейс. Обе платформы надёжны, но мы в своей работе используем сервис компании Яндекс, поскольку он полностью бесплатный, поддерживает до 1000 почтовых ящиков (с возможностью расширения при необходимости), приятный интерфейс и простой API.
К сожалению, корпоративная почта от Google бесплатна только при наличии до 10 аккаунтов или если это образовательное учреждение.
Рассмотрим процесс регистрации и привязки домена к сервису от Яндекса
Переходим по ссылке выше и авторизуемся, либо регистрируемся на Яндексе. Советую завести для целей администрирования корпоративной почты отдельный логин и сгенерировать для него сложный пароль (записав его на листочке и приклеив к монитору, разумеется :)). Добавляем домен и видим следующее окно:
Шаг 1: Помимо почтового сервиса Яндекс предоставляет бесплатную услугу хостинга DNS. Если у вас имеются достаточные знания, советую делегировать домен на Яндекс и использовать его серверы DNS в качестве вторичных.
Шаг 2: Подтвердите владение своим доменом. Процедура стандартная и не требует специальных навыков. Создаём запрашиваемый Яндексом файл и закачиваем его на сервер.
Шаг 3: Для определения маршрутов прохождения электронной почты в системе DNS используются MX (от Mail eXchanger) записи. Они указывают на сервер, авторитетный для отправки и принятия почты на данном домене. Для настройки этой записи нужно иметь доступ к панели управления DNS. DNS, как правило, предоставляются регистратором, либо обслуживающим хостером. Если в вопросе изменения MX-записей есть какие-то неясности, наиболее правильным решением будет обращение к своему хостинг-провайдеру.
Обращу внимание, что в отличии от сервисов Google, где требуется указать 5 MX-записей, здесь указывается только одна, но не стоит думать, что один хост mx.yandex.ru. соответствует одному физическому серверу. 😉 После того, как владение доменом подтверждено и MX-записи настроены, осталось создать нужные ящики и разослать сотрудникам логины и пароли к ним. Интерфейс создания ящика предельно прост:
Отдельно хочется поговорить о «хинтах» сервиса
1. Рассылки. Очень полезная возможность для средних и крупных компаний. Рассылка — это специальный почтовый адрес, который при получении письма, пересылает его всем адресатам, указанным в рассылке. Как это организовать? Используя интерфейс Яндекса, создаём рассылку с определенным именем и добавляем в неё нужных адресатов. Как можно использовать? Рассылки по всем сотрудникам одним письмом, рассылки по отделам, рассылки по филиалам и офисам, рассылки по интересам.
2. Отправка почты по SMTP и сбор почты по POP3. Многие предпочитают использовать почтовые клиенты для отправки и получения почты. Яндекс даёт возможность пользоваться корпоративной почтой через клиенты. Для включения сбора почты по POP3 следует самостоятельно, через интерфейс конкретного аккаунта, зайти в почту и отредактировать данную настройку:
3. Привязка почты к Gmail-аккаунту. Если интерфейс Яндекса чем-то не устраивает, можно привязать свою корпоративную почту к gmail-аккаунту как на отправку, так и на приём. Для этого потребуется в настройках своего gmail-аккаунта: на вкладке «аккаунты и импорт» нужно настроить отправку и сбор с других ящиков. Для настройки отправки писем нужно использовать следующие параметры: логин и пароль (логин и пароль от почты на Яндексе), использовать сторонний сервер для отправки, сервер smtp.yandex.ru, порт 465, ssl включён. Для сбора: логин и пароль — логин и пароль от почты на Яндексе, сервер pop.yandex.ru, порт 995, ssl включён. На выходе имеем «мощный» интерфейс Gmail и надёжность Яндекса.
Кстати, а вы подписаны на рассылку блога? Подпишитесь:
Ну, вот и все. Теперь можно осваивать эффективные email-рассылки и системы автоматизации маркетинга, которые предоставляют различные платформы (SendPulse, например).
Co-founder и Chief Executive Officer в агентстве интернет-маркетинга Netpeak.
Более 15 лет в IT-cфере. Начинал свой путь от PHP-разработчика, последние 4 года руководит агентским бизнесом.
Специализация Netpeak – услуги Performance-маркетинга. На сегодня более 400+ клиентов доверяют Netpeak 35M+ USD оборотов в Google. 350 сотрудников работают в трёх странах и восьми городах. Компания из года в год растёт на 30+% в обороте и прибыли.
На позиции CEO Дмитрий отвечает за общий финансовый результат, рост бизнеса и выполнение стратегических целей. Руководит многими процессами, отвечает за запуск новых проектов и направлений, курирует M&A. Дмитрий активно занимается развитием IT-отрасли, регулярно выступая на конференциях и в ведущих ВУЗах страны.
Как бесплатно настроить собственный почтовый сервер
Если есть необходимость бесплатно создать свой собственный почтовый сервер для вашей компании или личного пользования (это особенно актуально для малого бизнеса), эта информация будет интересна. В результате почту можно будет отправлять по всему миру через бесплатный почтовый сервер для вашего домена.
Зачем вообще делать собственный почтовый сервер?
Преимущества#
Отправка почты компании с ее домена – хорошая идея увеличить привлекательность и солидность бизнеса. Например, sales@mycompany.com.
Мы можем создать столько пользователей, сколько захотим, без дополнительной оплаты.
Нет ограничений на целевые адреса при отправке почты. Используя же внешние сервисы, мы в так или иначе должны платить за каждого пользователя.
Никто из вне не сможет увидеть наши внутренние деловые разговоры.
Некоторые общедоступные почтовые серверы не могут отправлять почту на некоторые домены, например protonmail.com из-за ограничений страны. Использование собственного почтового сервера дает нам возможность обходить такие ограничения.
Недостатки#
Да, это такая же головная боль, как и создание нашего собственного веб-сервера, например, поддержка его онлайн, администрирование и т. д.
Для правильной настройки требуются специальные знания. Но, если вы готовы к этому, мы расскажем об этом в этой статье.
Некоторые диапазоны статических адресов могут быть занесены в черные списки. Но есть решение, как этого избежать.
Есть три основных шага, чтобы установить и настроить собственный почтовый сервер.
Настройка IP и DNS#
Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR#
Это основные требования для запуска собственного почтового сервера.
IP-адрес нашего собственного почтового сервера должен быть общедоступным и одинаковым во времени. Убедитесь в этом у вашего хостинг или интернет-провайдера.
DNS-запись публичного доменного имени нашего собственного почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS вашего провайдера доменного имени.
Кроме того, обратная DNS-запись (именуемая PTR) должна наш IP-адрес указывать на доменное имя нашего собственного почтового сервера. Вы можете попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его для вашего общедоступного доменного имени. Его можно легко проверить по вашему IP-адресу с помощью специальной онлайн-проверки, подобной этой, или с помощью командной утилиты Windows ‘nslookup’ и команды ‘host’ в системах на основе UNIX.
Настройка MX записи в DNS#
Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.
Таким образом, мы должны указать доменное имя нашего собственного почтового сервера, который будет обрабатывать почту нашего основного домена. Например, если наш домен – mycompany.com, почтовый сервер – mail.mycompany.com, то запись DNS для mycompany.com будет:
Type
Host
Value
Priority
TTL
- Priority (приоритет) используется, когда в нашем домене более одного почтового сервера.
- TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при настройке нашего собственного почтового сервера.
Настройка DKIM записи в DNS#
Почта, идентифицированная ключами домена (DKIM) — это протокол безопасности электронной почты, который прикрепляет зашифрованную цифровую подпись к электронному письму. Принимающий сервер проверяет его с помощью открытого ключа, чтобы убедиться, что электронное письмо не было подделано.
Итак, нам нужны приватный и открытый ключи. Их можно создать с помощью онлайн-инструментов, например Power DMARC Toolbox – DKIM Record Generator, или с помощью команд OpenSSL (показано для Windows):
openssl.exe genrsa -out private.key 2048
openssl.exe rsa -in private.key -pubout -outform der 2>nul | openssl.exe base64 -A > public.key.txt
И наша запись DNS будет выглядеть так:
Type
Host
Value
TTL
selector._domainkey
- selector – самостоятельно выбранный идентификатор (например, mysrv), который будет использоваться в нашем приложении почтового сервера.
- public_key – наш открытый ключ, закодированный алгоритмом base64.
- TTL (время жизни) имеет то же значение, что и в предыдущем абзаце.
Настройка SPF записи в DNS#
Инфраструктура политики отправителя (SPF) — это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.
Наша запись DNS будет выглядеть так:
Type
Host
Value
TTL
- relayer_name – имя необязательного внешнего почтового сервера-ретранслятора.
- TTL (время жизни) имеет то же значение, что и в предыдущем абзаце.
Можно использовать удобный онлайн-генератор записи SPF.
Дополнительные записи DNS#
Некоторые поля не обязательны, но желательно иметь.
Запись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу нашего хоста декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.
Индикаторы бренда для идентификации сообщений (BIMI) — это новый стандарт, созданный для того, чтобы упростить отображение нашего логотипа рядом с нашим сообщением во входящих сообщениях. Кроме того, BIMI предназначен для предотвращения мошеннических электронных писем и улучшения доставки.
TLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.
Строгая транспортная безопасность агента пересылки почты (MTA-STS) – это новый стандарт, направленный на повышение безопасности SMTP, позволяя доменным именам выбирать строгий режим безопасности транспортного уровня, требующий аутентификации и шифрования.
Все эти записи кроме MTA-STS могут быть созданы с помощью Power DMARC Toolbox. Конфигурация MTA-STS похожа на Google и, наконец, может быть проверена с помощью Hardenize.
Выбор и запуск приложения почтового сервера#
Убедитесь, что ваш хостинг позволяет устанавливать программное обеспечение. В таком случае можно использовать любое подходящее приложение для почтового сервера. Например, есть бесплатный hMailServer для Windows, который предоставляет все необходимые функции с минимальным использованием ресурсов. Для систем на базе UNIX существует множество бесплатных почтовых серверов, таких как Exim Internet Mailer или iRedMail.
Если вы знаете ещё хорошие программы, то можете поделиться ими в комментариях ниже. Вообще, подробный выбор такого программного обеспечения заслуживает отдельной статьи.
Для Windows мы рекомендуем использовать hMailServer из-за его соответствия нашим принципам компактного и эффективного программного обеспечения.
Инициализация#
Когда программное обеспечение выбрано и установлено, самое время его настроить.
Мы должны добавить пользователей нашего бесплатного почтового сервера для домена. Их можно добавить или удалить в любой момент.
Чтобы обеспечить соответствующий уровень безопасности, мы должны добавить сертификат SSL для нашего домена. Конфигурацию SSL можно проверить здесь.
Далее следует настроить DKIM. Нам нужно добавить полученные выше приватный ключ и селектор. Кроме того, методы заголовка и тела должны быть установлены на «расслабленный», алгоритм подписи должен быть установлен на «SHA256» для совместимости с современной проверкой передачи почты.
Наконец, не забудьте настроить проверку антиспама специальными узлами черных списков, такими как spamhaus.org, чтобы защитить пользователей нашего почтового сервера от сообщений спама.
Протоколы электронной почты#
Мы должны настроить три протокола электронной почты, которые необходимы для её отправки и получения.
SMTP используется для приема входящей и исходящей почты с/на другие почтовые серверы. И это позволяет пользователям нашего домена отправлять свои сообщения.
Этот порт необходим для управления входящими подключениями от других почтовых серверов. Метод безопасности следует установить в STARTTLS.
Он нужен для почтовых клиентов собственного почтового сервера. Метод безопасности следует установить в STARTTLS.
Это может потребоваться для старых почтовых клиентов нашего собственного почтового сервера. И метод безопасности следует установить в SSL/TLS.
POP3, IMAP#
POP3 и IMAP используются отдельными почтовыми клиентами, такими как Outlook на ПК или любой почтовый клиент на наших мобильных телефонах. Это позволяет пользователям нашего домена управлять своими сообщениями.
Порт 993 следует использовать для защищенных соединений IMAP, а порт 995 – для POP3. Для обеспечения совместимости с большинством клиентов метод безопасности следует установить в SSL/TLS (не STARTTLS).
Также можно настроить порты 143 для IMAP и 110 для POP3, но их не рекомендуется использовать из-за их небезопасности.
Проверка#
Итак, когда все настроено, мы можем протестировать наш собственный почтовый сервер, отправив письмо кому-нибудь из списка наших пользователей. Кроме того, в некоторых почтовых приложениях есть функция самодиагностики, например hMailServer, которая показывает готовность к работе всех подсистем (см. ниже).
Теперь пора проверить отправку на внешний адрес.
Аккаунт Gmail.com#
Если у нас есть учетная запись Gmail.com, мы также можем отправить тестовое письмо на наш адрес Gmail. Затем откроем нашу электронную почту в браузере и нажмём «Показать подробности».
Если есть «подписано: наш домен», наша подпись DKIM настроена правильно. Если есть «отправлено по почте: наш домен», наш SPF в порядке.
Затем убедимся, что статус проверки нашей отправки пройден в оригинальных заголовках.
Также в Outlook мы можем видеть те же заголовки в свойствах сообщения.
Специальные онлайн-сервисы#
Существует множество онлайн-сервисов, которые могут проверять отправку электронной почты. Ниже приведены некоторые из них.
Этот сервис позволяет тестировать конфигурацию почтового сервера, такую как DKIM и SPF, отправляя электронное письмо на указанный сгенерированный почтовый адрес. Нам нужно просто следовать инструкциям на экране и результаты теста будут отображены там же.
Предоставляет те же функции, что и предыдущая служба. Результаты тестирования будут отправлены на адрес отправителя.
Чтобы проверить отправку сообщения здесь, нам нужно отправить специальное сообщение на tester@email-test.had.dnsops.gov. Результаты тестирования будут отправлены на адрес отправителя.
Этот сервис предоставляет только облегченную проверку всех атрибутов, но у него есть удобные инструменты, перечисленные выше.
Итак, если всё настроено правильно, но наш сервер присутствует в чёрных списках спама, мы должны внести в белый список наш собственный почтовый сервер. Смотри ниже.
Занесение своего почтового сервера в белые списки#
Таким образом, если всё вышеперечисленное настроено правильно, другие почтовые серверы по-прежнему могут отмечать сообщения как спам и отклонять их. Это бывает, когда IP (или его диапазон) нашего домена попадает в какой-то черный список. Чаще всего причиной этого является использование соседних IP-адресов для рассылки спам-сообщений.
Внесение в белый список в публичных источниках#
Итак, сначала давайте проверим IP (и, если необходимо, домен) онлайн на наличие в каких-либо черных списках. Его можно проверить в любом онлайн-чекере, который можно найти через поиск. Например, MXToolBox проверяет самые популярные черные списки. И мы рекомендуем проверить его на multirbl.valli.org, потому что он показывает много источников черного списка и показывает доверие к каждому из них.
Затем мы должны последовательно просмотреть каждый элемент в результатах и прочитать рекомендации о том, как внести наш IP-адрес в белый список в конкретном источнике черного списка. Но не все из них могут позволить это сделать бесплатно, например, UCEPROTECT ® -Network.
Внесение в белый список определенных почтовых серверов#
Некоторые серверы, такие как Outlook, имеют свои собственные черные списки. Проверка проста – ваше приложение почтового сервера уведомит вас о неудачной доставке в почтовом клиенте. Большинство почтовых серверов предоставляют в ответе URL-адреса разблокировки. Таким образом, мы должны открыть такой URL и следовать инструкциям, например, как этот.
Обход черных списков#
Если какой-то официальный черный список не разрешает добавление в исключения или когда-нибудь почта перестает отправляться на определенный домен – не паникуем – мы можем использовать внешние службы ретрансляции SMTP. Они позволяют использовать их в качестве шлюзов или прокси при отправке почты.
Мы рекомендуем использовать его как самый дешевый – он позволяет бесплатно отправлять 20 тысяч писем в месяц и имеет низкую стоимость дополнительной отправки. Особенность: поля CC и BCC пока не поддерживаются.
Это еще один хороший сервис, который позволяет бесплатно отправлять 9 тысяч писем в месяц с лимитом 200 в день. Особенность: встроенное отслеживание электронной почты нельзя отключить.
В каждой службе мы должны зарегистрировать и получить подтверждение домена нашего почтового сервера. После подтверждения, каждый из них дает указания на то, что должно быть настроено для нашего DNS и нашего приложения собственного почтового сервера. Для DNS это настройки DKIM, SPF и DMARK, для приложения – это адрес сервера ретрансляции SMTP, порт и учетные данные.
Заключение#
Итак, теперь мы можем использовать все преимущества запуска собственного почтового сервера. Надеемся, что этот материал поможет вам наиболее эффективно достичь поставленной цели. Если у вас есть какие-либо вопросы или предложения по этой теме, добро пожаловать в обсуждение в наших комментариях или по электронной почте.
Установка и настройка SMTP сервера на Windows Server 2016 / 2012 R2
02.02.2021
itpro
Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
комментариев 18
Вы можете установить SMTP сервер с помощью встроенных средств во всех версиях Windows Server. Такой SMTP сервер внутри организации может работать в качестве почтового релея, который должен принимать и пересылать через себя SMTP сообщения от различных устройств (к примеру, сендеров, сканеров, устройств СКД и пр.) и приложений (веб приложения, SQL Reporting Services, SharePoint), которым необходимо иметь возможность отправлять почту через SMTP сервер. Такой релей может пересылать сообщения на полноценные Exchange сервер или на публичные почтовые сервисы в Интернет типа Gmail, Mail.ru, Office 365 и т.д (ведь не всегда целесообразно разворачивать полноценную внутреннюю почтовую инфраструктуру на базе Microsoft Exchange Server или других почтовых служб).
В этой статье мы покажем, как установить, настроить и протестировать работу SMTP сервера на Windows Server 2012 R2, 2016 и 2019, который будет функционировать в качестве mail релея. Такой SMTP сервер не хранит почтовые сообщения и на нем отсутствуют почтовые ящики, он сможет только отправлять или пересылать почту.
Установка службы SMTP на Windows Server 2016/2012 R2
SMTP сервер – это один из компонентов Windows Server, который можно установить через Server Manager. Для этого откройте консоль Server Manager Dashboard (servermanager.exe), перейдите в режим Add roles and features и на этапе выбора функций отметьте чекбокс у пункта SMTP Server. Для управления службой SMTP нужно установить консоли управления, которые входят в комплект роли Web Server IIS (вам будет предложено установить IIS Management Tools).
Оставьте все предлагаемые опции роли Web Server (IIS) и запустите установку.
Также вы можете установить компонент SMTP сервера с помощью одной команды PowerShell:
После окончания установки компонентов может потребоваться перезагрузка системы.
Настройка SMTP сервера на Windows Server
Управляется SMTP сервер консоль управления Internet Information Services (IIS) Manager 6. Открыть эту консоль можно через Server Manager: Tools-> Internet Information Services (IIS) 6.0 Manager или командой inetmgr6.exe.
В консоли IIS 6 Manager разверните ветку с именем сервера, щёлкните ПКМ по SMTP Virtual Server и откройте его свойства.
На вкладке General, если необходимо, выберите IP адрес, на котором должен отвечать SMTP сервер (если у сервера несколько IP адресов), и включите ведение логов Enable logging (чтобы сохранялась информация обо всех полученных письмах).
Затем перейдите на вкладку Access.
Здесь нажмите на кнопку Authentication и убедитесь, что разрешен анонимный доступ (Anonymous access).
Вернитесь на вкладку Access и нажмите кнопку Connection. Здесь вы можете указать IP адреса устройств, которым разрешено отправлять почту через наш SMTP релей. Нужно выбрать опцию Only the list below и указать список IP адресов, не забыв самого себя (127.0.0.1).
Аналогичным образом настройте список разрешенных IP в настройках Relay (нажмите соответствующую кнопку). В этой секции указано каким IP адресам (или подсетям) можно пересылать почту через ваш SMTP сервер.
Перейдите на вкладку Messages. Здесь указывается email, на который будут отправляться копии всех NDR отчетов (Send copy of Non-Delivery Report to:). Также здесь можно указать ограничения на максимальный размер писем (Limit message size KB) и количество получателей (Limit number of recepients per message).
Перейдите на вкладку Delivery:
Затем нажмите на кнопку Outbound Security. Здесь указывается, как нужно авторизоваться на почтовом сервере, на который ваш SMTP-сервере будет пересылать (relay) всю почту. К примеру, если вся почта будет отправляться на почтовый сервер Gmail и уже с него пересылаться адресатам, вам нужно выбрать тип аутентификации Basic authentication, указав в качестве пользователя и пароля данные для доступа к почтовому ящику на сервисе Gmail (в настройках аккаунта Google нужно разрешить отправку через smtp сервера gmail).
Затем нажмите на кнопку Advanced.
Здесь указывается FQDN имя вашего SMTP сервера. Нажмите кнопку Check DNS, чтобы проверить корректность записи в DNS.
Если сервер должен пересылать почту внешнему smtp серверу, нужно указать его имя в поле Smart host (к примеру smtp.gmail.com или smtp.office365.com).
Сохраните настройки SMTP сервера и перезапустите ваш виртуальный SMTP сервер для применения изменений.
- Настройки DNS критичны с точки зрения работоспособности почтовой системы. Если ваш SMTP сервер не может корректно разрешить DNS имена доменов, на которые он пытается отправить письма, доставка не удастся.
- Если ваш сервер сам будет отправлять почту в другие домены, важно, чтобы для вашего адреса была сформирована правильная PTR запись для разрешения обратных DNS запросов. PTR запись для белого IP адреса должна указывать на FQDN имя. В противном случае большинство внешних smtp серверов не будут принимать от вас почту, считая ваш сервер спамерским.
Автозапуск службы SMTPSVC
Осталось настроить автозапуск службы SMTP сервера. Быстрее всего это сделать из командной строки PowerShell:
set-service smtpsvc -StartupType Automatic
Проверим, что запущена служба SMTPSVC :
Проверка работы SMTP сервера на Windows Server
Ну и последнее, что осталось сделать, проверить работу созданного SMTP сервера. Проще всего это сделать, создав на рабочем столе текстовый файл smtp-test-email.txt и скопировав в него следующий текст, заменив имя отправителя и получателя на ваши.
Скопируйте файл smtp-test-email.txt в каталог C:\inetpub\mailroot\Pickup. SMTP сервер следит за появлением файлов в этой каталоге и при обнаружении файла прочтет его содержимое и попытается отправить письмо с данной темой и текстом адресату, указанному в разделе To:.
Проверьте ящик получателя, в него должно прийти такое письмо.
Send-MailMessage -SMTPServer localhost -To [email protected] -From [email protected] -Subject «Email test» -Body «This is the test email sent via PowerShell»
Если вы хотите, чтобы вы включили Basic Authentication (Обычная проверка подлинности) для авторизации всех ваших SMTP клиентов (вместо анонимной аутентификации), вы можете отправить письмо с smtp-аутентификацией через telnet следующим образом.
Также убедитесь, что на вашем SMTP сервере не блокируется порт TCP 25 при удаленном подключении (локальным файерволом, антивирусом или межсетевым экраном). Проще всего это сделать с компьютера Windows, IP адрес которого добавлен в разрешенные. Проверку доступности порта можно выполнить с помощью командлета Test-NetConnection:
Test-NetConnection smtpsrv1.name.local –port 25
Если 25 порт блокируется, проверьте настройки Windows Firewall, антивируса и аппаратных межсетевых экранов.
Итак, вы настроили собственный почтовый SMTP релей на Windows Server 2016/2012 R2 и протестировали отправку писем через него.
Предыдущая статья Следующая статья