Меню

Настройка sendmail на порт



Установка и настройка sendmail

Настраиваем sendmail (8.12.6/7/8) для виртуального почтового хостинга.

Установка sendmail

Сначала устанавливаем итз портов sendmail c поддержкой cyrus sasl (система аутентификации).

После установки sendmail мы должны изменить файл /etc/make.conf. Добавляем в него строчку

Если до этого стоял более старый sendmail, устанавливаем файл submit.cf

Для запуска sendmail будем использовать следующий сценарий (переименуем его в удобоваримый формат):

Для нормального запуска обновленной версии мы должны указать путь к ней (файл /etc/mail/mailer.conf). Это можно сделать либо при помощи команды

либо вручную, изменив файл mailer.conf:

На этом установка sendmail окончена. Осталоь столько запустить его командой

Сообщения sendmail sm-msp-queue говорят о том, что все прошло нормально.

Настройка sendmail

Будем считать, что мы настраиваем два виртуальных почтовых домена: perldoc.ru и perlfaq.ru. Для настройки sendmail c поддержкой виртуального постового хостинга нам потребуется создать (или изменить) следующие файлы:

  • freebsd.mc
  • aliases
  • access
  • local-host-names
  • virtusertable

aliases

Этот файл описывает пользовательские псевдонимы, используемые sendmail. Файл расположен в каталоге /etc/mail и представляет собой список вида

Более подробно структура файла aliases описана в aliases (5). В этот файл мы добавляем строку

Вся локальная почта, адресованная пользователю root, теперь будет приходить на адрес admin@perldoc.ru.

access

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

local-host-names

В этом файле мы храним названия доменов, для которых наш сервер должен обрабатывать почту. Поскольку мы хотим использовать наш сервер для двух виртуальных почтовых доменов perldoc.ru и perlfaq.ru, пропишем их в файл:

virtusertable

В файле virtusertable мы указываем sendmail, куда направлять почту, пришедшую на адреса в доменах perldoc.ru и perlfaq.ru.

Вся почта, пришедшая на адрес stellar@perldoc.ru будет направляться в почтовый ящик пользователя stellar-perldoc.ru, а почта, пришедшая на admin@perldoc.ru, соответственно будет отсылаться пользователю admin-perldoc.ru. Тоже самое будет и для домена perlfaq.ru. Если на наш домен будет прислана почта с несуществующем пользователем, сработает строчка

и sendmail откажется принимать такое сообщение.

freebsd.mc

Теперь нам осталось только изменить конфигурацию файла freebsd.mc, чтобы sendmail научился работать с виртуальными почтовыми доменами. Здесь надо понимать, что в том случае, когда существует файл, у которого имя совпадает с названием машины (например, для машины с именем genius файл будет genius.mc), он используется вместо файла freebsd.mc

Вот примерный вид конфигурационного файла:

В строке 6 мы задаем файл с пользовательскими псевдонимами; в десятой строке — имя файла трансляции виртуальных пользователей в настоящих, а в 36-й строке — названия доменов, для которых наш сервер должен обрабатывать почту.
Также ограничим максимальный размер письма одним мегабайтом (строка 49) и запретим рассылать письмо одновременно более, чем 10 получателям (строка 48). Если есть необходимость отправки всей почты на промежуточный SMTP сервер (например, на SMTP сервер провайдера), следует раскомментировать строку 31 и вместо «your.isp.mail.server» указать IP адрес или имя SMTP сервера провайдера.

Запуск и тестирование

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

Результатом будет нечто вроде этого:

/usr/bin/m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/ /usr/local/share/sendmail/cf/m4/cf.m4 genius.mc > genius.cf /usr/sbin/makemap hash virtusertable.db Свойства почтового ящика -> Транспорт -> Аутентификация

Выделяем чекбокс «Аутентификация SMTP (RFC-2554)».
Переключаем кнопку «Использовать параметры, указанные ниже.»
Вводим имя пользователя и пароль, которые создали при помощи saslpasswd2.
Пользователь: admin-perldoc.ru@genius.
Пароль: *********

(!) Обратите внимание на то, что имя пользователя указано вместе с именем машины.
Выделяем чекбокс «Требовать безопасную (MD5) аутентификацию».

В том случае, если используется MS Outlook или другой почтовый клиент, в котором нет безопасной аутентификации (DIGEST-MD5, CRAM-MD5), необходимо использовать аутентификацию по методам PLAIN или LOGIN. При этом в качестве имени пользователя надо использовать имя пользователя БЕЗ добавленного имени машины. В нашем случае имя пользователя будет выглядеть так: admin-perldoc.ru.

После отправки письма в лог-файле /var/log/maillog должны быть примерно такие записи:

Источник

Настройки отправки почты через SMTP

05 июля 2016. Категория: Нужно знать!

Встречаются случаи, когда сайтостроители сталкиваются с проблемой работы электронной почты сайта на CMS Joomla. Например, при отправки письма через форму обратной связи могут появляться ошибки следующего типа: «Could not instantiate mail function» или «Не удалось вызвать функцию mail» . Также возможен вариант отправления письма без появления ошибок, однако в результате оно все равно не доходит до адресата.

