Протокол SMTP

Команда RCPT

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

RCPT forward-path

Аргумент forward-path определяет, куда направляется электронная почта. Как правило, здесь указывается полный адрес электронной почты, но может также указываться и имя пользователя локального сервера SMTP. Рассмотрим для примера следующую команду:

RCPT TO: haley

С помощью этой команды указывается, что сообщение должно быть направлено пользователю haley на сервер SMTP, который обрабатывает сообщения. Таким же образом можно посылать сообщения и пользователям других компьютеров, которые не являются пользователями сервера SMTP, куда направлено сообщение. Рассмотрим, например, следующую команду:

RCPT TO: riley@meshach.smallorg.org

Команда, направленная серверу SMTP с именем shardrach.smallorg.org, вынуждает принять решение о доставке сообщения именно этот сервер. Так как пользователь не зарегистрирован на локальном сервере shardrach, то серверу придется определить, что делать с сообщением дальше. В этом случае возможны три варианта действий хоста shardrach. Давайте остановимся на них подробнее.

На начальной стадии развития сети Internet практиковалась пересылка сообщений электронной почты вслепую между компьютерами по всему миру, в которых использовался исходный алгоритм передачи почтовых сообщений. К сожалению, такая практика привела к появлению спамеров. Спамерами называют людей, которые посылают огромное количество электронной почты по сети Internet либо с целью наживы (реклама, объявления и т.п.), либо просто для развлечения; при этом их сообщения, как правило, не несут смысловой нагрузки. Довольно часто они используют серверы SMTP, которые вслепую пересылают почтовые сообщения, что помогает скрыть истинного отправителя. Для борьбы со спамерами администраторы почтовых систем либо полностью отключают возможности пересылки почты, либо ограничивают пересылку таким образом, чтобы она осуществлялась только хостам своего домена. Многие Internet-провайдеры разрешают своим клиентам пересылать почту через свои почтовые серверы, но запрещают это делать компьютерам извне.

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

Команда DATA

Эта команда является основной в протоколе SMTP. После обработки команд MAIL и RCPT команда DATA используется для передачи информационной части сообщения. Формат команды DATA следующий:

DATA

Все, что следует за этой командой, интерпретируется как сообщение для передачи. Сервер SMTP, как правило, дополняет заголовок сообщения меткой времени и информацией об обратном маршруте return-path. Программа-клиент обозначает конец сообщения посредством передачи строки с одной точкой. Формат этой строки следующий:

<CR><LF>.<CR><LF>

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

При разработке формата реальных сообщений, посылаемых с помощью команды DATA, была проделана огромная работа. Технически теперь просто невозможно отправить сообщение неправильно, так как метод отправки был стандартизирован (см. раздел "Форматы сообщений"). Таким образом, любая комбинация символов кода ASCII будет сразу же передана получателям сообщения. В листинге 5.2 приведен пример сеанса передачи короткого почтового сообщения для локального пользователя сервера SMTP.

1 [rich@shadrach rich]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Wed, 25 Aug 1999 19:34:02 -050
6 HELO localhost
7 250 shadrach.smallorg.org Hello localhost[127.0.0.1], pleased to meet you
8 MAIL FROM:rich@localhost
9 250 <rich@localhost>... Sender ok
10 RCPT TO:rich
11 250 <rich>... Recipient ok
12 DATA
13 354 Enter mail, end with "." on a line by itself
14 This is a short, but sweet, mail message.
15 .
16 250 QAA01619 Message accepted for delivery
17 QUIT
18 221 shadrach.smallorg.org closing connection
19 Connection closed by foreign host.
20 You have mail in /var/spool/mail/rich
21 [rich@shadrach rich]$ mail
22 Mail version 8.1 6/6/93. Type ? for help.
23 "/var/spool/mail/ricn": 1 message 1 new
24 >N 1 rich@shadrach.smallor Wed Aug 25 19:34 11/409
25 1
26 Message 1:
27 From rich@shadrach.smallorg.org Wed Aug 25 19:34:46 1999
28 Date: Wed, 25 Aug 1999 19:34:24 -0500
29 From; rich@shadrach.smallorg.org
30
31 This is a short, but sweet, mail message.
32
33 x
34 [rich@shadrach rich]$

Итак, в листинге 5.2 представлен типичный обмен сообщениями между двумя хостами по протоколу SMTP. В строке 12 клиент водит команду DATA, а в строке 13 показан ответ, полученный от сервера SMTP. Строки 14 и 15 отображают текстовое сообщение, посланное клиентом. В строке 15 вводится точка, сигнализирующая серверу о конце сообщения. Далее, в строках 20–33 сервер SMTP пересылает сообщение в локальный почтовый ящик пользователя в том же виде в каком он принял его. Заметьте также, что в строках 28 и 29 SMTP-сервер в текст почтового сообщения добавил метку времени и обратный маршрут.

Для стандартизации формата сообщений электронной почты в сети Internet была проделана огромная работа. Ее результатом явилось создание документа RFC 822, который описывает формат электронных текстовых сообщений. Более подробно о форматах сообщений мы поговорим в разделе "Форматы сообщений".

Команда SEND

Команда SEND используется для передачи почтовых сообщений непосредственно на терминал зарегистрированного пользователя системы. Эта команда выполняется только в том случае, когда пользователь находится в системе, и обычно представляет собой всплывающее сообщение, подобно команде write в ОС UNIX. У этой команды имеется серьезный недостаток: с ее помощью внешний пользователь может легко определить, кто в данный момент находится в системе. Эта "возможность" давно и активно эксплуатируется хакерами для получения идентификаторов пользователя в сети Internet у ничего не подозревающих жертв, находящихся в системе. Из-за угрозы безопасности в настоящее время большинство программных пакетов для работы с SMTP уже не содержат эту команду.

Команда SOML

