Нет такого свода законов,
который отвечал бы всем потребностям.
Преступление в одном обществе
может казаться требованием морали в другом.
Френк Херберт "Дом Глав Дюны"
Локальная пересылка почты не ограничивается простым присоединением входящего сообщения к почтовому ящику получателя. Обычно локальные MTA поддерживают работу с псевдонимами (aliasing). Кроме того, сообщение, которое по каким-то причинам не может быть доставлено, должно возвращаться отправителю с добавленным сообщением об ошибке.
При удаленной пересылке почты используемая транспортная программа обычно определяется природой канала связи. При использовании каналов TCP/IP обычно применяется протокол SMTP. Выступая в роли протокола "сервер-сервер", SMTP требует дополнительного протокола, типа POP3, для локального сбора и обработки сообщений и их доставки конкретным пользователям. Протокол SMTP проектировался с расчетом на то, чтобы почта доставлялась прямо на компьютер получателя, а процесс пересылки согласовывался с демоном SMTP, работающим на удаленном конце. Протокол SMTP наделяется дополнительными возможностями благодаря протоколу ESMTP (Extended Simple Mail Transport Protocol). К таким возможностям относятся, в частности, 8-битовое кодирование MIME без применения типа base64 и возможность получения сервером сведений о размере сообщения (при использовании SMTP единственным способом отказа от приема слишком больших сообщений было получение их целиком и последующее уничтожение, что, естественно, создавало дополнительную нагрузку на сеть).
В обязанности MTA также входит и маршрутизация почты (так, письмо, отправляемое пользователю той же локальной системы, передается непосредственно локальному MDA - Mail Delivery Agent).
В задачи MDA входит обработка приходящих сообщений. Так sendmail, получив сообщение, вызывает MDA для его передачи из очереди sendmail в очередь MUA. Чаще всего эту роль выполняют /bin/mail и procmail.
В интернете выполнение процедуры маршрутизации зависит от конфигурации узла назначения. По умолчанию сначала определяется узел, на который должно быть доставлено сообщение, после чего сообщение передается на узел назначения напрямую. В большинстве сетей с подключением к Интернету вся входящая почта обычно направляется на специализированный, наиболее доступный почтовый сервер, способный поддерживать большую нагрузку. Этот почтовый сервер осуществляет дальнейшую пересылку почты на локальные сетевые узлы. Чтобы объявить о предоставлении такого рода услуг, сетевой узел должен обладать соответствующей ему записью MX в базе данных DNS. Запись MX означает Mail Exchanger (сервер обмена почтовыми сообщениями) и указывает на то, что данный сетевой узел выполняет функции почтового сервера домена.
Каждая запись MX содержит параметр приоритета. Это положительное целое число. Если почтовое сообщение, адресованное некоторому сетевому узлу может быть доставлено к месту назначения при помощи одного из нескольких почтовых серверов, почтовый транспортный агент будет пытаться переслать сообщение на сервер MX, у которого этот параметр имеет наименьшее значение, и только в случае неудачи сообщение будет передано на сервер с более высоким значением параметра приоритета. Если локальный узел сам является почтовым сервером для получателя сообщения, он не имеет права пересылать почтовое сообщение на серверы MX c большим значением приоритета, чем его собственный. Таким образом удается избежать передачи почтовых сообщений по замкнутому кругу. Если для домена не осталось ни одной подходящей записи MX или такой записи вообще не существует, транспортный агент проверяет, не связан ли с узлом IP-адрес и пытается доставить почту прямо на узел.
Допустим, в организации VasiyaPupkin, вся почта обрабатывается компьютером mail. В базу данных
DNS включается записи MX следующего вида:
boss.vasiyapupkin.ru. IN MX 5 mail.vasiyapupkin.ru.
Это означает, что компьютер mail.vasiyapupkin.ru является почтовым сервером для домена boss.vasiyapupkin.ru со степенью приоритета 5. Узел, собирающийся передать сообщение для joe@boss.vasiyapupkin.ru, сначала обратится к DNS и обнаружит запись MX со ссылкой на mail. Если в базе данных DNS не будет записей MX, относящихся к этому же домену и с приоритетом ниже 5, сообщение будет передано mail, который в дальнейшем перешлет его на boss.
Это только приблизительное описание принципа работы MX, более подробная информация о маршрутизации почты изложена в RFC-821, RFC-974, RFC-1123.
Многие администраторы сравнивают эту программу с "ужасом, летящим на крыльях ночи". Настройка sendmail очень сложна, но как отвечал критикам автор sendmail Эрик Олмен, это потому, что мир в целом далеко не прост. Программа sendmail в состоянии сделать с почтой буквально все, если только вы сумеете объяснить, чего именно от нее хотите. Говорят, если никогда не редактировали вручную файл sendmail.cf, вас нельзя назвать настоящим администратором системы UNIX. Так же говорят, что только сумасшедший возьмется за редактирование этого файла еще раз. sendmail - это невероятно мощная программа, однако для многих людей она является слишком сложной и непонятной. Ясно, что программный продукт, руководство, по использованию которого содержит 1050 страниц текста, способен отпугнуть даже самых бывалых компьютерщиков. Что касается последних версий, sendmail настраивать их стало легче благодаря большим набором макросов M4 и возможности использовать более или менее понятные имена опций в конфигурационном файле.
Рассмотрим процесс компиляции и установки sendmail. Исходные тексты можно загрузить с анонимного FTP-сервера ftp.sendmail.org. Или же здесь можно взять RPM той версии исходников, которую использовал я. Процесс компиляции довольно прост, так дистрибутив напрямую поддерживает Linux. Поэтому, не теряя времени, стоит рассмотреть процесс прикручивания к sendmail аутентификации.
Sendmail 8.10/8.11 поддерживают SMTP AUTH, как это описано в RFC 2554, которая базируется на SASL.
Следует отметить, что не все е-маил клиенты в полной мере поддерживают SMTP AUTH, поэтому здесь
мы рассмотрим только Outlook Express и The Bat, как наиболее популярные в данный момент. Таблицу
совместимости для различных клиентов можно посмотреть на официальном сайте sendmail:
http://www.sendmail.org/~ca/email/mel/SASL_ClientRef.html
Для организации аутентификации в sendmail нам потребуется библиотека Cyrus SASL, RPM которой можно
взять здесь.
Безусловно, версии исходников можно брать и напрямую
с сайта разработчика:
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail
После установки этой RPM в систему, исходные коды Cyrus SASL, а точнее их
архив, следует искать в /usr/src/RPM.
Распаковываем полученный архив cyrus-sasl-1.5.27.tar.bz2. Затем следует предпринять несколько следующих шагов с правами root, для конфигурации и компиляции библиотеки, с последующей установкой ее в систему:
cd cyrus-sasl-1.5.27/
./configure --prefix=/usr --enable-login
make
make install
Многие советуют отключить в SASL такие методы, как PLAIN и LOGIN, но к сожалению такие клиенты, как Outlook Express, не поддерживают другие, поэтому если большая часть ваших пользователей используют этот почтовый клиент или схожий с ним, нужно при конфигурировании SASL включить метод LOGIN (--enable-login), что и было продемонстрировано выше. Для уверенности, что все идет правильно проверьте наличие установленных библиотек в каталоге /usr/lib и include файлов (с расширением h) в каталоге /usr/include.
Теперь сделаем конфигурационный файл для Sendmail, этот файл будет использоваться SASL, для проведения аутентификации в Sendmail. Для этого необходимо создать файл /usr/lib/sasl/Sendmail.conf и добавить в него следующую информацию:
pwcheck_method: sasldb
Здесь же, для особо интересующихся можно прикрутить и mysql, т.е. информация с именами и паролями пользователей будет вестись в базе данных. На следующем шаге нужно организовать базу для всех пользователей, которые будут наделены полномочиями отсылать почту, т.е. использовать ваш почтовый сервер как relay. Так как мы используем SASL, то в нем есть две программы, которые и занимаются решением этой проблемы. Первая программа создает базу данных с вашими пользователями:
saslpasswd -a sendmail newuser
password:<пароль для newuser>
Вышепоказанные действия нужно проделать для всех пользователей вашей системы, которые будут иметь возможность отсылать сообщения.
Вторая программа называется: sasldblistusers
Служит она для отображения базы с пользователями. Запустив ее можно увидеть нечто подобное:
user: newuser realm: yourhost.youdomain mech: CRAM-MD5
user: newuser realm: yourhost.youdomain mech: DIGEST-MD5
user: newuser realm: yourhost.youdomain mech: PLAIN
user: newuser realm: yourhost.youdomain mech: LOGIN
Эта информация означает, что аутентификация для пользователя newuser может быть проведена следующими методами: CRAM-MD5, DIGEST-MD5, PLAIN, LOGIN.
Теперь перейдем к настройке Sendmail. Для начала следует проверить, не скомпилирована ли ваша версия Sendmail с поддержкой SASL?
sendmail -d0.1 -bv root | grep SASL
Если в результате этой команды вы увидите слово SASL, то Sendmail снабжен поддержкой SASL, если же нет, то вам придется собрать дистрибутив вручную.
Собираем Sendmail:
скачиваем (www.sendmail.org) нужную, или последнюю версию Sendmail
tar -xzf senmail-x.xx.xx.tar.gz
cd sendmail-x.xx.xx/
Теперь для того чтобы прикрутить поддержку SASL, нужно сделать следующее:
зайти в sendmail-x.xx.x/devtools/Site и создать там файл site.config.m4 в котором нужно написать
следующее:
APPENDDEF('confENVDEF', '-DSASL')
APPENDDEF('conf_sendmail_LIBS', '-lsasl')
APPENDDEF('confLIBDIRS', '-L/usr/lib/')
APPENDDEF('confINCDIRS', '-I/usr/include/')
Конечно, подключить поддержку SASL в ваш sendmail можно и другим способом, к примеру, для себя я делал несколько иначе, но результат остается прежним. Затем возвращаемся в каталог sendmail-x.xx.xx/ и запускаем следующий скрипт:
./Build
./Build install
Обычно sendmail настраивается на работу в качестве демона. Демон представляет собой программу, работающую в фоновом режиме и не имеющую доступа к терминалу. Будучи запущенным в качестве демона, sendmail прослушивает 25 порт (что в принципе не обязательно, так как можно настроить на любой другой порт, это нужно, например, для организации защищенных соединений). Командная строка запуска sendmail выглядит примерно так:
/usr/sbin/sendmail -bd -q30m
Обычно эта команда помещается в сценарий загрузки (например, в каталоге /etc/rc.d/init.d/sendmail).
#Start daemons.
echo -n "Staring sendmail: "
daemon sendmail -bd -q30m
echo
touch /var/lock/subsys/sendmail
;;
В приведенном примере опция -bd указывает, что sendmail должен запуститься в режиме демона, а опция -q30m заставляет проверять и обрабатывать очередь писем каждые тридцать минут.
После этого, если вы дадите следующую команду:
sendmail -d0.1 -bv root | grep SASL
Вы должны увидеть среди прочей информации, уже знакомое нам слово SASL.
Теперь собственно приступим к конфигурации самого Sendmail'а.
Программа sendmail имеет возможность использовать препроцессор m4, что упрощает создание
конфигурационного файла, содержащего выбранные вами возможности. В поставку sendmail входит
множество образцов таких файлов. Обычно такой исходный файл имеет расширение .mc, но оно не
является обязательным. Минимальный файл для системы Linux выглядит так:
OSTYPE(linux)dnl
MAILER(local)dnl
Впишем в свой файл sendmail.mc, следующие строчки:
TRUST_AUTH_MECH('GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl
define('confAUTH_MECHANISMS', 'GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl
define('confDEF_AUTH_INFO', '/etc/mail/auth/auth-info')dnl
FEATURE('no_default_msa')dnl turn off default entry for MSA
DAEMON_OPTIONS('Port=25, Name=MSA, M=E')dnl
Если вместо M=E в конфигурации поставить M=A, то Sendmail начнет требовать авторизацию при любой попытке послать через него почту. Если включить эту опцию, то не один сервер не сможет отправить вам почту, так как не сможет авторизироваться у вас!
Теперь соберем конфигурационный файл Sendmail'а используя следующую команду:
m4 sendmail.mc>sendmail.cf
Здесь m4 - вызов препроцессора m4, sendmail.mc - входной .mc фай, > sendmail.cf - указывает, что вывод должен быть помещен в файл sendmail.cf.
Теперь при использовании для генерации конфигурационного файла препроцессора m4 в файле будут находиться только заказанные вами возможности и не будет ничего лишнего. Кроме того, возможно добавление своих макросов, тем самым можно расширять функциональные возможности sendmail.
Скопируем полученный файл туда, где Sendmail его берёт, для примера это может быть либо
/etc/mail либо /etc:
cp sendmail.cf /etc/mail/sendmail.cf
Проверим насколько правильно мы настроили sendmail:
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
220 local.sendmail.ORG ESMTP Sendmail 8.10.0/8.10.0;
Thu, 9 Sep 1999 10:48:44 -0700 (PDT)
ehlo localhost
250-local.sendmail.ORG Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250 HELP
quit
Теперь можно в хидеры письма вписать информацию об аутентификации. В /etc/sendmail.cf поищите следующие строчки:
######################### # Format of headers # #########################
К примеру можно вписать следующее:
$.$?{auth_type}(authenticated with ${auth_type} from ${auth_author}$.)
Тогда в заголовке письма будет содержаться следующая информация:
(authenticated with CRAM-MD5 from newuser)
Если все сконфигурировано правильно, в том числе и ваш DNS, то в клиенте в качестве логина и пароля следует задать информацию вида:
login: newuser
password: <пароль для newuser>
Если же в конфигурации DNS имеются ошибки, то следует передать эту информацию так:
login: newuser@yourhost
password: <пароль для newuser>
Вот некоторые из них:
RFC-822 Standard of the format of ARPA Internet text messages. (Стандарт форматирования текстовых
сообщений в сети ARPA Internet). D. Crocker. Описание формата сообщений электронной почты,
используемого в современных компьютерных сетях. Несмотря на то, что многие слышали о существовании
и предназначении этого документа, мало кто прочитал его от начала до конца. Дополнения к этому RFC
содержатся в RFC-1123, RFC-1138, RFC-1148, RFC-1327 and RFC-2156.
RFC-0821 Simple Mail Transfer Protocol (Простой протокол передачи почты, SMTP). J. Postel.
Спецификация SMTP - транспортного протокола, предназначенного для передачи почты через канал TCP/IP.
RFC-974 Mail routing and domain system (Маршрутизация почты и система доменов). C. Partridge.
Этот документ описывает маршрутизацию почты в Internet. В нем содержится подробное описание всего,
что связано с записями MX.
RFC-819 Domain Naming. Соглашение для пользовательских приложений Internet.
RFC-976 UUCP Mail Interchange Format Standard Определяет протокол UUCP.
RFC-1123 Requirements for Internet Hosts - Application and Support. Расширенные и обновленные
версии RFC-822 (в основном используемые для устранения неоднозначностей).
RFC-1327 Maping between X.400 (1988)/ISO 10021 and RFC-822 Обновление RFC-822.
RFC-1521
RFC-1522 MIME ( Multipurpose Internet Mail Extensions) parts 1 and 2. Расширение формата
сообщений, определенного в RFC-822.
RFC-1651 SMTP Service Extensions. Описание ESMTP.
RFC-1652 SMTP Service Extensions for 8-bit MIME Transport.
RFC-1653 MTP Service Extensions for Message.
RFC-1869 SMTP Service Extensions. Замена для RFC-1651.
RFC-1870 SMTP Service Extensions for Message Size Declaration. Замена для RFC-1653.
RFC-1891 SMTP Service Extension for Delivery Status Notifications.
RFC-1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.
RFC-1893 Enhanced Mail System Status Codes.
RFC-1894 An Extensible Message Format for Delivery Status Notifications.
RFC-2045-2049 Multipurpose Internet Mail Extensions (MIME) parts 1 - 5. Замена для RFC-1521 and RFC-1522.
P.S. На данном этапе развития ведется работа над следующей частью документа, так как самая интересная часть осталась за кадром, сего опуса. Попрошу набраться немного терпения и немного подождать.