Почему же происходят данные проблемы с почтой? Чтобы ответить на данный вопрос необходимо в панели управления пройти по следующему пути: «Система» — «Общие настройки» — вкладка «Сервер» — раздел «Настройка почты».

В CMS Joomla предусмотрено три механизма отправки писем: PHP Mail, Sendmail и SMTP. По умолчанию используется PHP Mail с которым зачастую и происходят проблемы, которые, в основном, связаны с настройками используемого хостинга.

Исходя из вышеизложенного делаем вывод: либо обращаемся за помощью к хостинг провайдеру, либо используем способ отправки писем Sendmail или SMTP. Остановимся на использовании SMTP.

Настройки отправки почты при помощи SMTP

SMTP (англ. Simple Mail Transfer Protocol) — сетевой протокол, используемый для передачи электронной почты. Для использования SMTP необходимо корректно выставить настройки определенного почтового сервера, который будет использоваться.

Чтобы увидеть настройки SMTP, необходимо в «Способе отправки» выбрать «SMTP». Рассмотрим каждую настройку популярных почтовых серверов: Yandex, Mail, Gmail, Rambler и Yahoo.

Настройки SMTP для Yandex

Настройки SMTP для Mail

Настройки SMTP для Gmail

Настройки SMTP для Rambler

Настройки SMTP для Yahoo

Проверить отправку почты можно при помощи нажатии кнопки «Send test mail», которая размещена под всеми настройками почты.

Источник

Настройка sendmail на порт

Я не администратор, поэтому относитесь к этой заметке с осторожностью.
Рассматривается такя ситуация: надо заставить sendmail сервера отправлять почту, но ничего в ответ не принимать. Строго для оповещений с сайтов. У меня вдс-ка с предустановленным exim4 на который, насколько я понимаю, «ссылается» sendmail. Т.е. фактически работает exim4.

Сначала настраиваем хост (my-host-name это имя нашего хоста с которого все будет ездить) В файле должны быть строки вида Далее меняем имя хоста в файле Файл должен выглядеть вот так (полностью, т.е. только имя хоста и все) Теперь перегружаем службу которая грубо говоря обновляет имя хоста глобально REM ещё такой вариант есть, для Debian 9 (stretch) Теперь выполняем команды Если все правильно сделано, то они обе должны вернуть значение my-host-name (т.е. имя вашего хоста)

Теперь надо настроить сам sendmail. В моем случае, нужно перенастроеить exim4. Делается это примерно так: После этого в мастере просто нужно выбирать значения (именно для exim4)

  • internet site..
  • вводим название вашего хоста (my-host-name)
  • ip для smtp устанавливаем только 127.0.0.1 т.к. нам не нужны внешние подключения по smtp
  • другие допустимые назначения оставляем по умолчанию
  • домены для разрешенного релея — оставляем пустым
  • машины для релея — оставляем пустым
  • кол-во днс запросов на ваше усмотрение, я не ограничивал
  • метод доставки я оставил тот же который был, т.е. /var/mail
  • разделять не разделять файлы конфигурации — на ваше усмотрение, аргументы там описаны, я разделять не стал

Теперь, чтобы проверить ходит ли почта делаем так Далее вводим тект тестового сообщения. И по готовности нажимаем Ctrl+d
Идем проверяем свою почту. Если письмо пришло — все ок и ура. Если нет — идем гуглить дальше 🙂

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

Ещё маленькая фишка. Бывает так что по каким-то причинам, сервис рулящий веб-приложением надо перезапускать регулярно. В моем случае это node.js и делаю я это по крону раз в N времени. Так вот если перезапустить процесс кроном, то sendmail перестает работать, потому как приложение не знает где он, в path пути до него просто нет и соот-но он просто не находится. Точно так же можно передавать любые другие настройки переменных окружения. Как это делать смотрим ниже.

Сначала посмотрим где sendmail Ок, видим путь. Если вдруг не видим то идем смотреть тоже самое но под sudo. Теперь идем в кронтаб и добавляем переменные окружения там. Откроется редактирование заданий для текущего пользователя. То есть все задания будут выполнены с правами текущего пользователя и сервис запустится с правами этого пользователя, если он запускается конечно согласно вашему плану 🙂

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

Пользовался вот этим источником. Рекомендую на него взглянуть, надеюсь он ещё дышит.

Источник

Как работает Sendmail? Полезные подробности. Часть 1

Архив номеров / 2006 / Выпуск №5 (42) / Как работает Sendmail? Полезные подробности. Часть 1

Сергей Супрунов

Как работает Sendmail?

Полезные подробности. Часть 1

Современная жизнь немыслима без электронной почты. Ещё лет десять назад само понятие «электронная почта» прочно ассоциировалось с программой Sendmail. Сейчас ситуация несколько изменилась, но проект Sendmail по-прежнему остаётся одним из лидеров, и вполне заслуженно.