Команда SOML обозначает SEND или MAIL. Если получатели сообщения подключены к системе, то она работает как команда SEND. В противном случае она ведет себя, как команда MAIL, и пересылает сообщение в почтовый ящик получателя. Уязвимость этой команды привела к тому, что теперь она также нечасто включается в новые версии программных пакетов для работы с SMTP.

Команда SAML

Команда SAML обозначает SEND и MAIL. Она передает сообщение на терминал активного пользователя и одновременно кладет это сообщение в его почтовый ящик. И в этом случае отрицательные "возможности" команды привели к тому, что она была признана небезопасной и в настоящее время не поддерживается в SMTP.

Команда RSET

Команда RSET — сокращение от reset (англ. сброс — Прим. пер.). Если клиент запутался в ответах, получаемых от сервера, или решил, что соединение потеряно, он может послать команду RSET и вернуть сеанс к его начальной точке — выполнению команды HELO. При этом все ранее посланные команды — MAIL, RCPT и DATA будут аннулированы. Очень часто к этой команде прибегают в качестве "последнего средства", когда клиент либо потерял последовательность команд, либо получил неожиданный ответ от сервера.

Команда VRFY

Команда VRFY является сокращением от verify (англ. проверить — Прим. пер.). Ее можно использовать для определения возможности доставки сервером почты определенному получателю перед выполнением команды RCPT. Формат этой команды следующий:

VRFY username

По принятии данной команды сервер SMTP определяет, имеется ли у него на локальном сервере пользователь с заданным именем. Если такой пользователь найден, то сервер вернет ответ с полным почтовым адресом пользователя. Если такого пользователя нет на локальном сервере, то SMTP-сервер может либо вернуть негативный ответ клиенту, либо указать, что он будет пересылать все сообщения удаленному пользователю. Это зависит от того, будет ли сервер SMTP пересылать сообщения удаленному клиенту.

Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты. Как администратор почтовой системы вы, можете проверить работоспособность адресов электронной почты двумя путями. Во-первых, с помощью команды DNS host, которая позволяет определить правильность доменного имени и наличие почтового сервера, обслуживающего домен. И во-вторых, можно зайти с помощью telnet на порт 25 почтового сервера и затем задать команду VRFY, которая определит правильность имени пользователя. В листинге 5.3 показан пример использования команды VRFY для проверки имен пользователей.

1 [riley@shadrach riley]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Thu, 26 Aug 1999 19:20:16 -050
6 HELO localhost
7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you
8 VRFY rich
9 250 <rich@shadrach.smallorg.org>
10 VRFY prez@mechach.smallorg.org
11 252 <prez@mechach.smallorg.org>
12 VRFY jessica
13 550 jessica... User unknown
14 QUIT
15 221 shadrach.smallorg.org closing connection
16 Connection closed by -foreign host.
17 [riley@shadrach riley]$

В строках 8–13 представлены результаты выполнения команды VRFY. В строке 8 делается попытка выполнить VRFY для локального пользователя rich. Ответ SMTP-сервера в строке 9 подтверждает, что пользователь с таким именем имеется в системе, и клиенту возвращается его полный адрес электронной почты. В строке 10 показан еще один вариант задания команды VRFY. Здесь клиент пытается выполнить команду VRFY для пользователя на удаленном компьютере. Ответ, полученный в строке 11 от системы shadrach, отличается от результата, полученного в строке 9. В разделе "Ответы сервера" значения кодов, возвращаемых сервером, обсуждаются более детально. В нашем случае отметим, что система shadrach уведомляет клиента о том, что почта будет пересылаться пользователю prez на удаленном сервере meshach.smallorg.org. Строка 12 отображает попытку проверить несуществующее имя в системе meshach. Ответ SMTP-сервера в строке 13 в пояснениях не нуждается.

Команда EXPN

Команда EXPN является сокращением от expand (англ. расширить — Прим. пер.). С ее помощью сервер SMTP может запрашивать списки рассылки и почтовые псевдонимы. Списки рассылки весьма эффективны, когда с одного адреса требуется послать большое количество одинаковых сообщений группам пользователей. Более глубоко вопросы, связанные с этим аспектом использования электронной почты, рассмотрены в лекции 18, . Кроме того, при работе с электронной почтой можно использовать в качестве адресов почтовые псевдонимы. Более подробно о них читайте в лекции 17. Формат команды EXPN следующий:

EXPN mail-list,

где mail-list — имя списка рассылки или почтовый псевдоним. Сервер SMTP при обработке данной команды либо возвращает код ошибки (если у клиента нет прав на просмотр списков), либо выводит список рассылки с адресами электронной почты один на строку.

Команда HELP

Команда HELP используется для вывода на экран списка команд, которые воспринимает сервер SMTP. Программные пакеты SMTP в соответствии с RFC 821обрабатывют основные команды, приведенные выше (кроме представляющих угрозу безопасности). Различия в реализациях SMTP заметны лишь в дополнительных функциях SMTP. В листинге 5.4 представлен результат выполнения команды HELP, заданной серверу на базе ОС Linux с SMTP-пакетом sendmail версии 8.9.3.

1 [katie@shadrach katie]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 228 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Thu, 26 Aug 1999 19:50:57 -050
6 HELO localhost
7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you
8 HELP
9 214-This is Sendmail version 8.9.3
10 214-Topics;
11 214- HELO EHLO MAIL RCPT DATA
12 214- RSET NOOP QUIT HELP VRFY
13 214- EXPN VERB ETRN DSN
14 214-For more info use "HELP <topic>".
15 214-To report bugs in the implementation send email to
16 214- Sendmail-bugs@Sendniail.org.
17 214-For local information send email to Postmaster at your site.
18 214 End Of HELP info
19 HELP RCPT
20 214-RCPT TO: <recipient> [ <parameters> ]
21 214- Specifies the recipient. Can be used any number of times.
22 214- Parameters are ESMTP extensions. See "HELP DSN" for details.
23 214 End of HELP info
24 HELP VRFY
25 214-VRFY <recipient>
26 214- Verify an address. If you want to see what it aliases
27 214- to, use EXPN instead.
28 214 End of HELP info
29 QUIT
30 221 shadrach.smallorg.org closing connection
31 Connection closed by foreign host.
32 [katie@shadrach katie]$

