Sendmail

Материал из Wiki Open book
Перейти к: навигация, поиск

Содержание

Введение

Sendmail — это наиболее распространенный транспортный агент в UNIX системах. Он поставляется почти со всеми дистрибутивами Linux, в том числе и с CentOS. Sendmail был написан Эриком Оллманом в 1983 году и в дальнейшем дорабатывался различными разработчиками.

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

Очень часто возникаю вопросы по поводу безопасности sendmail. Хочу привести цитату из материалов сайта http://www.intuit.ru.

Программа sendmail используется на многих платформах уже на протяжении нескольких десятков лет. В первые годы ее применения были выявлены практически все черные входы и дыры в программе, которые позволяли хакерам проникать в систему. Например, общеизвестна реакция sendmail на SMTP команды debug и wiz. Получив при анонимном SMTP-сеансе посредством этих команд доступ в систему, через другие программы хакер мог получить права пользователя root . Когда программа sendmail стала популярной, то все черные ходы были закрыты и ошибки в программе были исправлены.

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

Так что было бы неосмотрительно только из-за слухов о неблагонадежности sendmail отказываться от ее преимуществ.

Конфигурационные файлы sendmail

Основной конфигурационный файл программы — sendmail.cf. Обычно он находится в директории /etc/mail. В файле определяются основные параметры и особенности работы sendmail, в том числе и дополнительные конфигурационные файлы, которые тоже обычно находятся в директории /etc/mail.

Кроме файла sendmail.cf в системе может присутствовать файл submit.cf, являющийся конфигурационным файлом агента подачи сообщений.

Какой из перечисленных файлов будет использоваться в качестве конфигурационного (то есть, в каком режиме будет работать программа) зависит от опций, с которыми sendmail запускается:

  • -Ac — запуск в качестве агента подачи почты с использованием конфигурационного файла submit.cf.
  • -Am — запускается в качестве основного почтового сервера с использованием файла sendmail.cf. (Параметр по умолчанию).

Файл submit.cf обычно никогда не редактируется.

Если посмотреть на содержимое файла sendmail.cf, в нем можно найти строки похожие на:

R$* < @ $=w > $* $: $1 < @ $2 . > $3
R$* < @ $=M > $* $: $1 < @ $2 . > $3
R$* < @ $={VirtHost} > $* $: $1 < @ $2 . > $3

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

Конфигурация sendmail при помощи препроцессора m4

Как было сказано в предыдущем разделе, препроцессор m4 облегчает администратору процесс создания и изменения конфигурационных файлов sendmail.cf и submit.cf.

После установки sendmail, конфигурационные макросы будут помещены в директорию /usr/share/sendmail-cf (В разных дистрибутивах эта директория может находиться в различных сетах. Обратитесь к документации к дистрибутиву.). В этой директории вы увидите файл README, где находится полноценная документация по всем макросам. Сами макросы располагаются в поддиректориях

В директории cf находятся шаблоны макросов, которые можно использовать для создания файла sendmail.cf для разных типов UNIX.

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

m4 my.mc > /etc/mail/sendmail.cf

В дистрибутиве CentOS файл-шаблон находится в директории /etc/mail.

Препроцессор m4 имеет очень строгий синтаксис. Любой лишний пробел, неправильное указание скобок ведет к появлению сообщения об ошибке или создание неправильного файла.

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

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

Так же, в файле на языке препроцессора можно использовать инструкцию divert, при помощи которой можно писать комментарии сразу на нескольких строках.

divert(-1)
#
# Copyright (c) 1998-2002 Sendmail, Inc.
# Copyright (c) 1983 Eric P. Allman.
# Copyright (c) 1988, 1993
# The Regents of the University of California.
divert(0)

divert(-1) — очищает буфер макросов от данных, оставшихся от предыдущих попыток. divert(0) — применяется для обозначения начала макроса.

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

