Меню Рубрики

Установка почтового сервера для чайников

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Почтовый сервер для начинающих. Настраиваем DNS зону

Для правильной работы почтового сервера важно иметь правильно настроенную DNS зону. В прошлой статье мы уже касались некоторых аспектов, связанных с системой DNS, сегодня мы остановимся на этом вопросе более подробно. Настройка DNS зоны относится к подготовительным операциям перед развертыванием почтового сервера и от нее непосредственно зависит работоспособность системы электронной почты.

Неправильные настройки способны привести к тому, что почту будет невозможно доставить вашему почтовому серверу или сервера получателей будут отклонять вашу почту. Действительно, если записи вашей зоны не содержат сведений о почтовом сервере, куда должна отправляться почта? На деревню дедушке? Можно, конечно, попросить настроить DNS зону вашего провайдера, но лучше сделать это самим.

Что нам понадобиться? Выделенный IP адрес (допустим 11.22.33.44), который вы должны получить у своего провайдера. Доменное имя (например example.com), его можно зарегистрировать у любого регистратора или их партнера. При регистрации у партнера уточняйте, предоставляет ли он доступ к управлению DNS зоной, иначе придется потратить дополнительное время, нервы и деньги на перенос домена к регистратору.

Если у вас уже есть домен и, скорее всего, на нем функционирует сайт, уточните, возможно ли управление DNS зоной из панели хостинг провайдера, в противном случае лучше перенести домен к регистратору, для этого обратитесь в поддержку провайдера.

Итак, домен у нас есть. Какие записи содержит его DNS зона? Во первых это SOA запись — описание зоны. Мы не будем подробно разбирать все записи, это выходит за рамки нашей статьи, но иметь общее представление о них необходимо. Также должны быть две NS записи, указывающие на сервера имен (DNS сервера) обслуживающие данный домен, это будут сервера регистратора или хостинг провайдера.

Первой записью, которую необходимо добавить будет A запись или запись имени. Она должна указывать на IP-адрес вашего сервера, если вы решите обслуживать все запросы к домену у себя или на IP адрес хостинг провайдера, если решите разместить свой сайт на хостинге. При размещении сайта у хостера домен обычно делегируется на его DNS сервера (прописываются соответствующие NS записи) и A запись будет сделана автоматически при парковке домена.

Чаще всего встречается этот вариант, но при необходимости вы всегда сможете создать A запись сами. Данная запись имеет вид

В нашем примере 22.11.33.44 адрес нашего хостинг провайдера, у которого расположен сайт. Обратите внимание на точку в конце имени, это указывает что имя абсолютное, при отсутствии точки имя считается относительным и к нему добавляется доменное имя из SOA. Проверить запись можно командой nslookup.

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

Также можно написать просто:

К такому имени (без точки на конце) example.com будет добавлено автоматически. Цифра 10 определяет приоритет сервера, чем она меньше, тем выше приоритет. Кстати, DNS зона уже может содержать MX запись вида:

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

Теперь создадим A запись для mail.example.com

Теперь вся почта для домена example.com будет направляться хосту mail имеющему адрес 11.22.33.44, т.е. вашему почтовому серверу, в то-же время сайт example.com продолжит работать на сервере провайдера по адресу 22.11.33.44.
Может возникнуть вопрос, а почему нельзя сразу указать в MX записи IP адрес почтового сервера? В принципе можно, некоторые так и делают, но это не соответствует спецификациям DNS.

Также можно сделать алиасы для почтового сервера типа pop.example.ru и smtp.example.ru. Зачем это надо? Это позволит клиенту не зависеть от особенностей вашей инфраструктуры, один раз прописав настройки. Допустим, что ваша компания разрослась и выделила для обслуживания внешних клиентов отдельный почтовый сервер mail1, все что вам понадобиться, это изменить две DNS записи, клиенты и не заметят того, что работают с новым сервером. Для создания алиасов используются записи типа CNAME:

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

Немного странный вид, не правда ли? Разберем структуру PTR записи более подробно. Для обратного преобразования имен используется специальный домен верхнего уровня in-addr.arpa. Это сделано для того, чтобы использовать для прямого и обратного преобразования имен одни и те же программные механизмы. Дело в том, что мнемонические имена пишутся слева направо, а IP адреса справа налево. Так mail.example.com. означает что хост mail находится в домене example, который находится в домене верхнего уровня com., 11.22.33.44 означает что хост 44 находится в подсети 33, которая входит в подсеть 22, принадлежащую сети 11. Для сохранения единого порядка PTR записи содержат IP адрес «задом наперед» дополненный доменом верхнего уровня in-addr.arpa.