Среди системных администраторов, особенно начинающих, бытует мнение, что Sendmail – чрезвычайно сложная, неуклюжая, неэффективная и небезопасная программа. Конечно, дыма без огня не бывает, и причины для подобных мнений есть. Достаточно взглянуть на основной конфигурационный файл – sendmail.cf, чтобы согласиться с первым утверждением. Монолитная архитектура, когда практически все функции выполняются одним двоичным файлом, навевает мысли о втором и третьем. Нередкие взломы в прошлом (долго ещё люди будут помнить червя Морриса, потрясшего мир в 1988 году) серьёзно подорвали доверие к Sendmail в плане защищённости системы.

Однако идёт время, меняется ситуация. Кое-что из сказанного выше несколько улучшилось, что-то вообще стало неправдой. Скажем, конфигурационный файл по-прежнему остался пугающе непонятным. Но ведь никто вас и не заставляет его править! Для этого существуют более удобные и простые инструменты. Монолитность сохранилась, но работа этого единственного «бинарника» стала более эффективной, появилось более чёткое разделение на задачи, причём уже не все из них требуют наличия прав суперпользователя. Говоря же о безопасности, надо признать, что последняя критическая уязвимость была обнаружена сравнительно недавно – 22 марта 2006 года (к чести разработчиков, была она исправлена достаточно быстро). Но вот предпоследняя датируется аж 18 сентября 2003 года.

Конечно, если сравнивать Sendmail с такими альтернативами, как Postfix, Exim, Qmail, то по некоторым параметрам он проигрывает своим конкурентам. Но только не в плане функциональности. Так что вряд ли стоит так просто сбрасывать его со счетов. Тем более что Sendmail по-прежнему остаётся почтовой программой, устанавливаемой по умолчанию во FreeBSD, OpenBSD, Solaris и ряде других систем.

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

Всё, о чём будет идти речь сегодня, относится к версии Sendmail 8.13.4 с последним патчем, работающей во FreeBSD 6.0 (используется дистрибутивная установка). Применимость утверждений, примеров конфигурации, путей к файлам и т. д. к другим системам и версиям не проверялась, но в большинстве случаев всё должно работать аналогично.

Учитывая, что на системах Linux в последнее время более распространён Postfix (за исключением некоторых дистрибутивов), отвлекаться на особенности Sendmail в этих системах я не буду.

Архитектура и основы функционирования

Как уже упоминалось, Sendmail является монолитной программой. Единственный двоичный файл – /usr/sbin/mailwrapper – отвечает за все функции, но вручную его обычно не запускают. Все же программы, которыми мы обычно пользуемся, являются не более чем простыми символьными ссылками на этот «бинарник»:

serg$ ls -l /usr/sbin | grep mailwrapper

lrwxr-xr-x 1 root wheel 21 11 ноя 10:01 hoststat -> /usr/sbin/mailwrapper

-r-xr-xr-x 1 root wheel 5236 11 ноя 10:01 mailwrapper

lrwxr-xr-x 1 root wheel 21 11 ноя 10:01 purgestat -> /usr/sbin/mailwrapper

lrwxr-xr-x 1 root wheel 21 11 ноя 10:01 sendmail -> /usr/sbin/mailwrapper

serg$ ls -l /usr/bin | grep mailwrapper

lrwxr-xr-x 1 root wheel 21 11 ноя 10:01 mailq -> /usr/sbin/mailwrapper

lrwxr-xr-x 1 root wheel 21 11 ноя 10:01 newaliases -> /usr/sbin/mailwrapper

Если говорить точнее, то собственно работа выполняется файлом /usr/libexec/sendmail/sendmail, а mailwrapper, как следует из его названия, является «обёрткой» к этому файлу. Система, как правило, пользуется ссылкой sendmail, остальные же запускаются администратором для решения конкретных задач.

Посмотрим, какие задачи возлагаются на программу Sendmail. Если посмотреть на вывод команды ps, то можно увидеть, что в системе активны сразу несколько процессов sendmail:

serg$ ps awxo pid,user,command | grep sendmail | grep -v grep

596 root sendmail: accepting connections (sendmail)

600 smmsp sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)

83329 root sendmail: k35B3pRn083329 [59.42.1.71]: DATA (sendmail)

83670 root sendmail: server N023143.ppp.ne.jp [61.20.23.14] cmd read (sendmail)

Чем же они занимаются? Два верхних (с PID 596 и 600 соответственно) запускаются при старте системы и постоянно присутствуют в памяти. Первый, как следует из описания, обслуживает входящие соединения, поступающие на порты, выделенные для SMTP-соединений:

serg$ sockstat | grep 596

root sendmail 596 3 tcp4 1.2.3.4:25 *:*

root sendmail 596 4 dgram -> /var/run/logpriv

root sendmail 596 5 tcp4 127.0.0.1:25 *:*

root sendmail 596 6 tcp4 10.0.0.254:25 *:*

root sendmail 596 7 tcp4 *:587 *:*