Как видно из листинга 5.4, доступны два уровня помощи. Получив просто команду HELP, сервер SMTP выдаст краткий список всех команд SMTP. Если же задать команду HELP с аргументом, в качестве которого присутствует другая SMTP-команда, то можно получить более детальное описание этой команды, включая ее синтаксис.

Команда NOOP

Команда NOOP — сокращение от no operation (англ. нет операции — Прим. пер.). Эта команда не оказывает никакого воздействия на SMTP-сервер, за исключением того, что сервер возвращает на нее позитивный код ответа. Она используется при тестировании соединения без пересылки сообщения.

Команда QUIT

Команда QUIT делает именно то, что она и означает (англ. выйти — Прим. пер.), т.е. сообщает SMTP-серверу о том, что клиентский компьютер закончил текущий сеанс и хочет закрыть соединение. Сервер SMTP должен ответить на эту команду, а затем инициировать и закрыть TCP-соединение. Если сервер принимает команду QUIT в процессе передачи почты, то все переданные в течение сеанса данные должны быть уничтожены и не поступят получателю.

Команда TURN

В целях безопасности команда TURN пока не включена в реализации SMTP-серверов. Хотя, согласно RFC 821, она входит в стандартный набор SMTP-команд, к сожалению, хакеры использовали ее совсем для других целей (как и много других хороших идей). Идея применения команды TURN была несколько модифицирована в документах RFC, описывающих расширения протокола SMTP. Более подробно эта команда рассматривается в разделе "Расширения SMTP", где описана ее расширенная версия — команда ETRN.

Смысл использования команды TURN заключается в организации двустороннего обмена почтовыми сообщениями между двумя компьютерами по имеющемуся TCP-соединению. Обычно протоколом SMTP предусмотрена пересылка сообщений только в одном направлении через одно TCP-соединение. Клиентский хост управляет средой передачи и направляет действия сервера посредством SMTP-команд. Почта может посылаться только от клиента к серверу. Но иногда желательно, чтобы клиентская машина не только посылала почту на сервер, но и принимала почту, которую сервер должен отдавать клиенту.

Как уже обсуждалось ранее, для идентификации клиента с которым организуется сеанс, сервер использует доменное имя, получаемое с помощью команды HELO. Смысл команды TURN заключается в разрешении серверу поменяться ролями с клиентом и отсылать ему почту, которая имеется для домена клиента. Единственная проблема, которая возникает при использовании такого алгоритма, — насколько надежен клиент и является ли он тем, за кого себя выдает. Если хакер, подключившись к серверу SMTP, называет себя чужим именем, то сервер будет вынужден отослать всю почту, предназначенную для этого домена, прямо на хост хакера. Приехали!

Ответы сервера

На каждую команду, посланную клиентом, SMTP-сервер должен ответить соответствующим сообщением. Как видно из листингов 5.2 и 5.3, ответы сервера состоят из двух частей. В первой части отображаются трехзначные коды, которые используются программным обеспечением SMTP для выводов об успешном (или не очень) выполнении тех или иных команд сервером, с указанием причины невыполнения, если команда не была выполнена. Вторая часть представляет собой строку текста, которая помогает человеку анализировать происходящее. Часто эта текстовая строка передается программным обеспечением сервера SMTP и отображается как часть ответа сервера.

Обычно текстовая строка и код в ответе разделяются пробелом. Если ответ содержит несколько строк (например, при использовании команды HELP, см. листинг 5.4), код и текст разделяются дефисом (-) и только последняя строка ответа сервера содержит пробел в качестве разделителя. Это помогает клиентскому хосту ориентироваться, как много строк он примет от сервера. Существует четыре категории кодов ответа. Ниже мы рассмотрим их подробнее.

Коды ошибок, возвращаемые в ответах SMTP

В табл. 5.2 представлены коды ошибок, которые могут появиться во время SMTP-сеанса.

Сообщения об ошибках SMTP не дают полную картину происходящего. Они лишь отражают общую тенденцию процессов, происходящих во время сеанса SMTP. При поиске и устранении неполадок в работе электронной почты весьма полезно пронаблюдать реальный обмен командами и ответами на них сервера, в особенности если вы работаете с незнакомым SMTP-сервером. Часто появление ошибок типа 500, 502 и 504 может быть вызвано попыткой выполнения команд из расширений протокола SMTP, которые не поддерживаются более старыми версиями программ на сервере SMTP.

Информационные коды в ответах SMTP

Следующая категория — информационные коды. Они используются для отображения разного рода дополнительной информации о команде. Эти коды представлены в табл. 5.3.

Как показано в листинге 5.3, код ответа 214 используется при отображении результатов работы команды HELP. Когда имеется несколько строк для вывода, после кода ответа ставится дефис, который предупреждает, что далее следует еще одна строка ответа. В последней строке код ответа и текст разделены пробелом.

Служебные коды в ответах SMTP

Еще одна категория кодов ответа — служебные коды. Служебные коды используются для отображения состояния служба SMTP на протяжении соединения. Эти коды приведены в табл. 5.4.

