 |
|
|
|
Как работает Sendmail? Полезные подробности. Часть 4: Взаимодействие со сторонними программами
Как работает Sendmail? Полезные подробности Часть 4: Взаимодействие со сторонними программами Гуртом і батька добре бити.
Мудрость братского народа Как бы ни был гибок и функционален Sendmail, его возможностей не всегда хватает для решения всего многообразия задач. Но открытость ПО тем и хороша, что позволяет наращивать мощь практически без ограничений. Защиты не бывает много Sendmail, как было показано в предыдущих частях статьи (№ 5, 6, 7 за 2006 г. – http://www.samag.ru/cgi-bin/go.pl?q=articles;n=05.2006;a=01; http://www.samag.ru/cgi-bin/go.pl?q=articles;n=06.2006;a=02; http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2006;a=01), позволяет, используя файл aliases или пользовательские .forward-файлы, перенаправлять входящие сообщения на обработку сторонними программами. Сам механизм достаточно прост: письмо в исходном формате поступает на стандартный вход (stdin) указанной программы или скрипта, который в дальнейшем занимается его обработкой. Несложный пример реализации такого сценария на Python можно найти в статье «Практикум Python: обрабатываем входящую электронную почту» (№2 за 2006 г. – http://www.samag.ru/cgi-bin/go.pl?q=articles;n=02.2006;a=01). Однако здесь скрывается потенциальная проблема безопасности – если у пользователя будет возможность самостоятельно указывать любые программы в качестве обработчиков почты, то всегда остаётся вероятность, что он воспользуется этим для несанкционированного вызова программы, к которой в нормальных условиях у него нет доступа (например, не предоставляется доступ к командной оболочке, но есть возможность вносить изменения в .forward-файл через веб-интерфейс). Конечно, Sendmail снижает до минимума негативные последствия этой возможности, запуская процесс, выполняющий такую обработку, от имени пользователя-владельца .forward-файла. Но нельзя забывать, что в системе могут быть исполняемые файлы, на которые установлен бит suid, что в ряде случаев может привести к печальным последствиям... Для решения этой проблемы Sendmail можно настроить на работу с «ограниченной оболочкой» (restricted shell for sendmail) – smrsh. Особенностью этой оболочки является то, что она позволяет запускать программы только из своего каталога, в системах FreeBSD по умолчанию это /usr/libexec/sm.bin (изменить можно перекомпиляцией утилиты с флагом -DSMRSH_CMDDIR). Как это работает, лучше всего посмотреть на примере (после ключа -c указывается имя выполняемой программы): # pwd
# ls –l
# /usr/libexec/smrsh -c w
# /usr/libexec/smrsh -c who
# /usr/libexec/smrsh -c thetest
Как видите, smrsh позволяет исполнять только те программы, ссылки на которые (или сами двоичные файлы) размещены в /usr/libexec/sm.bin. Это же относится и к скриптам – достаточно указать ссылку на скрипт, делать ссылку на интерпретатор не требуется. При желании вы можете использовать любое имя программы – будет использоваться имя ссылки, а не первоначальное имя «бинарника». Чтобы Sendmail использовал для обработки перенаправлений эту оболочку, а не стандартную sh, добавьте в mc-файл такую строку: FEATURE(smrsh) Любители править cf-файл могут заменить имя программы в строке Mprog, т.е. вместо «Mprog, P=/bin/sh . . . » использовать «Mprog, P=/usr/libexec/smrsh . . . ». Вход только по пропускам Если для всех ваших пользователей предусматривается работа только из вашей подсети (или в крайнем случае существует ограниченный и стабильный список внешних сетей для доступа к почте), то задача ограничения режима ретрансляции почты, чтобы ваш MTA не стал «открытым релеем», решается довольно легко с помощью файла access. Но как только у вас появляются пользователи, которым нужно обеспечить возможность работы с их электронной почтой из любой точки мира, возникает определённая проблема. И наиболее приемлемым её решением будет использование аутентификации. Пожалуй, самой удобной методикой для Sendmail является использование SASL-аутентификации силами пакета SASL-Auth. По умолчанию Sendmail во FreeBSD собирается без поддержки SASL, в чём можно убедиться, подав такую команду: $ sendmail -d0.1 -bv и внимательно изучив строчки «Compiled with» на предмет упоминания про SASL. Чтобы поддержка SASL в Sendmail появилась, нужно его пересобрать. Для этого у вас должны быть исходные коды системы. Последовательность действий такова:
# Флаги SASL для Sendmail SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 # Поддержка порта smtps для sendmail (если планируется) SENDMAIL_CFLAGS+= -D_FER_SMTP_SSL Здесь мы указываем добавлять при компиляции Sendmail данные флаги, а также сообщаем программе make пути к необходимым библиотекам. # cd /usr/src/lib/libsmutil/ # make clean && make depend && make # cd ../libsm # make clean && make depend && make # cd /usr/src/usr.sbin/sendmail # make clean && make depend && make && make install Обязательно убедитесь, что предварительно установили пакет cyrus-sasl (см. пункт 1), иначе получите ошибку об отсутствии нужных библиотек. Кстати, чтобы эти библиотеки не приходилось отыскивать по всему диску, настоятельно рекомендуется ставить всё только из системы портов. Теперь в выводимой информации должно присутствовать упоминание SASLv2: $ sendmail -d0.1 –bv
Это означает, что осталось подкорректировать при необходимости конфигурацию Sendmail, и можно проверять работу системы. Первое, что может потребовать настройки, это список разрешённых методов аутентификации. То, что у вас получилось сразу после перекомпиляции, можно узнать, подключившись с помощью telnet на 25-й порт и введя команду EHLO: $ telnet localhost 25
Третья с конца строка как раз и отображает поддерживаемые механизмы аутентификации. Изменить их список можно с помощью следующих директив: TRUST_AUTH_MECH(`DIGEST-MD5 LOGIN PLAIN")dnl define(`confAUTH_MECHANISMS", `DIGEST-MD5 LOGIN PLAIN")dnl Во второй строке перечисляются поддерживаемые механизмы вообще, в то время как первой директивой мы определяем список «доверенных» механизмов, т.е. тех, при использовании которых будет разрешена пересылка почты (relaying), даже если адрес клиента не помечен в базе access как RELAY или OK. Ребята! Да я же свой! Иногда может возникнуть ситуация, когда ваш сервер, для того, чтобы передать куда-то сообщение, сам должен будет пройти аутентификацию. Например, это вполне обычная ситуация, если ваш MTA работает исключительно через сервер провайдера, а провайдер не желает тратить силы на добавление вашего хоста в список доверенных, настаивая на обязательном прохождении всеми клиентами процедуры проверки подлинности. Для этого существует файл authinfo, который подключается таким образом: FEATURE(`authinfo", `hash -o /etc/mail/authinfo") В указанном файле прописываем параметры аутентификации на нужные серверы в следующем формате: AuthInfo:servak.de "U:" "I:" "P:" "M:LOGIN PLAIN" Здесь servak.de – имя удалённого сервера, которому нужно будет предоставить аутентификационную информацию. В ключе M указываются методы, которые должны при этом использоваться. Не забудьте создать хэш этого файла. LDAP – путь к единению В крупных корпоративных сетях довольно часто используются базы LDAP для хранения информации о пользователях этих сетей. И было бы весьма разумно воспользоваться этим механизмом для хранения некоторой конфигурационной информации вашего почтового сервера. Sendmail поддерживает возможность работы с LDAP-базой, позволяя вам использовать службу каталогов вместо файлов access, aliases и т. д. Правда, так же, как и в случае с SASL, во FreeBSD он собран без поддержки LDAP. Включается эта поддержка аналогично:
# Флаги LDAP для Sendmail SENDMAIL_CFLAGS+= -I/usr/local/include -DLDAPMAP SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lldap -llber Теперь уже знакомая нам команда должна вывести упоминание и про LDAP: # sendmail -d0.1 -bv root | grep LDAP
Кстати говоря, если вы заодно хотите воспользоваться преимуществами самой последней версии Sendmail (дистрибутивная, как правило, отстаёт на один-два минорных номера), то можно не мучиться с перекомпиляцией, а поставить Sendmail из портов сразу с нужным набором функций. Благо, этого добра там хватает: $ make search name=sendmail | grep Port
После перекомпиляции (или установки) Sendmail проверьте в /usr/local/etc/openldap/slapd.conf, подключена ли схема sendmail.schema. Если нет, добавьте строку: include /usr/share/sendmail/cf/sendmail.schema Эта команда подключит схему для Sendmail (где определены допустимые атрибуты записей), что необходимо для правильного заполнения нужных полей. Теперь осталось занести в каталог LDAP необходимые записи (как это сделать, смотрите в документации по LDAP; несколько полезных ссылок приведено в конце статьи) и добавить в mc-файл директивы, указывающие, что следует использовать LDAP: define(`confLDAP_DEFAULT_SPEC", `-h ldap.your.domain.ru -b dc=your,dc=domain,dc=ru") FEATURE(`access_db", `LDAP") define(`ALIAS_FILE", `ldap:") Первая строка задаёт параметры LDAP-сервера, второй мы указываем, что вместо /etc/mail/access следует использовать службу каталогов, третьей строкой аналогично указываем использовать LDAP для определения псевдонимов. Альтернативные LDA Sendmail позволяет подключать практически любую программу в качестве локального агента доставки, естественно, при условии, что эта программа будет «вести себя как LDA» (помните? – «если это выглядит как утка, крякает как утка и ходит как утка, то это – утка»). Благодаря этому у нас есть возможность довольно сильно влиять на то, как почта будет сохраняться. Поэтому не удивительно, что помимо стандартного для FreeBSD mail.local разработано большое число «альтернативных» агентов доставки. Прежде всего вспоминается очень мощная программа procmail, предоставляющая широчайшие возможности по обработке почты, до того как она попадёт в почтовый ящик пользователя. Её порой так активно используют для борьбы со спамом, что письмо в принципе может вообще не попасть к пользователю. Недаром во многих дистрибутивах Linux именно она работает в паре с Sendmail по умолчанию. Чтобы воспользоваться его преимуществами, достаточно подключить этот LDA (директивой MAILER(procmail), соответствующий m4-файл входит в стандартную поставку Sendmail) и указать в mailertable использование этого LDA для нужных доменов: your.domain procmail Второй вариант – включить в mc-файл директиву FEATURE(`local_procmail’), которая даст указание использовать procmail в качестве стандартного LDA (объявленного как local). Далее, если вы хотите просто перейти на использование хранилища формата Maildir вместо стандартного mailbox, то в качестве LDA можно подключить, например, программу maildrop: FEATURE(`local_procmail", `/usr/local/bin/maildrop", `maildrop -d $u") Здесь мы воспользовались той же самой директивой, только вместо пути к procmail указали нужный нам. Кстати, если procmail у вас установлен нестандартно (т.е. не в /usr/local/bin), то и для его подключения потребуется указывать полный путь. Естественно, для полноценной работы с Maildir ваш POP3/IMAP-сервер тоже должен уметь работать с этим форматом, впрочем, это уже совсем другая история… Следующий шаг к совершенству – DBMail Для полного счастья хорошо бы ещё добавить гибкости почтовым ящикам пользователей. Одно из решений – использовать для их хранения реляционную СУБД, что и реализуется проектом DBMail. Подробно о DBMail здесь мы говорить не будем (этот пакет с успехом может применяться не только в связке с Sendmail, но и с другими популярными MTA). Некоторая общая информация представлена во врезке «DBMail». Также обратитесь к статье Евгения Прокопьева «Почтовый сервер на основе реляционной СУБД» (№1 за 2006 г.), где работа DBMail освещена очень детально. Поскольку размещение входящей корреспонденции по почтовым ящикам пользователей не является функцией MTA (как вы помните из первой части статьи, этим занимается агент локальной доставки (LDA)), то с точки зрения Sendmail его логика обработки сообщений совершенно не меняется. Всё что требуется – это зарегистрировать DBMail в качестве LDA и дать указание Sendmail использовать именно его для доставки входящей корреспонденции, как мы это делали для procmail. Первая задача решается одной из следующих директив в mc-файле: MAILER(dbmail) MAILER(dbmail-lmtp) Первая строка подключает DBMail в качестве LDA, работающего обычным образом (по конвейеру (pipe)), вторая – для работы по протоколу LMTP. То есть почта, для обработки которой будет указан соответствующий агент доставки, будет передаваться демону dbmail, который и займётся всем остальным. При необходимости можно использовать и оба агента одновременно. Правда, при установке из портов файл dbmail.m4 нигде не появился, и его либо придётся создать самому, подкорректировав один из имеющихся шаблонов (например, procmail.m4), либо найти готовый (например, здесь: http://www.dbmail.org/dokuwiki/doku.php?id=sendmail_howto). Вторая задача (чтобы Sendmail знал, для какой почты следует использовать тот или иной LDA) – настройка mailtertable для использования этого LDA: your.domain dbmail other.domain dbmail-lmpt:[127.0.0.1] Естественно, вы можете указать использование dbmail только для необходимых доменов. Не забудьте всё пересобрать и перезагрузить процесс sendmail, чтобы изменения вступили в силу. Думаю, можно также безболезненно воспользоваться тем же приёмом, которым мы подключали maildrop (т.е. создав видимость, что наш dbmail – это procmail, и воспользовавшись готовыми шаблонами для этого LDA). Правда, на практике это не испытывал. Расширенные возможности фильтрации Очень широкие возможности для обработки сообщений предоставляют появившиеся в версии 8.11.6 (неофициально – с 8.10) почтовые фильтры, или «мильтеры» (milter, аббревиатура от Mail fILTER). Почтовые фильтры широко применяются для взаимодействия с такими программами, как антивирусы, спам-фильтры и т. д. То есть они, по сути, предоставляют возможность «заворачивать» обрабатываемое сообщение сторонней программе через сетевой или UNIX-сокет. Кстати говоря, использование для взаимодействия сокетов позволяет размещать программу-фильтр на другой машине в сети, что в ряде случаев может быть полезно для централизации обработки или для снижения нагрузки на основной сервер, если фильтрация требует существенных вычислительных ресурсов или создаёт большую нагрузку на дисковую подсистему. Но нельзя забывать и о дополнительных задержках в этом случае, равно как и о безопасности передаваемой по сокету информации. Фильтр позволяет контролировать обработку письма начиная с момента установления соединения с удалённым сервером и до полного его получения. В любой момент обработка может быть прервана с помощью одного из флагов возврата: ACCEPT (принять сообщение), REJECT (отклонить с уведомлением об этом отправителя) или DISCARD (отбросить без каких-либо уведомлений). То есть, скажем, если необходимость отклонить сообщение будет выявлена на ранних стадиях сеанса, например, на основе информации, помещённой в заголовок, то это можно будет сделать до того, как письмо будет принято полностью. Ещё один пример использования такой возможности – приём сообщения (ACCEPT) без проверки всех вложений на вирусы, если в заголовке будет обнаружена строка, информирующая о том, что такая проверка уже выполнялась сервером отправителя (хотя всецело доверять таким заголовкам, конечно же, не стоит). Помимо решения о том, принять или отклонить сообщение, milter позволяет вносить изменения в тему или тело сообщения, добавлять строки в заголовок, и т. д. Благодаря этому можно, например, поместить в заголовок информацию о выполненной антивирусной проверке или оставить пометку, что письмо признано вероятным спамом. Именно так поступают многие антивирусные и антиспамовые пакеты. Условно схема прохождения письма через подключенные фильтры показана на рис. 1. Фильтров может быть сколь угодно много (реальное ограничение накладывается лишь нагрузкой на систему и требованиями к допустимой задержке при обработке сообщений). Порядок применения фильтров определяется порядком их подключения в конфигурационном файле.
Рисунок 1. Схема прохождения сообщений Кстати, о конфигурации... Подключается milter такой директивой: INPUT_MAIL_FILTER(`clmilter", `S=local:/var/run/clamav/clmilter.sock,F=, T=S:4m;R:4m") Первым аргументом передаётся имя фильтра, вторым – строка параметров. Параметра может быть три:
Флаги тайм-аутов
В нашем примере, если clamav-milter не начнёт принимать сообщение от Sendmail в течение четырёх минут или не даст ответ в течение такого же времени, то сообщение будет передано на дальнейшую обработку без фильтрации. Вместо указанной выше директивы можно подключать фильтры и таким образом: MAIL_FILTER(`miltergreylist", `S=local:/var/milter-greylist/milter-greylist.sock,F=, T=S:4m;R:4m")dnl define(`confINPUT_MAIL_FILTERS", `miltergreylist") Здесь процедура подключения фильтра разделена на два этапа – первой директивой мы объявляем milter с указанными параметрами, второй – регистрируем указанный milter как фильтр для обработки сообщений. Если по такой схеме требуется подключить несколько почтовых фильтров, то директива define нужна только одна, в которой через запятую перечисляются все регистрируемые фильтры в нужном порядке. Нужно сказать, что для разработки milter существует прекрасный API, позволяющий довольно быстро создавать фильтры на родном для Sendmail языке C (в списке дополнительной литературы вы найдёте ссылку на пример разработки milter для дублирования исходящей почты на некоторый адрес). Существуют «привязки» к этому API для других языков программирования, например, для Perl (модуль Sendmail::Milter, в коллекции портов – mail/p5-Sendmail-Milter) и Python (интерфейс Python Milter, в Портах – mail/py-milter). Прекрасный пример разработки фильтра на Python рассматривался в статье Романа Сузи «Почтовый фильтр, или Milter = Mail + Filter» (№2 за 2003 г., статью вы можете найти на сайте журнала в разделе «Статьи».). Списки рассылки Электронная почта широко используется в самых различных формах. Конечно, если говорить о ведении групповых дискуссий, то есть и более удобные средства: IRC, службы новостей (NNTP), веб-форумы, наконец. Несмотря на это, списки рассылки по электронной почте до сих пор остаются довольно популярным способом обсуждения тех или иных проблем. Очень многие открытые проекты (например, FreeBSD.org, ALT Linux) используют рассылки для оказания технической поддержки своим пользователям, для обсуждения новых возможностей тестовых версий, для уведомлений об обнаруженных проблемах безопасности… Одной из наиболее известных систем управления списками рассылки является программа Majordomo. Она очень хорошо интегрируется с серверами Sendmail и обладает достаточным набором функций для работы с рассылками. Установка из коллекции портов никаких сложностей не вызывает, за исключением одного небольшого нюанса: начиная с FreeBSD 5.x Perl не является частью системы и должен устанавливаться из портов, т.е. размещается в /usr/local/bin. Однако порт Majordomo по-старинке хотел видеть /usr/bin/perl. Пришлось ставить ссылку (хотя можно, конечно, и Makefile подправить): # ln /usr/local/bin/perl /usr/bin/perl После этого вам нужно будет указать, какой MTA будет использоваться (см. рис. 2; наш выбор, думаю, очевиден). После непродолжительной компиляции мы получим немного нестандартную для FreeBSD схему размещения файлов: «бинарники» и файлы конфигурации будут располагаться в /usr/local/majordomo. Наиболее важны здесь два конфигурационных файла – majordomo.cf, где можно изменить базовые настройки, и aliases.majordomo, содержащий настроенный набор псевдонимов, с помощью которых будет работать Majordomo.
Рисунок 2. Диалог выбора MTA для Majordomo Принцип взаимодействия этого пакета с Sendmail достаточно прост и основан на псевдонимах. Например, сообщение, поступающее на адрес majordomo@your.domain.ru будет перенаправлено программе /usr/local/majordomo/wrapper и обработано в соответствии с настройками списка. Для того чтобы Majordomo начал работать, нужно подключить к Sendmail его файл псевдонимов (хотя можно и просто скопировать нужные строки в /etc/mail/aliases): define(`ALIAS_FILE", `/etc/mail/aliases, /usr/local/majordomo/aliases.majordomo") Всё – Majordomo готов к работе. Отправив письмо с командой «lists» в теле на свой домен на адрес majordomo, вы получите информацию о доступных списках рассылки (по умолчанию там будет test-l и test-l-digest). По образу и подобию вы можете создавать собственные списки, для чего нужно создать пустой файл, соответствующий имени рассылки, в /usr/local/majordomo/lists, а также в aliases.majordomo ввести псевдонимы для самой рассылки, команд, адресов владельцев и т.д. – пример можно посмотреть для того же демо-списка, test-l. Дальнейшее администрирование может выполняться через электронную почту. Например, чтобы поэкспериментировать со списком test-l, первым делом рекомендуется сменить пароль администратора, послав на адрес test-l-request письмо в фразой «passwd test-l test mynewpas», где test-l – имя списка, для которого меняется пароль, test – старый пароль (используется по умолчанию), mynewpas – новый пароль. В случае удачи вы получите письмо с сообщением «Password changed». Впрочем, работа со списками рассылок – это уже другая тема, и здесь не будем вдаваться в подробности. Тем более что к вашим услугам – отличная страница справки, man majordomo. Подводная часть айсберга На этом, пожалуй, и завершим наше знакомство с Sendmail. Естественно, даже в пределах столь объёмного цикла невозможно охватить все аспекты работы этого мощного пакета. Поэтому в заключение я решил привести список ссылок (тоже далеко не полный), по которым можно получить дополнительную информацию. На этом всё! Удачи! Приложение Cyrus SASL Механизм аутентификации SASL (Simple Authentication and Security Layer) используется для реализации безопасной аутентификации в связке с другими интернет-протоколами. Помимо аутентификации, SASL предоставляет механизмы проверки целостности данных. Одной из наиболее популярных реализаций SASL является библиотека Cyrus SASL. Будучи разработанной для нужд Cyrus IMAP Server, она широко используется и для других задач, включая SMTP-аутентификацию. Cyrus SASL поддерживает широкий набор механизмов аутентификации – CRAM-MD5, DIGEST-MD5, Kerberos, GSSAPI (спецификация Kerberos 5). При необходимости может быть разрешена поддержка механизмов «плоской» аутентификации, таких как LOGIN и PLAIN, однако их рекомендуется использовать только при работе по защищённому соединению. Для выполнения аутентификации используется входящий в состав Cyrus SASL демон saslauthd. Он умеет проводить проверку пароля как по собственной базе, так и используя механизмы PAM, LDAP, системный файл паролей /etc/passwd, и т. д. LDAP Lightweight Directory Access Protocol – облегчённый протокол доступа к каталогам – это протокол, призванный обеспечить работу так называемой службы каталогов. Службы каталогов используются для централизованного хранения различной информации, такой как пользовательские учётные записи, адресные книги, различные настройки. Первоначально служба каталогов (определённая в протоколе X.500) была ориентирована на обслуживание почтовых сетей стандарта X.400, разработанного OSI. Для доступа к этой службе использовался протокол DAP, который и послужил основой для разработки более простого и удобного в работе LDAP. Записи, хранящиеся в каталогах LDAP, представлены уникальными именами (distinguished name) и рядом атрибутов, определяемых в так называемых схемах. Структура записей позволяет легко организовать записи в виде дерева. Основным преимуществом LDAP перед «плоскими» файлами или реляционными базами данных является ориентированность на высокую скорость чтения. С учётом очень эффективного кэширования, использование LDAP, помимо централизации информации, что упрощает её сопровождение (включая резервирование), позволяет также снизить задержки при получении информации, если объёмы данных достигают значительных величин. Помимо свободной реализации службы каталогов – OpenLDAP, широко используемой в системах семейства UNIX/Linux, существует ряд других (например, Active Directory, предназначенная для управления сетями Windows). Сам протокол LDAP определён в RFC 1777, RFC 2251 (версия 3). Существует также большое число расширяющих и дополняющих документов. DBMail Программа DBMail, разработка которой осуществляется двумя датскими фирмами – IC&S и NFG, позволяет организовать хранилище пользовательских почтовых ящиков в базе данных общего назначения. Поддерживаются MySQL и PostgreSQL (в версии 2.2 ожидается добавление к этому списку и SQLite). Для небольших почтовых серверов, обслуживающих локальную сеть вашего предприятия, дополнительное звено в цепи «почтового обслуживания» пользователей лишь снизит надёжность и усложнит сопровождение системы, практически ничего не давая взамен. Однако на системах с большим числом пользователей или там, где от почтовой системы требуется максимальная гибкость и возможность реализовать самые различные услуги (например, полнотекстовый поиск по всему почтовому ящику с использованием веб-интерфейса) хранение всех сообщений в БД даёт почти безграничные возможности. Например, DBMail очень легко позволяет задать максимальный размер почтового ящика (в случае использования традиционных хранилищ для этого приходится прибегать к системному механизму установки квот на файловую систему): его нужно просто указать в команде создания нового пользователя или изменения параметров его учётной записи: # dbmail-users -c vasya -m 100M Любая статистика может быть получена напрямую из базы данных, с помощью обычного SQL-запроса. Кроме того, вы можете использовать все преимущества реляционных баз, такие как резервирование, размещение на отдельном сервере, кластеризация (хотя применительно к поддерживаемым в настоящее время СУБД её реализация требует некоторых дополнительных усилий; см., например, статью Андрея Тренина «Создаём кластер для PostgreSQL» (№1 за 2006 г. – http://www.samag.ru/cgi-bin/go.pl?q=articles;n=01.2006;a=07). Помимо Sendmail поддерживаются практически все популярные MTA. Sendmail
Аутентификация
LDAP
Milter API
Прочие
|
Сергей Супрунов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