Как видите, помимо стандартного 25-го порта на обслуживаемых интерфейсах (рассматриваемая система имеет две сетевые карты – внешнюю, с условным IP-адресом 1.2.3.4, и внутреннюю – 10.0.0.254, а также непременный loopback-интерфейс 127.0.0.1) процесс 596 прослушивает порт 587. Этот порт (в /etc/services определён как «submission 587/tcp») предназначен согласно RFC 2476 для приёма новых писем от клиентов, чтобы не перегружать данной работой основной, 25-й порт, служащий для пересылки сообщений между серверами. (То есть более правильно в настройках почтовых клиентов – The Bat, Thunderbird, Outlook и проч. – указывать для исходящих соединений 587-й порт.) В настоящее время протокол Submission используется не слишком широко, и клиенты для отправки электронной почты задействуют тот же 25-й порт, но ничего плохого в том, что данный порт открыт, в принципе нет. Тем более что данная рекомендация (я про RFC 2476) рано или поздно должна стать популярной. UNIX-сокет на /var/run/logpriv (с дескриптором 4) используется для записи журнальной информации с помощью syslog (обратите внимание, что поскольку этот процесс sendmail работает с правами суперпользователя, то используется привилегированный сокет).

Думаю, задача этого процесса понятна – получив запрос на соединение, он порождает дочерний процесс (в нашем выводе команды ps вы можете наблюдать два экземпляра оных – с PID 83329 и 83670), который и занимается обслуживанием данного соединения согласно протоколу SMTP.

Второй процесс, PID которого равен 600, отвечает за обслуживание очереди. Если говорить точнее, то сам он очередь не обслуживает, а лишь запускает с заданным интервалом (в данном случае он составляет 30 минут, как видно из листинга) другой процесс, который и выполняет всю грязную работу.

Ах да, я же ещё не рассказал, что такое очередь! Ничего, скоро этот пробел будет восполнен…

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

Кто кому родитель

Итак, при обработке сообщения для локального клиента, выполняется следующая последовательность действий (см. рис. 1):

  1. Удалённый сервер, желая передать нам сообщение, отправляет запрос на соединение на 25-й порт нашего сервера.
  2. Процесс sendmail, обслуживающий соединения (тот, который в примере выше имеет PID 596), порождает дочерний процесс (назовём его sm1).
  3. Дочерний процесс sm1 проверяет возможность принять данное сообщение (анализируя конверт, прежде всего «rcpt to:») и в случае положительного ответа помещает сообщение в очередь, в файлы qf (заголовки) и df (тело сообщения). Причём qf обычно создаётся в памяти и записывается на диск только в случае невозможности переслать письмо сразу. То есть очередь – это каталог, куда временно сохраняются почтовые сообщения, проходящие через сервер электронной почты (по умолчанию используется /var/spool/mqueue).
  4. Если запись пройдёт успешно, Sendmail подтверждает факт приёма сообщения (принимая тем самым на себя всю ответственность за его дальнейшую судьбу) и завершает соединение с удалённым сервером.
  5. Далее sm1 анализирует заголовок сообщения и принимает решение о том, что нужно с ним делать. Если оно предназначено для локального пользователя, то вызывается локальный агент доставки, LDA (Local Delivery Agent), которому даётся поручение положить письмо в почтовый ящик пользователя.
  6. Когда LDA успешно выполняет доставку, он рапортует об этом процессу sm1, который удаляет сообщение из очереди и завершает свою работу.

Рисунок 1. Приём сообщения

Передача сообщения от локального пользователя на удалённый сервер выполняется в следующем порядке (см. рис. 2):

  1. Локальный клиент (MUA – Mail User Agent), такой как утилита mail, вызывает процесс send-mail (выступающий в роли MSA – Mail Submission Agent).
  2. Процесс send-mail принимает сообщение, переданное клиентом, и подключается на 25-й порт хоста localhost.
  3. Процесс, прослушивающий соединения на 25-м порту, порождает дочерний процесс sm1 для обработки данного соединения.
  4. Sm1, приняв сообщение и поставив его в очередь, предпринимает попытку передать его получателю, для чего составляет маршрут движения письма и устанавливает соединение с первым сервером (в большинстве случаев он же является и последним, т.е. сервером, непосредственно обслуживающим домен получателя).
  5. Дождавшись подтверждения о приёме сообщения от удалённого сервера, sm1 удаляет сообщение из очереди и завершает работу.

Рисунок 2. Передача сообщения

В случае транзитной передачи сначала выполняются пункты 1-4 алгоритма приёма сообщения, затем выполняется доставка согласно пунктам 4-5 алгоритма передачи локального сообщения (см. рис. 3).

Рисунок 3. Транзитная передача

Обратите внимание, что здесь всё завязано на выполнении основополагающего требования – надёжности передачи. Ни при каких обстоятельствах письмо не должно потеряться (разве что в случае прямого попадания в сервер из «базуки»). Промежуточная запись на диск, даже когда это, казалось бы, излишне, является обязательной, поскольку только это гарантирует целостность данных в случае сбоя на сервере. Впрочем, «если нельзя, но очень хочется – то можно», и здесь есть приёмы, позволяющие обойтись без «лишней» записи на диск (это мы обсудим в одной из последующих частей статьи, где будем говорить об оптимизации и нестандартной настройке).

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