Каждый из этих кодов ответа будет содержать имя хоста сервера SMTP в текстовой части ответа, а также описание. Код ответа 421 является немного некорректным. Многие администраторы почтовых систем считают, что данный код ответа означает недоступность программного обеспечения SMTP на удаленном сервере. Хотя это и может быть возможной причиной появления такого кода ответа, обычно он означает, что имеется сервер SMTP, который в данный момент не принимает почтовые сообщения. Иногда это может быть следствием сильной загруженности сервера при выполнении резервного копирования данных, что сопровождается блокированием файловой системы. В таком состоянии сервер не сможет сохранять почтовые сообщения, так как файловая система блокирована. Поэтому на время резервного копирования SMTP-сервер может временно приостанавливаться. Попытка подключения к серверу спустя некоторое время может оказаться успешной.

Коды ответов на действия в SMTP

Последняя группа кодов ответов сервера относится к ответам на действия клиента SMTP. В табл. 5.5 приведены коды ответов на действия, выполняемые при сеансе SMTP.

Коды действий являются результатом попыток SMTP-сервера выполнить запросы клиента, такие как команды MAIL, RCPT и DATA. Все они возвращают состояние выполнения того или иного действия. Благодаря этому во время сеанса SMTP клиент может принимать решения о необходимости каких-либо действий.

Коды ответов сервера SMTP — "актеры второго плана" в мире SMTP. Некоторые программы-клиенты электронной почты возвращают отправителю письма все коды ответов, содержащие ошибки. В таком случае намного легче проверить коды ответов, чем списки кодов, чтобы определить, что идет не так, как нужно. Иногда, однако, тяжело определить причину неправильной обработки сообщений электронной почты. Например, возвращаемое письмо не было правильно смаршрутизировано, и пользователь не получил соответствующий код ошибки. Кроме того, часто администраторам почтовых систем приходится обращаться к сетевым анализаторам для того, чтобы проследить реальный путь TCP-пакетов в ЛВС и увидеть коды ошибок, поступающие от SMTP-сервера. Помните, что пакеты данных протокола SMTP представляют собой текст в формате ASCII, поэтому их легко читать и декодировать.

Форматы сообщений

В листинге 5.2 показан простейший пример сеанса SMTP. Формат сообщения электронной почты, приведенный там же, довольно прост — всего одна строка текста. Сообщение, показанное в примере, хотя и является вполне функциональным, все же не совсем соответствует среднестатистическим электронным письмам, имеющим в настоящее время хождение по сети Internet. Сегодняшние сообщения электронной почты немного сложнее, и пользователи вполне закономерно ожидают соответствующего уровня обслуживания своих растущих потребностей. Теперь все эти поля вроде Subject, CC и BCC уже стали нормой при написании электронных писем и вопросов уже ни у кого не вызывают. Документ RFC 822 описывает стандартный формат почтового сообщения, который реализуется в той или иной степени в большинстве SMTP-систем. Эти системы как бы "стандартизируют" внешний вид и стиль работы с электронной почтой. В наше время простые однострочные сообщения уже не удовлетворяют потребности современного большого бизнеса.

Стандартные поля заголовка, согласно RFC 822

Документом RFC 822 предусматривается разбиение сообщения на две части. Первая часть называется заголовком. В нее вносятся все данные, идентифицирующие сообщение. Вторая часть называется телом сообщения. Заголовок состоит из полей данных, которые используются по мере необходимости внесения дополнительной информации в сообщение. Поля заголовка и тело сообщения должны разделяться пустой строкой. Для полей заголовка не существует определенного порядка следования, т.е. поля заголовка могут располагаться в произвольном порядке. Кроме того, в одном сообщении поля заголовка могут повторяться. На рис. 5.1 представлен общий вид почтового сообщения, соответствующего требованиям RFC 822.

Поле заголовка Received

Формат поля заголовка Received: (Принято:) следующий:

Received:
from host name
by host name
via physical-path
with protocol
id message-id
for final e-mail destination

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

Поле заголовка Return-Path

Формат этого поля заголовка следующий:

Return-Path: route

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

Поле заголовка Originator

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

Reply-To: address

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

Поле заголовка Resent

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

Resent-Reply-To:
address

Поля заголовка Authentic

Данные поля заголовка идентифицируют отправителя электронного сообщения. Формат полей Authentic:

From: user-name
Sender: user-name

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

Поля заголовка Resent-authentic

Поля Resent-authentic определяют отправителя сообщения, которое по какой-либо причине повторно передавалось программой-клиентом. Формат этих полей следующий:

Resent-From: date-time
Resent-Sender: date-time

Поля Resent-From: и Resent-Sender: работают подобно полям From: и Sender:. Они лишь отражают, что сообщение было повторно передано клиентом по неизвестной причине.

Поля заголовка Dates

Поля заголовка Dates используются для помещения метки времени в сообщение при передаче его от клиента серверу. Формат полей Dates следующий:

Date: date-time
Resent-Date: date-time

Поле Date: (Дата) будет пересылать информацию в заголовке сообщения в точном соответствии с оригиналом сообщения. Этот параметр может оказаться полезным при отслеживании времени получения ответов, в особенности — множественных ответов.

Поля заголовка Destination

В полях заголовка Destination указываются адреса электронной почты получателей сообщения. Эти поля являются чисто информационными. Сервер SMTP в любом случае не будет посылать сообщение в почтовый ящик пользователя, пока на получит команду RCPT, выданную для данного пользователя (см. раздел "Основные команды клиента SMTP"). Формат этих полей следующий:

To: address
Resent-To: address
CC: address
Resent-CC: address
BCC: address
Resent-BCC: address

Поля To:, CC: и BCC: устанавливают стандартный алгоритм обработки электронной почты. Большинство пакетов для работы с электронной почтой используют именно эту терминологию для классификации получателей сообщения. Поле CC: сходно с памяткой, и указанные в нем получатели должны получить "копию" сообщения. Еще одно новое понятие, введенное системами электронной почты, — BCC: или "невидимая копия" (blind carbon copy). В поле "невидимой копии" также указывается получатель копии сообщения, но его адрес не виден посторонним (это не совсем этично). В связи с этой опцией обсуждалась вопросы компьютерной этики, но на сегодняшний день практически все программы для работы с электронной почтой поддерживают эту возможность.