Читайте также:  Установка автомагнитол в штатные места

Проверить MX и PTR записи также можно командой nslookup используя дополнительный параметр -type=MX или -type=PTR

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

источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Почтовый сервер для начинающих. Структура и принцип работы

Многие системные администраторы испытывают определенные трудности при работе с системами электронной почты. Это неудивительно, почтовый сервер имеет гораздо более сложную структуру, чем файловый сервер, роутер или сервер терминалов. В этой статье мы рассмотрим структуру и принцип работы почтовых серверов, без понимания которых настройка системы электронной почты вполне способна превратиться в шаманские танцы с бубном.

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

Для большинства пользователей и начинающих администраторов почтовый сервер представляет собой некий «черный ящик», который получив письмо «неведомыми» путями доставляет его адресату и наоборот. Все взаимодействие с таким сервером заключается в обращении почтового клиента к определенным портам, а то и вообще через веб-интерфейс. Однако внутри скрыт целый механизм, понимание работы которого имеет ключевое значение для успешной настройки и обслуживания системы электронной почты. Это особенно важно для администрирования серверов на платформе Linux. В отличии от Windows, где почтовый сервер представляет собой законченное программное решение и о внутреннем взаимодействии уже позаботились разработчики, в Linux компоненты почтового сервера представляют собой отдельные программы и настраивать их взаимодействие нужно самостоятельно.

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

Важнейшей часть почтового сервера является MTA (Mail Transfer Agent — агент пересылки почты) в задачи которого входит прием и передача почты. Очень часто (в Linux / UNIX) МТА называют также почтовым сервером. MTA работает по протоколу SMTP, и его одного, в принципе, уже достаточно для создания системы электронной почты. Когда-то давно именно так и было и для доступа к своему почтовому ящику требовалось обладать определенными техническими знаниями.

Однако прогресс не стоит на месте, MTA, получая письмо, помещает его в почтовый ящик пользователя на сервере, к которому последний должен получить доступ, желательно наиболее простым и понятным способом. Вот здесь на сцену выходит MDA (Mail Delivery Agent — агент доставки почты), его задача по запросу почтового клиента передать ему почту из почтового ящика на сервере. MDA может работать по протоколам POP3 или IMAP, в ряде случаев для «общения» почтового клиента и агента доставки могут применяться собственные протоколы, обладающие расширенной функциональностью, например MAPI (Exchange Server).

Вопреки распространенному заблуждению, MDA не имеет никакого отношения к процессу передачи почты. Это прерогатива MTA. Если провести аналогию, MTA можно представить как почтовое отделение, которое занимается приемом и отправкой почты, а MDA с почтальоном, который приносит пришедшую корреспонденцию к вам домой. Если почтальон заболел, то это никак не скажется на работе почты, просто вы не получите письма на дом. Также и MDA, его отказ не приводит к неработоспособности почтового сервера, становится недоступно только получение почты почтовым клиентом, в то же время к ней можно спокойно получить доступ другими путями, например, через веб интерфейс.

Посмотрим, что происходит при отправке почты. В нашем примере пользователь Иванов, находящийся в домене example.org (ivanov@example.org), пишет письмо Козлову в домен example.com (kozlov@example.com). Для Иванова процесс отправки почты состоит из создания сообщения и нажатия кнопки «Отправить» в почтовом клиенте. Почтовый клиент соединяется с МТА по протоколу SMTP и первым делом сообщает свои учетные данные. Авторизовав пользователя, MTA принимает сообщение и пытается доставить его дальше.

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

Читайте также:  Установка расширений для dreamweaver

Для авторизации MTA может использовать собственный список пользователей, системный список, списки пользователей LDAP или AD. Также существует способ: авторизация POP прежде SMTP, когда пользователь перед отправкой почты авторизуется на MDA, который, в свою очередь подтверждает аутентификацию пользователя для MTA.