Возвращаясь к процессам

Как видите, Sendmail может выступать в трёх ипостасях – MTA, MSA и MDA. В таких инструментах, как Postfix и Qmail, применяется понятная структура «одна задача – одна программа». Здесь же всё делает один исполнимый файл. Так что не мудрено, что он обладает огромным количеством самых разных параметров. Перечислю здесь наиболее востребованные (за подробностями обратитесь к странице man sendmail(8)):

  • -b: этот ключ указывает на то, что необходимо выполнить какое-то действие, и всегда дополняется уточняющим ключом;
  • -bd: работать в режиме демона;
  • -bm: работать в режиме отправки сообщения – аналогично команде mail;
  • -bs: выводить команды SMTP на стандартный вывод (фактически, то же самое, что и «telnet localhost 25»);
  • -bt: работать в режиме тестирования (позволяет выполнить ряд команд, например, обработать адрес или определить MX-запись для хоста);
  • -bv: проверить адрес получателя (фактически, «разворачивает» псевдонимы, показывая реального пользователя или скрипт, которые получат письмо). Следующий пример показывает, что на моей системе адресу postmaster соответствует скрипт maildigest.py, используемый для обработки сообщений антивирусного пакета и сбора статистики по вирусной активности на узле:

root# sendmail -bv postmaster

Рубрика: Администрирование / Продукты и решения
«| /usr/local/scripts/maildigest/maildigest.py». deliverable: mailer prog, user «| /usr/local/scripts/maildigest/maildigest.py»

Другие полезные ключи:

  • -C: с помощью этого ключа вы можете указать альтернативный файл конфигурации (отличный от /etc/mail/sendmail.cf).
  • -q: этот ключ задаёт период обработки очереди. Например, указанный как -q30m, он установит обработку очереди сообщений каждые 30 минут.
  • -t: даёт указание извлечь адрес получателя из соответствующих полей заголовка самого почтового сообщения. Может быть полезен при ручной отправке почты.
  • -d: эти ключи задают уровень отладки.

Вот, кстати, приём, позволяющий получить информацию о версии вашего Sendmail:

serg$ echo «» | /usr/sbin/sendmail -bt -d0 | grep Version

Version 8.13.4

Для сокращения числа ключей можно использовать другие ссылки на mailwrapper, специально предназначенные для решения конкретных задач. В таблице 1 приводится соответствие «специализированной» команды ключам программы sendmail.

Таблица 1. Ключи sendmail и специальные ссылки

Пересоздаёт базу псевдонимов

Работа с очередью сообщений

Если вы посмотрите на сценарии инициализации, используемые системой, то увидите, что FreeBSD использует преимущественно ссылку sendmail с необходимыми для решения той или иной задачи ключами.

Как же всё это настраивается? Начиная с 4-й (если не ошибаюсь) ветви, в системе FreeBSD основные настройки сосредоточены в каталоге /etc/mail (ранее, по крайней мере в 3.5-RELEASE, они размещались непосредственно в /etc). Здесь вы найдёте следующие основные файлы:

  • your.domain.mc: основной конфигурационный файл (так называемый master config, или просто mc-файл). Его имя будет соответствовать доменному имени вашего сервера. Именно в него вносятся необходимые изменения, и на его основе автоматически будет собираться рабочий файл sendmail.cf.
  • your.domain.submit.mc: конфигурационный файл для работы в режиме доставки сообщений, когда Sendmail не обслуживает внешние соединения, а только отправляет почту от локальных пользователей (в этом случае Sendmail запускается с правами обычного пользователя и использует для работы очередь /var/spool/clientmqueue).
  • sendmail.cf, submit.cf: рабочие файлы конфигурации, которые и использует Sendmail. Настоятельно не рекомендуется вносить в них исправления вручную, хотя никто и не запрещает это делать. Просто нужно иметь в виду, что в данном случае все сделанные вами изменения будут потеряны при первом же выполнении make install, поскольку утилита make при сборке cf-файлов руководствуется исключительно данными, содержащимися в mc-файлах. Безусловно, учитываются и m4-шаблоны, размещённые в /usr/share/sendmail/cf/, но их тоже лучше не изменять.
  • aliases: здесь хранятся псевдонимы пользователей. Говоря упрощённо, псевдоним позволяет вам наиболее простым способом перенаправлять почту, приходящую на тот или иной почтовый ящик, на конкретного пользователя. Этот же механизм используется для создания списков рассылки или перенаправления почты на вход какой-либо программы.
  • access: этот файл позволяет управлять доступом к почтовому серверу извне. Например, вы можете запретить доступ из конкретной подсети или разрешить пересылку (relaying) почты для некоторых нелокальных адресов.
  • local-host-names: список хостов (их доменных имён), для которых сервер Sendmail будет принимать почту. Используется, в частности, для организации виртуального почтового хостинга.
  • mailertable: этот файл используется для определения специфических обработчиков для некоторых адресов. Например, так может выглядеть строка для обработки UUCP-почты пользователя account.