include(`../m4/cf.m4')dnl

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

Макрос VERTIONID

Макрос VERSIONID применяется для идентификации версии создаваемого конфигурационного файла. Все, что указывается в качестве параметра, будет без изменений помещено в выходной файл, сразу после символа комментария.

VERSIONID(`My super mail server')dnl

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

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

Макрос OSTYPE

Исторически так сложилось, что в разных версиях UNIX систем принято свое месторасположение и название дополнительных конфигурационных файлов sendmail. Каждый файл можно определить отдельно при помощи директивы define. Но для того, чтобы эти директивы не описывать каждый раз в файле mc, используют макрос OSTYPE.

OSTYPE(linux)dnl

В качестве параметра макроса указывают имя файла без расширения, находящегося в директории /usr/share/sendmail-cf/ostype. В файле определяются параметры по умолчанию для каждого типа UNIX. Ниже показано содержимое файла linux.m4:

VERSIONID(`$Id: linux.m4,v 8.13 2000/09/17 17:30:00 gshapiro Exp $')
define(`confEBINDIR', `/usr/sbin')
ifdef(`PROCMAIL_MAILER_PATH',,
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail'))
FEATURE(local_procmail)

Макрос DOMAIN

Если у Вас есть много почтовых серверов с одинаковыми параметрами, можно создать файл в директории /usr/share/sendmail-cf/domain, в котором эти параметры будут описаны.

Затем при помощи макроса DOMAIN подключить этот файл.

DOMAIN(my-domain)dnl

Например, файл generic.m4 из директории domain:

VERSIONID(`$Id: generic.m4,v 8.15 1999/04/04 00:51:09 ca Exp $')
define(`confFORWARD_PATH',`$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
define(`confMAX_HEADERS_LENGTH', `32768')dnl
FEATURE(`redirect')dnl
FEATURE(`use_cw_file')dnl

Макрос MAILER

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

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

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

MAILER(local)dnl
MAILER(smtp)dnl

На самом деле mailer smtp включает сразу несколько транспортных агентов: smtp, esmtp, dsmtp, smtp8 и relay.

Если при доставке почты в локальные почтовые ящики требуется ее фильтрация, рекомендуется добавить поддержку программы procmail:

MAILER(procmail)dnl

При помощи мейлера fax можно организовать шлюз почта-fax. Правда, в системе должен быть установлен факс сервер hylafax. Мейлер отсылает письма, отправленные по специальному адресу в качестве fax сообщения.

Макрос FEATURE

Макрос применяется для описания различных особенностей почтового сервера. Подавляющее большинство параметров будут определяться при помощи именно этого макроса. Более подробно макрос FEATURE мы будем рассматривать при конфигурации sendmail в других разделах.

Сейчас же мы посмотрим два ключевых макроса FEATURE.

use_cw_file

После определения макроса вы можете пользоваться файлом /etc/mail/local-host-names. Это обыкновенный текстовый файл, в котором по одному на строке вы будете вписывать имена доменов, для которых sendmail должен принимать почту. Например:

# Пример файла locak-host-names
kryukov.biz
test.kryukov.biz
# end of file

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

acces_db

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

FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl

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

В параметрах говориться, что sendmail в своей работе будет использовать бинарную базу данных, расположенную в файле /etc/mail/access.db. Выполненную в виде hash таблицы.

Для ускорения доступа к данным, хранящимся в базе, sendmail разместит ее в оперативной памяти ( -T<TMPF>).

Файл базы является не обязательным (-o optional). Т.е. если файла не будет, sendmail все равно запуститься. Если же убрать параметр –o, то sendmail не будет стартовать если файл access.db не будет создан или не будет доступен на чтение программе.

Файл access.db — это бинарная база данных, которую нельзя редактировать напрямую. Обычно поступают следующим образом: создают текстовый файл, который затем при помощи программы makemap переделывают в бинарную базу данных.

Что из себя представляет hash таблица? Это уникальный ключ поиска и значение, которое выдается по этому ключу.

KEY     VALUE

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

Что можно указывать в качестве ключа? Рассмотрим несколько примеров.

  • IP адрес -- Наример: 92.168.0.1
  • Часть IP адреса -- например: 192.168.0. -- все IP, начинающиеся на 192.168.0.
  • Имена доменов -- например: @kryukov.biz
  • Email -- например: artur@kryukov.biz
  • Имя почтового ящика -- например: artur@
  • Управляющие теги -- например: To:artur@, From:@kryukov.biz, Connect:192.168.0.1

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

  • REJECT -- Письмо не принимается. Клиенту или почтовому серверу, который пытался доставить письмо, выдается стандартное сообщение об ошибке.
  • DISCARD -- То же самое, что и REJECT но письмо будет принято и потеряно. Сообщение об ошибке возвращено не будет.
  • OK -- Пропускает письмо от указанного адресата. Например, вы заблокировали прием писем из домена mail.ru: From:@mail.ru REJECT. Но вы должны принимать письма с адреса user@mail.ru. Для разрешения приема писем от него необходимо добавить строку: From:user@mail.ru OK.
  • Текст -- В качестве ошибки можно использовать любое другое сообщение об ошибке. Для этого его следует явно написать. Например, если вы не хотите принимать письма для почтового ящика list@, и выдавать при этом другое сообщение об ошибке. Можно написать так: 550 mail box list blocked.

  • RELAY -- Один из способов, при помощи которого указывают, кто имеет право на пересылку писем через наш домен — это указание IP адреса машины или сети, с определением параметра RELAY.

Например, необходимо разрешить пересылать всю почту с машины с IP адресом 192.168.0.2: Connect:192.168.0.2 RELAY. Это далеко не лучший способ разрешения пересылки почты. Используйте аутентификацию.

Cуществуют и другие варианты значений, но мы не будем рассматривать их на этом курсе.

Ниже приводится возможный пример текстового файла /etc/mail/access для машины, принимающей почту для домена kryukov.biz.

Connect:localhost.localdomain           RELAY
Connect:localhost                       RELAY
Connect:127.0.0.1                       RELAY
To:artur@kryukov.biz                    OK
To:postmaster@kryukov.biz               OK
To:postmaster@cosmos.kryukov.biz        OK
To:root@kryukov.biz                     OK
To:root@cosmos.kryukov.biz              OK
To:kryukov.biz                          REJECT

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

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

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

Поэтому при помощи базы доступа, мы можем на стадии соединения отказать в приеме письма. Что и сделано у меня в примере. Конечно, придется повозиться и явно описать все почтовые ящики, для которых вы будете принимать почту. Но овчинка стоит выделки.

Обратите внимание на два обязательных ящика, прием почты, для которых вы должны открыть: root и postmaster. На первый ящик по умолчанию отсылаются служебные письма, от программ, работающих на вашем сервере. Postmaster — это стандартный ящик, куда все почтовые сервера пытаются посылать сообщения об ошибках, возникающих в работе системы электронной почты.

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

После того, как вы создадите текстовый файл, его необходимо превратить в бинарную базу данных. Тут возможны два варианта. Первый — это явный вызов программы makemap:

# makemap hash /etc/mail/access < /etc/mail/access

Мы говорим программе, что бы она создала бинарную базу в виде hash таблицы (параметр hash). Результирующий файл должен находиться в директории /etc/mail и называться access.db. При вызове программы, расширение файла можно не указывать. Данные для преобразования передаются на стандартный вход программы из файла /etc/mail/access.

Второй способ. Необходимо перейти в директорию /etc/mail.

# cd /etc/mail

И запустить в ней программу make

# make

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

После изменения файла, sendmail рекомендуется перезапустить:

# service sendmail restart

Порядок описания макросов в файле прероцессора m4

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

  • VERSIONID
  • OSTYPE
  • DOMAIN
  • local macro definitions
  • FEATURE
  • MAILER
  • LOCAL_CONFIG
  • LOCAL_RULE_*
  • LOCAL_RULESETS

Локальные конфигурации, LOCAL_CONFIG и другие, пишутся на языке конфигурационного файла sendmail.cf. Позволяют расширить функционал почтового сервера. Но, к сожалению, этот язык очень сложный и мы его изучать не будем.

Аутентификация пользователя

Наиболее предпочтительным способом разрешения пересылки почты является аутентификация пользователя.

Для разрешения пересылки аутентифицированным пользователям необходимо определить какие механизмы аутентификации считать доверенным. Добавим в файл my.mc следующую строку:

TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl

При помощи макроса TRUST_AUTH_MECH мы определяем доверенные способы аутентификации.

define(`confAUTH_OPTIONS', `A p y')dnl

Оператор define определяет значение переменной confAUTH_OPTIONS. Параметры:

  • А — включает механизм аутентификации.
  • p — начинает «доверять» PLAIN аутентификации только после того как соединение будет зашифровано при помощи TLS.
  • y — запрещает анонимные логины.

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

Еще одна переменная — confAUTH_MECHANISMS, определяет какие механизмы аутентификации будут обрабатываться sendmail.

define(`confAUTH_MECHANISMS', `LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl

Для нормальной работы почтовых клиентов Windows необходимо определить два механизма аутентификации: login и plain. Карма у нас такая, ничего серьезнее перечисленных механизмов они не поддерживают. Но поскольку они не надежны (в смысле безопасности), обязательно включайте TLS/SSL.

В большинстве дистрибутивов кроме самого почтового сервера, слушающего запросы на 25 порту, запускается дополнительный процесс sendmail — MSA (Агент подачи почты). Он предназначен для предварительной проверки и изменений в заголовках письма. По умолчанию он слушает запросы на 587 порту и, естественно, никакой аутентификации не поддерживает. Поэтому мы сначала запретим значения параметров по умолчанию.

FEATURE(`no_default_msa')dnl

Затем, при помощи макроса DAEMON_OPTIONS, определяем используемые сервером порты и некоторые дополнительные параметры.

DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtps, Name=MSA-SSL, M=E')dnl

Основной процесс sendmail (MTA — Mail Transfer Agent) будет слушать запросы на 25 порту (smtp). А агент подачи почты на 465 порту (smtps). Кроме того, параметр M=E говорит, что не будет использоваться команда ETRN, протокола SMTP.

В результате содержимое файла my.mc станет таким:

include(`../m4/cf.m4')
VERSIONID(`My mega server')dnl
OSTYPE(linux)dnl
FEATURE(`use_cw_file')dnl
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`local_procmail',`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`always_add_domain')dnl
define(`confAUTH_OPTIONS', `A p y')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtps, Name=MSA-SSL, M=E')dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl

Пока все прекрасно, но кроме включения собственно механизма аутентификации, потребуется настроить дополнительную программу, позволяющую sendmail осуществлять аутентификацию, и TLS.

SASL

Sendmail сам не производит аутентификацию пользователей, для этого он пользуется SASL механизмом. В системе должна быть установлена библиотека, реализующая этот механизм. В подавляющем большинстве дистрибутивов используется пакет Cyrus-sasl, с которым поставляются необходимые библиотеки.

У этого способа есть один неприятный момент — Вам прийдется заносить всех пользователей, которые должны получать почту, в специальную базу данных. (Поправьте меня, я так и не понял как в Slackware заставить брать информацию о пользователях из /etc/passwd) Делается это следующим образом:


---Поправлено---- Для того что бы в slackware пароли брались из shadow без создания баз :

в каталоге /etc/sasl2 создаем файл Sendmail.conf в него вписываем:
 
 
     pwcheck_method: saslauthd
     mech_list: plain login

создаем два линка (я просто не проверял откуда конкретно читается Sendmail.conf )

     ln -sf /etc/sasl2/Sendmail.conf /etc/Sendmail.conf
     ln -sf /etc/sasl2/Sendmail.conf /usr/lib/sasl2/Sendmail.conf

пересобираем пакет cyrus-sasl с доп настройками в файле cyrus-sasl.SlackBuild добавляем опции компиляции для того что бы sasl понимал не шифрованые пароли, керберос нам не нужен!

      --enable-plain \
      --disable-krb4 \

запускать демона /usr/sbin/saslauthd -a shadow


Конец поправки =)



# saslpasswd2 -a sendmail -u kryukov.ru artur
#

Программа saslpasswd2 позволяет управлять этой базой. В приведенном примере мы добавили пользователя artur из домена kryukov.ru (-u kryukov.ru). Пользоваться этой информацией сможет программа sendmail (-f sendmail).

Для смены пароля пользователя программа вызывается аналогичным образом. Для удаления пользователя добавьте параметр -d.

Программа sasldblistusers2 позволяет посмотреть какие пользователи находятся в базе данных.

# sasldblistusers2
artur@kryukov.ru: userPassword
artur@kryukov.ru: cmusaslsecretOTP
#
Внимание! При конфигурации почтового клиента в разделе отправление почты в качестве логина пользователя необходимо указывать логин и домен. Для приведенного выше примера это будет выглядеть так: artur@kryukov.ru.

TLS

Последнее, что осталось сделать — включить TLS. Это делается не сложно, достаточно добавить четыре параметра в файл my.mc и создать все необходимые ключи и сертификаты.

Что бы не генерировать все снова, возьмем ключи и сертификаты, которые мы использовали при конфигурации сервера OpenVPN (см. OpenVPN). Или сгенерируйте их самостоятельно, подробности смотрите тут: Создание ключей и сертификатов.

В my.mc добавляем следующие строки:

define(`confCACERT_PATH', `/etc/openvpn/keys/')dnl
define(`confCACERT', `/etc/openvpn/keys/ca.crt')dnl
define(`confSERVER_CERT', `/etc/openvpn/keys/kryukov.ru.crt')dnl
define(`confSERVER_KEY', `/etc/openvpn/keys/kryukov.ru.key')dnl

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

Безопасность

Конфигурационные параметры

Подключение антивирусов

Подключение антивируса ClamAV описано на странице, посвященной настройке антивируса.

Перевод документации

Sendmail:README

Источник — «http://kryukov.biz/wiki/Sendmail»
Инструменты
    
Личные инструменты