Следующим шагом MTA анализирует служебную информацию письма, определяя домен получателя, если он относится к доменам обслуживаем данным МТА, производится поиск получателя и письмо помещается в его ящик. Так произошло, если бы Иванов написал письмо Петрову или Сидорову.

Если домен получателя не обслуживается MTA, формируется DNS-запрос, запрашивающий MX-записи для данного домена. MX-запись представляет особый вид DNS-записи, которая содержит имена почтовых серверов, обрабатывающих входящую почту для данного домена. MX-записей может быть несколько, в этом случае MTA пробует последовательно установить соединение, начиная с сервера с наибольшим приоритетом. При отсутствии MX-записи запрашивается A-запись (запись адреса, сопоставляющая доменное имя с IP-адресом) и выполняется попытка доставить почту на указанный там хост. При невозможности отправить сообщение, оно возвращается отправителю (помещается в почтовый ящик пользователя) с сообщением об ошибке.

Мы не будем рассматривать работу принимающего сервера, будем считать что все прошло нормально, Козлов получил письмо от Иванова и написал ему ответ. Сервер, обслуживающий домен example.com, проводит точно такие же действия и пробует передать почту нашему серверу. Получив входящее сообщение MTA, как и в случае с локальным отправителем, проверяет домен получателя, если он входит в число обслуживаемых MТА, обработка сообщения продолжается, иначе сервер отказывается принимать почту. После проверки домена проверяется получатель, если он присутствует в списке пользователей, сообщение доставляется в его ящик, в противном случае возможны два варианта: отказ от приема сообщения или прием сообщения в общий почтовый ящик (ящик администратора). С одной стороны такая настройка увеличивает число принимаемого спама, с другой позволяет не потерять письма с ошибками в написании адреса.

Еще одной мерой защиты от спама является запрос PTR-записи. PTR-запись (запись указателя) связывает IP-адрес с именем домена. Запрашивая PTR, MTA принимает почту только в том случае если домен отправителя совпадает с доменом отправляющего сервера.

Рассмотрим пример более подробно. Некий спамерский сервер spam.com пытается рассылать письма с поддельным отправителем, якобы от известного нам сервера example.com. В случае фильтрации по белым / черным спискам такое письмо будет доставлено, так как отправителем числится пользователь из доверенного домена (на что и рассчитывали спамеры). В целях борьбы со спамом MTA формирует запрос PTR записи для IP-адреса отправляющего сервера, который он сообщает в процессе SMTP сессии. Для адреса y.y.y.y PTR-запрос вернет имя домена spam.com, которое не совпадает с доменом отправителя, что будет причиной отказа в приеме данного сообщения. В то-же время сообщения от сервера x.x.x.x будут получены, так как домен из PTR-записи для x.x.x.x (example.com) совпадает с доменом отправителя.

Итак, сообщение получено и находится в почтовом ящике пользователя. Как его прочитать? Почтовое хранилище, где находятся ящики пользователей, может быть организовано самыми различными способами: начиная от банальных папок и фалов, заканчивая базой данных. Не обладая техническими знаниями, прочитать собственную почту вряд-ли удастся. Но разве это должно волновать пользователя Иванова? Для него процесс получения почты сводится к нажатию кнопки «Получить» в почтовом клиенте.

Для получения почты клиент устанавливает соединение с MDA по протоколу POP3 или IMAP, обязательно передавая данные для авторизации. MDA проверяет наличие пользователя в списках и, при успешной проверке, передает клиенту все новые сообщения находящиеся в его почтовом ящике. Пользователь Иванов получает свою корреспонденцию и может работать с ней удобным ему способом.

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

источник

Как самому сделать себе почтовый сервер?

Столкнулся с тем что все интересные короткие варианты имени для электронной почты заняты.

А что если сделать свой почтовый сервер с тем электронным именем почты которое тебя устраивает ?

К примеру petrov@krivedka.ru

Вопрос, кто может подсказать, как самому создать свой почтовый сервер ?

Дубликаты не найдены

Регистрируешь у хостера, например, nic.ru или рег.ru или ещё кто-то, свой домен криведко.какойтодоменпервогоуровня. Привязываешь его на яндекс https://connect.yandex.ru/pdd/ Смысл в том, что окружающие теперь будут слать на почту яндекс используя имя криведко.какойтодоменпервогоуровня. Пользуешь вебсервисом с яндекса, а почта твоя.