account.myserver.ru uucp-dom : account

То есть для обработки почты локального пользователя account будет использоваться протокол UUCP с соответствующим преобразованием адреса.

  • virtusertable: здесь размещаются записи, определяющие виртуальных пользователей. Подробнее вопросы виртуального хостинга будут рассмотрены во второй части статьи.
  • mailer.conf: конфигурационный файл для /usr/sbin/mailwrapper. Здесь задаётся соответствие «удобных» имён файлов, таких как mailq, реально вызываемому двоичному файлу. Например, согласно такой строке в этом файле:

если mailwrapper будет вызван по ссылке mailq, то он запустит программу sendmail, которая размещается по указанному пути. Собственно говоря, любая команда будет запускать этот файл (архитектура-то монолитная), но теоретически здесь заложена возможность использовать для тех или иных задач внешние файлы или в дальнейшем безболезненно перейти на модульную структуру (это, в частности, используется в Postfix).

  • helpfile: здесь размещаются строки, которые Sendmail будет выводить во время SMTP-сеанса в ответ на команды HELP.

Более подробно использование того или иного файла будет рассматриваться во второй части статьи.

Обратите внимание, что около aliases, access и ряда других будут размещаться файлы с таким же именем, но суффиксом «.db». Это базы (обычно в формате hash, но также поддерживаются dbm и btree), которые и использует Sendmail в своей работе, чем достигается сокращение времени, расходуемого на разбор этих файлов. Следовательно, после внесения изменений в «хэшируемые» конфигурационные файлы вы должны пересоздавать соответствующие базы.

Традиционно это выполняется командой makemap (для базы aliases – команда newaliases, являющаяся одной из ссылок на mailwrapper). Однако разработчики FreeBSD предоставили нам замечательный Makefile, который делает большую часть работы по обслуживанию почтовой системы, самостоятельно вызывая необходимые служебные утилиты.

В данном случае достаточно перейти в каталог /etc/mail и выполнить команду make:

root# cd /etc/mail

При этом make самостоятельно определит, какие файлы были изменены, и пересоздаст соответствующие базы. Если были изменения в конфигурационном mc-файле, то эта же команда построит на его основе cf-файл (например, your.domain.cf; далее нужно будет ещё выполнить make install, чтобы этот файл был скопирован как sendmail.cf). При желании вы можете явно указать, что именно должно быть пересобрано:

root# make aliases

/usr/sbin/sendmail -bi -OAliasFile=/etc/mail/aliases

/etc/mail/aliases: 167 aliases, longest 47 bytes, 2529 bytes total

chmod 0640 /etc/mail/aliases.db

Как видите, всё предельно просто. Кстати, раз уж у нас зашла речь о Makefile, помимо сборки и установки конфигурационных файлов, он же позволяет управлять запуском/остановом/перезагрузкой необходимых процессов (make start, make stop, make restart соответственно). Можно даже работать по отдельности с каждым процессом:

root# make restart-mspq

root# make stop-mta

Нужно заметить, что сами команды управления процессами размещаются в /etc/rc.sendmail. Makefile лишь вызывает этот сценарий с нужными параметрами. Обратите внимание, что в рассматриваемой версии FreeBSD запуск sendmail при загрузке системы может выполняться другим сценарием – /etc/rc.d/sendmail. Это более соответствует принятому начиная с 5-й ветви порядку инициализации (он был позаимствован из NetBSD), но подобное «двоевластие» может в некоторых случаях привести к путанице и ошибкам (например, если вам нужно внести в эти файлы какие-то специфические изменения, то приходится особо следить за их синхронизацией).

Раз уж мы заговорили о сценариях инициализации, рассмотрим параметры rc.conf, определяющие работу Sendmail. Основные настройки сосредоточены в файле /etc/defaults/rc.conf. По умолчанию переменная sendmail_enable установлена в значение «NO», что подразумевает работу Sendmail только для отправки сообщений локальных пользователей. MTA, обслуживающий внешние соединения, запускаться не будет. Чтобы разрешить работу Sendmail в режиме MTA, следует установить значение этой переменной в «YES». Кстати, если вы хотите полностью запретить работу Sendmail, используйте значение «NONE», а не «NO».

Обратите внимание на одну важную переменную:

Именно она определяет, какой из сценариев – /etc/rc.sendmail или /etc/rc.d/sendmail – будет использоваться при загрузке системы. По соображениям «однозначности» лучше оставить использование rc.sendmail, как это и предусмотрено по умолчанию.

Подробнее узнать об опциях, которые вы можете изменить, можно в самом файле /etc/defaults/rc.conf – он достаточно хорошо прокомментирован. Ну и при необходимости что-то переопределить внесите соответствующие строки в /etc/rc.conf (надеюсь, вы даже спросонья без запинки скажете, почему не рекомендуется делать изменения непосредственно в default-скриптах).