Необязательные поля заголовка

Необязательными являются поля, которые более подробно идентифицируют сообщение для сервера SMTP, но, согласно RFC 822, могут и не присутствовать в сообщении. Тем не менее эти поля в настоящее время широко распространены, и многим из вас придется столкнуться с ними. Формат некоторых из них следующий:

Message-ID: message-id
Resent-Message-ID: message-id
In-Reply-To: message-id
References: message-id
Keywords: text - list
Subject: text
Comments: text
Encrypted: word

Наиболее полезным и часто используемым из этого набора является поле Subject: (Тема). Большинство программ для работы с электронной почтой допускает ввод отправителем темы сообщения в одну строку, которая описывает для получателя содержание сообщения. Эта строка текста довольно часто используется почтовой программой-клиентом при формировании списков полученных сообщений. Еще одно необязательное поле также помогает идентифицировать почтовое сообщение. Это поле Message-ID: (Идентификатор сообщения). В этом поле сообщению присваивается уникальный идентификационный номер, который может затем отображаться в возвращенном сообщении. Специальное поле шифрования Encrypted: указывает, было ли сообщение в целях безопасности подвергнуто шифрованию, а в Keywords: можно задать ключевые слова, которые можно использовать при поиске определенного текста, встречающегося в сообщении (сообщениях).

Использование формата RFC 822 при почтовой операции по протоколу SMTP

Пример почтовой операции по протоколу SMTP с использованием полного формата сообщения согласно RFC 822 представлен в листинге 5.5.

1 [rich@shadrach rich]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 250 shadrach.smallorg.org Hello localhost [127.0.01], pleased to meet you
6 MAIL FROM:rich@localhost
7 250 rich@localhost... Sender ok
8 RCPT TO:rich
9 250 rich... Recipient ok
10 DATA
11 354 Enter mail, end with "." on a line by itself
12 Return-Path:rich@localhost
13 received: from localhost by localhost with TCP/IP id 1 for Richard Blum
14 Reply-to:rich@localhost
15 From:rich
16 Date:8/27/99
17 To:rich
18 cc:jessica
19 cc:katie
20 bcc:barbara
21 bcc:haley
22 Message-ID:1
23 Sub]ect:Test RFC 822 message
24
25 This is a test message sent from the local host to rich.
26 This message is a little larger, and sweet.
27 .
28 250 PAA02866 Message accepted for delivery
29 QUIT
30 221 shadrach.smallorg.org closing connection
31 Connection closed by foreign host.
32 You have new mail in /var/spool/mail/rich
33 [rich@shadrach rich]$ mail
34 Mail version 8.1.6/6/93. Type ? for help.
35 "/var/spool/mail/rich": 1 message 1 new
36 >N 1 rich@shadrach.smallo Fri Aug 27 18:50 18/622 "Test RFC 822 message"
37 1
38 Message 1:
39 From rich@smallorg.org Fri Aug 27 18:50:21 1999
40 From: rlch@shadrach.smallorg.org
41 Reply-to: rich@shadrach.smallorg.org
42 Date: 8/27/99
43 To: rich@shadrach.smallorg.org
44 cc: jessica@shadrach.smallorg.org
45 cc: katie@shadrach.smallorg.org
46 Subject: Test RFC 822 message
47
48 This is a test message sent from the local host to rich.
49 This message is a little larger, and sweet.
50
51 x
52 [rich@shadrach rich]$

Этот пример сходен с тем, что представлен в листинге 5.2, но обратите внимание на отличия между ними. Строки 12–23, согласно RFC 822, отображают поля заголовков, которые были использованы в сообщении. В строке 36 показано, что программа для чтения электронной почты использует поле Subject: для краткого описания содержания сообщения. Строки 39–46 отображают поля заголовка, в том порядке, в котором они выводятся на экран программой для чтения почтовых сообщений. Обратите внимание на отсутствие полей BCC:. Поля BCC: используются только для идентификации "невидимых" копий. Те получатели сообщения, о которых другим получателям знать не следует, получают копии сообщения (немного путано, не правда ли?). Это имеет смысл для программы чтения почтовых сообщений, поскольку эти поля не отображаются в ней. Еще одна очевидная разница заметна в строке с датой. В строке 28 листинга 5.2 указывается полная дата, которая автоматически добавляется программой для работы с электронной почтой. В строке 42 листинга 5.5, согласно RFC 822, отображается дата, установленная в сообщении. Данный пакет для работы с электронной почтой позволяет полям, которые соответствуют RFC 822, перекрывать автоматически подставленную дату.

Двоичные данные и MIME

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

За несколько лет до изобретения протокола SMTP системные администраторы UNIX уже пересылали двоичные данные с помощью почтовых программ, которые "понимали" только текст в формате ASCII. Метод, который они использовали для преобразования двоичных данных в ASCII-код, назывался uuencode и uudecode. Первые буквы uu обозначали UNIX-to-UNIX. Был также разработан протокол для передачи данных между UNIX-компьютерами посредством модемов (об этом подробнее вы прочтете в лекции 9, ). После того как протокол SMTP приобрел популярность, системные администраторы UNIX стали использовать эти утилиты для передачи двоичных данных с его помощью через Internet. К сожалению, многие современные пакеты для работы с электронной почтой уже не включают такую возможность.