Читайте также:  Установка кондиционеров в крымске

Затраты только на доменное имя.

Судя по вопросу — это лучший вариант. Правильный вариант — VDS с почтовым сервером или дома, имея белый IP, поднять как уже подсказали хоть на Raspberry но лучше на компе тот же Iredmail, но боюсь это потребует уже знаний 🙂 Ведь кроме настройки MX, DNS, TXT, SFP на стороне DNS регистратора, потребуется и банальные пробросы портов на роутере. А это уже в комплексе, чуть выше среднего нужны знания.

Помимо регистрации имени домена надо его ещё где ни будь запарковать, тоесть иметь DNS хостинг. Ну и чтоб норм настройками домена порулить.

на яндексе и держать NSы в чем проблема то ?

почта норм. че гнать то ? мейл ру уебаны. gmail норм .

Все верно, но одно уточнение ник.ру да и вообще наши регистрары, те еще жлобы в плане цен на домены. Поищи что нибудь у буржуев, на зоне «.ru» свет клином не сошелся

krivedka.ru на реге стоит 199 рублей. На годик хватит поиграться)

А продление? Рег.ру — это временами неиллюзорный пиздец.

а продление может и не понадобится)))

Если интересует именно почтовый сервер, то берем какую-нибудь железку, в принципе будет достаточно Raspberry Pi, выпрашиваем у провайдера белый ip (если его нет), регистрируем на него домен c mx записями, и ставим на железку какой-нибудь линукс, далее вопрос настройки, но это просто.

Подходящий домен тоже будет трудно подобрать. Или занято, или стоит приличных денег.

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

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

Достаточно в поиск вбить: «Почта для бизнеса». Будут выданы ссылки yandex, mail.ru , gmail для этих задач — останется только выбрать.

Далее надо выбрать и зарегистрировать домен.

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

Если принципиально нужен собственный почтовик, то тут вариантов просто масса — от собственной машинки, до виртуального сервера в крупном ЦОДе. Софта тоже всякого полно — все не перечислить наскоком.

Уже подсказали нормальный вариант — Яндекс.Почта для домена. Домен можно найти бесплатный.

Ты домен от хостинга отличаешь?

Домен регни и делай чо хошь. Хоть сайт.

вот инструкция для юных спамеров:

У тебя есть WiFi роутер, у провайдера меняешь тариф где он может присвоить тебе белый ip address, на роутере делаешь редирект порта 25 на локальный комп, на компе поднимаешь SMTP сервер, с этого момента на этот ip address можно отправлять письма с внешних адресов, но тебе нужно имя, через сервис dyndns регистрируешь редирект имени на твой ip address этот процесс также можно автоматизировать на wifi роутере.

если не желания привязываться на локальный комп покупаешь VDS виртуальный сервер, там уже есть белый ip address.

КазПочта: перехвалили.

Стоит сказать, что я всегда очень скептически относился к постам подобного рода и никогда не думал, что сам стану автором одного из них… Частенько с ехидной ухмылкой на лице читал новости про беспредел Почты России и думал, «ну, у нас то с этим, как ни странно, все нормально» — ходил в местный супермаркет посылок и довольно быстро получал свои приобретения, но вот случилось… и нет, у меня не украли что-то из посылки, мне не нахамил оператор, все куда интереснее…

Дело в том, что с 5 января в Казахстане практически парализована почтовая служба. Точных причин этого события я не знаю, но существует мнение, что всему виной стала новая система трекинга, призванная не только отслеживать сами посылки, но и подсчитывать их стоимость (с 1 января 2019 введен лимит в 500 евро). Как результат, те посылки, которые успели пройти таможню до 5 января, были успешно получены, а те, которые не успели – находятся в метафизическом состоянии где-то вне нашей реальности.

Но возмущает даже не сама ситуация в целом и не то, что на все обращения поддержка КазПочты отвечает банальным: «Ваша посылка не поступала не территорию РК», а кромешная тишина в СМИ. При том, что вот уже две недели граждане лишены почтовых услуг, ни одно, даже захудалое интернет-СМИ, не выпустило по этому поводу никаких сообщений. И я тут подумал – может они просто не в курсе и им нужно помочь? Посему прошу максимальную огласку. Пост, само собой, без рейтинга.

источник

Добавить комментарий