Пример файла конфигурации

Рассмотрим небольшой пример mc-файла, для того чтобы в общих чертах познакомиться с синтаксисом и наиболее типичными директивами (подробно конфигурация будет рассматриваться во второй части статьи). Он представляет собой набор команд макропроцессору m4, который используется для сборки cf-файла. Подробнее о m4 мы поговорим в следующий раз, пока же просто рассмотрим некоторые опции, не вдаваясь в подробности. Поскольку комментарии в m4 выглядят не совсем привычно, то вместо пояснений в самом файле разобьём его на отдельные строки:

Директива divert() служит для переключения режимов макропроцессора. Собственно, сама конфигурация начинается после divert(0), поэтому между указанными строками часто помещают комментарии к файлу. Буквы dnl, присутствующие в конце каждой строки, в m4 означают конец строки. Если вы хотите закомментировать какую-то директиву, перенесите dnl в начало строки.

Тип операционной системы. Согласно данному параметру m4 будет выбирать необходимые для работы шаблоны (из /usr/share/sendmail/cf/ostype/), поэтому очень важно следить здесь за актуальностью информации (особенно когда выполняется обновление системы на другую «ветку»). В первую очередь от этого параметра зависят принятые в той или иной системе полные имена агентов доставки (LDA), используемые флаги и т. д.

Ещё один параметр, влияющий на выбор шаблонов. Шаблоны можно найти в /usr/share/sendmail/cf/domain/, в большинстве случаев следует использовать домен «generic». Впрочем, если вам нужны специфические параметры, которые по тем или иным причинам вам не хотелось бы выносить в конфигурационный файл, можно создать здесь свой «доменный» шаблон (посмотрите здесь же примеры для доменов Berkley.EDU) и использовать его.

dnl DAEMON_OPTIONS(‘Name=IPv4, Family=inet’)dnl

Подобным образом указывается, на каких адресах и портах следует прослушивать входящие соединения. Первая строка из приведённых (закомментированная) указывает ожидать входящие соединения на всех IPv4-интерфейсах. Если прослушивать нужно только конкретные интерфейсы, можно поступить так, как показано в последующих двух строках.

define(‘confCW_FILE’, ‘-o /etc/mail/local-host-names’)dnl

Эти строки задают использование файла local-host-names и указывают путь к нему.

Данные две директивы (сейчас они закомментированы) позволяют несколько ослабить требования стандартов. Первая разрешает обслуживать не полностью квалифицированных отправителей (т.е. не имеющих полного имени формата user@domain). Вторая допускает работу с доменами, для которых не удалось определить их DNS-имя по IP-адресу.

FEATURE(mailertable, ‘hash -o /etc/mail/mailertable’)dnl

FEATURE(access_db, ‘hash -o -T /etc/mail/access’)dnl

FEATURE(virtusertable, ‘hash -o /etc/mail/virtusertable’)dnl

Эти строки описывают пути к специальным файлам конфигурации. Обратите внимание, что имена баз указаны без суффикса «.db».

dnl FEATURE(‘dnsbl’, ‘sbl.spamhaus.org’)dnl

Строки, реализующие встроенный в Sendmail механизм борьбы с так любимым нами спамом. Он основан на «чёрных списках», отклоняя любые попытки установить соединение со стороны IP-адреса, присутствующего в одном из указанных списков. Для таких адресов Sendmail выдаёт код 550 и разрывает соединение. Если же адреса в базе rbl-сервера нет, то соединение принимается. На страницах журнала уже неоднократно обсуждались недостатки такого подхода, так что использовать его следует с особой аккуратностью.

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

Максимальное число дочерних процессов, которые могут быть запущены одновременно. Эта опция помогает ослабить последствия DoS-атаки на почтовую подсистему, ограничивая число запущенных процессов и не позволяя, тем самым, вызвать катастрофическую перегрузку системы.

Эта опция позволяет задать ряд дополнительных флагов, управляющих работой протокола SMTP. В данном случае запрещается выполнять smtp-команды VRFY и EXPN, которые по умолчанию позволяют любому пользователю (в том числе и спамеру) достаточно легко проверить наличие на сервере конкретного почтового ящика и «развернуть» списки рассылки (если таковые имеются).

Ну а так указывается, какие агенты доставки будут использоваться. Здесь определены локальный агент доставки (LDA), и использование протокола SMTP для доставки на удалённые серверы (MDA). Закомментированная строка отвечала некогда за подключение агента, работающего по протоколу UUCP, ныне практически вымершему.

Немного подробнее мы поговорим о конфигурации в следующий раз. После внесения всех изменений в mc-файл нужно выполнить следующие действия:

root# cd /etc/mail

root# make install

root# make restart

После этого Sendmail будет перезапущен в новой конфигурации.

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

Как всё начиналось