Многие современные пакеты для работы с почтой не содержат утилиту uuencode по той причине, что теперь уже официально существует стандарт для кодирования двоичных файлов в сети Internet. В документах RFC 2045 и 2046 описывается формат многоцелевых расширений для электронной почты в Internet (Multipurpose Internet Mail Extensions — MIME). Алгоритм кодирования MIME намного надежней uuencode. В нем учитывается тип двоичного файла, подвергающегося преобразованию, а также передается дополнительная информация о файле для декодера. Алгоритм MIME позволяет помещать двоичные данные напрямую в стандартное почтовое сообщение, согласно RFC 822. Для описания двоичных данных, вкладываемых в сообщение формата RFC 822, были созданы пять новых полей заголовка. Программы для работы с почтой, которые поддерживают стандарт MIME, должны правильно обрабатывать все эти новые типы заголовков. На рис. 5.2 показано, каким образом все это помещается в стандартное почтовое сообщение.

Поле заголовка MIME-Version

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

Поле Content-Transfer-Encoding

В поле заголовка Content-Transfer-Encoding указывается способ помещения двоичных данных в сообщение текстового формата ASCII. На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII.

Поле Content-ID

Это поле заголовка используется для идентификации сеансов MIME по определенному идентификационному коду, когда содержимое имеет сложную структуру.

Поле Content-Description

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

Поле заголовка Content-Type

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

Тип данных text идентифицирует данные в формате ASCII, которые должны читаться в исходном виде. Здесь существует также два подкласса — plain -текст, т.е. неформатированный ASCII-текст, и enriched -текст, который включает в себя элементы форматирования, схожие с обогащенным текстовым форматом. Новейшие программы для работы с электронной почтой могут работать даже с обогащенным текстовым форматом (RTF).

Тип данных message позволяет почтовой программе отсылать простые сообщения в формате RFC 822. Подклассы этого типа: rfc822, который указывает на то, что вложением является обычное сообщение, соответствующее RFC 822; partial, который позволяет разбивать длинные сообщения на несколько частей, и external-body, который позволяет помещать указатель на объект, не являющийся частью сообщения.

Тип данных image определяет вложение в сообщение двоичных данных, которые представляют собой графическое изображение. В настоящее время для этого типа определено два подкласса — jpeg и gif.

Тип данных video, соответственно, определяет, что вложенные в сообщение данные представляют собой видеоданные. В настоящее время для этого типа определен только один подкласс — формат mpeg.

Тип данных audio обозначает содержимое сообщения как аудиоданные (звуковые файлы). Здесь также пока определен только один подкласс basic, который соответствует одному каналу ISDN с частотой дискретизации 8 Кгц.

Тип данных application соответствует двоичным данным, вложенным в сообщение, которые являются приложением (например, электронные таблицы Microsoft Excel или документы, созданные с помощью текстового процессора Microsoft Word). На сегодняшний день определено два подкласса такого рода данных — postscript и octet-stream. Довольно часто подкласс octet-stream используется при вложении в сообщение прикладных данных, таких как документы Microsoft Word или электронные таблицы Microsoft Excel.

Тип данных multipart идентифицирует сообщения, содержащие несколько различных типов данных. Этот формат довольно часто встречается в почтовых программах, поддерживающих вывод сообщения несколькими способами, например в виде текста ASCII, HTML-текста или аудиофайла. Граничный идентификатор разделяет различные типы данных. В то же время каждый тип данных идентифицируется определенным полем заголовка типа данных. Тип данных multipart имеет четыре подкласса.

Подкласс mixed указывает на то, что каждая из частей сообщения является независимой и все они должны быть представлены получателю в том порядке, в каком они были вложены отправителем. Подкласс parallel указывает то, что каждая из частей сообщения является независимой и все они могут быть представлены получателю в любом порядке. Следующий подкласс alternative указывает, что все части сообщения представляют собой одни и те же данные, но представленные в различном виде. При этом получатель может выбрать наилучшее средство для просмотра полученных данных. Подкласс digest во многом сходен с подклассом mixed, но при этом указывает, что тело сообщения всегда представляется в формате RFC822.

1 [rich@shadrach rich]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 07:36:58 -050
6 HELO localhost
7 258 shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you
8 MAIL FROM:rich@localhost
9 250 rich@localhost... Sender ok
10 RCPT TO:rich
11 250 rich... Recipient ok
12 DATA
13 354 Enter mail, end with "." on a line by itself
14 From:"Rich Blum" <rich@localhost>
15 To:"rich"<rich©localhost>
16 Subject:Formatted text message test
17 MIME-Version: 1.0
18 Content-Type: multipart/alternative; boundary=bounds1
19
20 –bounds1
21 Content-Type: text/plain; charset=us-ascii
22
23 This is the plain text part of the message that can
24 be read by simple e-mail readers.
25
26 –-bounds1
27 Context-Type: text/enriched
28
29 This is the <bold>rich text</bold> version of the <bigger>SAME</bigger> message.
30
31 –-bounds1--
32 .
33 250 MAA04305 Message accepted for delivery
34 QUIT
35 221 shadrach.smallorg.org closing connection
36 Connection closed by foreign host.
37 You have new mail in /var/spool/mail/rich
38 [rich@shadrach rich]$

Пример сообщения, представленный в листинге 5.6, является сообщением MIME, которое состоит из двух частей. В строке 18 показан тип данных сообщения. Тип multipart/alternative указывает на то, что в сообщении имеются различные типы данных, которые отделены граничным разделителем bounds1. Данные первого типа начинаются со строки 21 и представляют собой простой ASCII-текст, который может прочесть практически любая почтовая программа.

Данные второго типа начинаются со строки 27 и представляют собой форматированный текст с использованием обогащенного текстового формата. Так как тип MIME, указанный для сообщения, — multipart/alternative, то определение того, какую версию вложения отобразить, всецело зависит от почтовой программы. На рис. 5.3 показан пример отображения сообщения с помощью программы Netscape Mail. Обратите внимание на то, что обычный текст в формате ASCII был отвергнут, и для вывода на экран была использована версия с форматированным обогащенным текстом сообщения. В обеих частях обычного почтового сообщения содержится одно и то же. Содержимое частей сообщения было сделано различным лишь для того, чтобы показать вам, какую из версий сообщения выберет для отображения программа для чтения почты.