В конце семидесятых Эрик Олман (Eric Allman), работая в Университете Беркли, бился над одной проблемой – как обмениваться электронной почтой в университетской сети, объединяющей несколько машин, взаимодействующих между собой по разным протоколам. Существовали, конечно, отдельные программы, обеспечивающие взаимодействие каждой пары машин, но Эрику хотелось создать именно универсальную программу.

И вот в 1983 году появилась первая версия программы Sendmail, основанной на менее универсальной delivermail (разработанной для сети ARPANET). Первоначально созданная для BSD 4.1c, она постоянно развивалась, переносилась на другие системы. Многие компании брали Sendmail за основу для построения собственных почтовых программ.

В настоящее время наиболее известной и распространённой версией Sendmail является открытая программа, разрабатываемая Sendmail Consortium при спонсорской помощи компании Sendmail Inc. Последняя выпущенная версия – 8.13.6.

Несколько слов про SMTP

Simple Mail Transfer Protocol (SMTP) – простой протокол передачи электронной почты – является основным протоколом, на котором основана работа электронной почты в сети Интернет. Описан он в RFC 821, который дополнен рядом других рекомендаций. Наиболее серьёзным дополнением (скорее даже заменяющим документом) является RFC 2821, описывающий расширенный протокол SMTP и более соответствующий современным реалиям.

SMTP является, скажем так, «терминальным» протоколом, то есть взаимодействие двух систем осуществляется путём обмена текстовыми строками. Клиент (хост, инициировавший соединение) передаёт на сервер (хост, принимающий соединение) команды, состоящие из четырёх букв и следующих далее параметров. Сервер отвечает трёхзначным числовым кодом с последующей строкой-пояснением.

Типичный пример SMTP-диалога может выглядеть таким образом:

serg$ telnet localhost 25

Connected to localhost.

Escape character is «^]».

220 server.ru ESMTP Sendmail 8.13.4/8.13.4; .. ..

250 server.ru Hello localhost [127.0.0.1], pleased to meet you

MAIL From: me@me.domain.ru

250 2.1.0 me@me.domain.ru. Sender ok

RCPT To: serg@server.ru

250 2.1.5 serg@server.ru. Recipient ok

354 Enter mail, end with «.» on a line by itself

Hello! It’s a test message.

250 2.0.0 k3BAK9Je017265 Message accepted for delivery

221 2.0.0 server.ru closing connection

Connection closed by foreign host.

Как видите, смоделировать работу SMTP-протокола достаточно просто. Но нужно заметить, что полная поддержка протокола – достаточно сложная задача, требующая учёта многих факторов.

Unix to Unix Copy Program (UUCP) – некогда очень популярный протокол взаимодействия между удалёнными хостами. Пересылка электронной почты не была его единственной обязанностью, но эта услуга была наиболее востребована. Sendmail, будучи разработанным как универсальный почтовый сервер, призванный объединить разнородные сети, обладает поддержкой этого протокола (правда, реализация осуществляется сторонней программой – во FreeBSD это Taylor UUCP, установить её можно из коллекции портов: /usr/ports/net/freebsd-uucp).

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

По различным данным, среди наиболее популярных открытых серверов электронной почты наблюдается примерно такое соотношение: Sendmail – 24%, Postfix – 17%, Exim – 9%, Qmail – 4%. Если сравнить эти цифры с данными за 2001 год (соответственно 42%, 2%, 1%, 17%), то можно отметить довольно существенное снижение доли Sendmail, прежде всего за счёт Postfix, активно используемого на небольших серверах и домашних системах. Тем не менее, Sendmail по-прежнему занимает лидирующие позиции.

В качестве основных характеристик конкурирующих открытых систем можно отметить следующие:

Postfix: выросший из IBM Secure Mailer разрабатывается как быстрая и безопасная альтернатива Sendmail. Отличается модульной структурой, простым форматом конфигурационного файла. Благодаря имитации взаимодействия Sendmail с операционной системой миграция на Postfix может быть выполнена сравнительно безболезненно.

Exim: был разработан в 1995 году Филипом Хазелем (Philip Hazel) на базе MTA Smail для почтовой системы Кембриджского университета. Достаточно мощная и гибкая почтовая система. К её преимуществам также часто относят хорошую документированность. Как и Sendmail, имеет монолитную архитектуру, но (по отзывам) работает несколько быстрее.

Qmail: при разработке этого MTA (автор – Даниэль Бернштайн (Daniel J. Bernstein)) основной акцент делался на вопросах безопасности. Имеет модульную структуру. Для решения различных задач запускает процессы от имени разных пользователей, чем достигается максимальный уровень защищённости в случае обнаружения проблем в одном из модулей. Довольно странную лицензию, допускающую распространение только в исходных кодах и сильно осложняющую развитие программы (текущая версия – 1.03 – датируется аж 1998 годом), можно назвать одной из причин, по которым Qmail стремительно теряет популярность.

Существуют и другие MTA (например, Comminigate Pro), имеющие свои достоинства и недостатки. В общем выбирать есть из чего.

Источник

Читайте также:  Усилитель сони xplod 500w настройка
Adblock
detector