Расширенный протокол SMTP

С момента своего появления в 1982 году протокол SMTP прекрасно справлялся со своими задачами по пересылке сообщений между компьютерами в сети Internet. Однако со временем стали заметны заложенные в протокол ограничения. Тогда, вместо того чтобы заменить стандартный протокол, имевший к тому времени широкое распространение, было решено улучшить некоторые функции протокола SMTP. При этом было принято решение, оставив все спецификации SMTP в первозданном виде, лишь добавить к ним новые функции.

В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался "Расширенные службы SMTP".

Расширенный SMTP (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды. В листинге 5.7 показан пример сеанса с использованием EHLO, а также дополнительных команд.

1 [katie@shadrach katie]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 16:36:48 -050
6 EHLO localhost
7 250-shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you
8 250-EXPN
9 250-VERB
10 250-8BITMIME
11 250-SIZE
12 250-DSN
13 250-ONEX
14 250-ETRN
15 250-XUSR
16 250 HELP
17 HELP DSN
18 214-MAIL FROM: <sender> [ RET={ FULL || HDRS} ] [ ENVID=<envid> ]
19 214-RCPT TO: <recipient> [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
20 214- [ ORCPT=<recipient> ]
21 214- SMTP Delivery Status Notifications.
22 214-Descriptions:
23 214- RET Return either the full message or only headers.
24 214- ENVID Sender's "envelope identifier" for tracking.
25 214- NOTIFY When to send a DSN. Multiple options are OK, comma -
26 214- delimited. NEVER must appear by itself.
27 214- ORCPT Original recipient.
28 214 End of HELP info
29 HELP ETRN
30 214-ETRN [ <hostname> | @<domain> | #<queuename> ]
31 214- Run the queue for the specified <hostname>, or
32 214- all hosts within a given <domain>, or a specially-named
33 214- <queuename> (implementation-specific).
34 214 End of HELP info
35 QUIT
36 221 shadrach.smallorg.org closing connection
37 Connection closed by foreign host.
38 [katie@shadrach katie]$

В строке 6 задана SMTP-команда EHLO для подключения к серверу SMTP. Строки 7–16 отображают ответ сервера. Заметьте, сервер сигнализирует о том, что для использования доступно больше команд, т.е. сеанс происходит в "расширенном" режиме. Одна из новых групп команд называется параметрами уведомления о доставке сообщения (Delivery Status Notification). Эти параметры могут использоваться с командами MAIL и RCPT для отображения состояния доставки определенного сообщения электронной почты. Однако для нас как администраторов почтовой системы наибольший интерес представляет команда ETRN.

Команда TURN уже упоминалась ранее. Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

ETRN name

Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.

Реализация SMTP в ОС Linux

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

Программа sendmail

Программа sendmail является прародительницей всех программных пакетов для работы с SMTP. На протяжении многих лет она использовалась в среде UNIX. Ее развитие и поддержку осуществляет sendmail Consortium (http://www.sendmail.org). К моменту издания этой книги текущая версия sendmail была 8.9.3. Версия 8.10 проходит бета-тестирование, и, возможно, вскоре будет доступной, так что наведывайтесь почаще на Web-сайт, где всегда есть свежая информация о новых версиях программы.

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

Конфигурирование sendmail может потребовать некоторой предварительной подготовки. Изданы целые книги лишь про установку и настройку sendmail. Sendmail Consortium открыл специальный Web-сайт для того, чтобы оказывать помощь администраторам систем электронной почты в настройке sendmail и решении проблем, возникающих при ее эксплуатации. Одна из заслуживающих внимания возможностей программы sendmail состоит в том, что она содержит типовой конфигурационный файл и автоматизированную систему для генерации новых конфигураций на его основе. Все, что от вас потребуется, — создать текстовый файл, в котором содержатся необходимые параметры и возможности. В листинге 5.8 представлен пример текстового файла sendmail, который можно использовать для генерации конфигурационного файла.

1 divert(-1)
2 divert(0)dnl
3 include(` ../m4/cf.m4')dnl
4
5 OSTYPE(`linux')
6
7 FEATURE (`allmasquerade')dnl
8 FEATURE (`masquerade_envelope')dnl
9 FEATURE (`always_add_domain')dnl
10 FEATURE(`nodns')dnl
11 FEATURE(`nocanonify')dnl
12 FEATURE(`local_procmail')dnl
13 FEATURE(`uucpdomain')dnl
14
15 MAILER(`smtp')dnl
16 MAILER(`uucp')dnl
17 MAILER(`procmail')dnl
18
19 define(`SMART_HOST', `uucp-dom:mail.isp.net')dnl

Когда работа над файлом описания завершена, его необходимо обработать специальной программой-макропроцессором m4. Формат использования программы m4 следующий:

m4 mailhost.m4 > sendmail.cf

По этой команде генерируется конфигурационный файл sendmail.cf с параметрами и возможностями, заданными в файле описания. В лекции 11 , этот процесс рассмотрен более детально.

Следует отметить также широкое распространение sendmail. Большинство серверов сети Internet работают именно с этой программой, так что при обнаружении каких-либо неполадок или дыр в защите они оперативно устраняются. Так, весной 1999 года в Internet появился широко известный вирус Melissa. Это был типичный макровирус, поражавший документы Microsoft Word. Его распространению способствовало то, что этот вирус, используя программный пакет для обработки почты Microsoft Outlook, посылал свои копии на другие компьютеры, адреса которых находились в адресной книге Microsoft Outlook. Несмотря на то что вирус не оказывал прямого воздействия на программу sendmail, программисты разработали специальный фильтр, который можно включать в конфигурацию sendmail на SMTP-сервере. Этот фильтр сканирует почтовые сообщения, и если в них обнаруживается вирус Melissa, то пересылка аннулируется. Довольно изящно, не правда ли?

Программа qmail

Программный пакет qmail, написанный Дэном Бернстейном (Dan Bernstein), является полноценным заменителем программного пакета sendmail. Основное внимание при его создании уделялось вопросам надежности и безопасности — двум довольно впечатляющим целям. Дэн организовал в Internet свой сервер на базе qmail и объявил приз в $1000 тому, кто сможет взломать его защиту. На момент написания книги никто не обратился за этой премией. Кроме того, в qmail предлагается улучшенный метод помещения корреспонденции в электронные почтовые ящики пользователей с использованием нового формата почтового ящика, более устойчивого к сбоям в системе. Возможно, главным преимуществом qmail является простота конфигурирования. Для ее настройки используются простые текстовые файлы в формате ASCII. Программа qmail является удачным выбором для простого почтового сервера.

Текущая версия qmail — 1.03. В настоящее время пакет qmail пока не входит ни в одну из версий ОС Linux. Если вы решите использовать этот программный пакет, то нужно получить его через Internet с сайта по поддержке qmail по адресу http://www.qmail.org, а затем самостоятельно скомпилировать (но в Linux это только полдела!).

После того как вы получили и скомпилировали пакет, его нужно еще установить. Для поддержки заявленного высокого уровня безопасности программа qmail должна устанавливаться и впоследствии запускаться с определенными идентификатором пользователя и группой. В принципе, программой используется две группы и семь идентификаторов пользователя. Для хранения исходных и конфигурационных файлов программа qmail использует каталог /var/qmail. Если в вашей версии ОС Linux уже установлен пакет sendmail, то необходимо удалить его (или по крайней мере запретить его использование в системе), чтобы программа qmail смогла получить управление TCP-портом для протокола SMTP с целью обработки входящих SMTP-запросов. Программа qmail также устанавливает специальный набор инструкций, в которых описан процесс проверки правильности работы демона qmail при включении и выключении системы.

Программа smail

Пакет smail является реализацией программного обеспечения SMTP, предложенной GNU Project. Как известно, этой организации принадлежит большинство прав на разработку и распространение утилит для ОС Linux. Организация проекта GNU имеет большое количество зеркальных серверов, где анонсируются новые версии smail. На момент написания книги текущей версией этой программы была версия 3.2. Некоторые распространители ОС Linux даже включают smail в виде пакета готового к установке.

Программа smail приобрела популярность среди тех администраторов почтовых систем, которые хотели иметь программный пакет SMTP, совмещающий гибкость sendmail и легкость конфигурирования. В действительности, серверы, на которых используется протокол UUCP для передачи почты, совершают намного больше действий, чем простое добавление доменного имени в конфигурационный файл. Основной конфигурационный файл smail находится в каталоге /usr/lib/smail/config. В листинге 5.9 показан пример конфигурационного файла для smail.

1 #
2 #list all domain names this host will accept mail for
3 hostnames=mail.smallorg.org:smallorg.org:mail
4 #
5 #describe our advertised domain name
6 visible_name=smallorg.org
7 #
8 #identify our default SMTP gateway to the Internet
9 smart_path=mail.isp.net
10 smart_transport=smtp
11 #
12 #list domains we are authoritative for
13 auth_domains=smallorg.org

Вот и все. Всего 13 строк конфигурационного файла (включая комментарии), с помощью которых выполняется маршрутизация всех почтовых сообщений на SMTP-хост, используемый по умолчанию.

Одна из полезных возможностей smail — ее способность доставлять сообщения немедленно, без помещения их в очередь. Такой способ ускоряет доставку электронной почты, но может повлечь за собой появление определенных проблем при больших объемах электронной почты. Для решения этой проблемы можно сконфигурировать smail таким образом, чтобы почта помещалась в очередь, как это делается в sendmail.

Программа exim

Программа exim для работы с SMTP была разработана Кембриджским университетом на основании общественной лицензии GNU. Она доступна в настоящее время для большинства версий ОС UNIX, включая Linux. Текущая версия exim — 3.02. Ее возможности по защите SMTP от спамеров и хакеров снискали заслуженное уважение среди пользователей Linux. В exim имеется несколько конфигурационных файлов, которые могут ограничивать доступ на основе имен хостов, IP-адресов или доменных имен. Более подробную информацию о программе exim можно получить через Web-сайт в Internet по адресу http://www.exim.org.

Резюме

Простой протокол передачи почты Simple Mail Transfer Protocol (SMTP) позволяет компьютерам передавать сообщения от пользователя на одном компьютере пользователю (или нескольким пользователям) на другом компьютере. Протокол SMTP описан в документе RFC 821, где определен стандартный набор команд, идентифицирующих отправителя и получателя сообщения, а также команд, используемых для передачи сообщения. Почтовое сообщение может быть представлено в произвольной форме, но его стандартный формат был определен в RFC 822. Этим форматом предусмотрено существование в сообщении двух частей — заголовка и тела сообщения. Заголовок сообщения содержит поля, которые несут важную информацию о сообщении; здесь указывается отправитель сообщения, его получатели, тема сообщения и комментарии. Двоичные данные при пересылке по электронной почте по протоколу SMTP должны кодироваться в текстовый формат ASCII. Для кодирования и передачи двоичных данных по сети Internet был разработан стандарт для включения их в обычное почтовое сообщение формата RFC 822. Новые поля заголовка, предусмотренные RFC 822, которые помогают идентифицировать вложенные двоичные данные, описаны в RFC 2045 и 2046. В ОС Linux протокол SMTP поддерживается несколькими программными пакетами. Программный пакет sendmail является стандартным для большинства UNIX-платформ. Версия sendmail была разработана и для ОС Linux. Другие программы для работы с SMTP — qmail, smail и exim — содержат некоторые улучшения и/или легче в использовании, по сравнению с sendmail.