Реклама:

info.krc.karelia.ru

win -:|:- koi -:|:- iso -:|:- dos -:|:- mac

Start -:|:- Проекты -:|:- О нас

SENDMAIL - Межсетевой почтовый роутер

Eric Allman1

University of California, Berkeley Mammoth Project

Перевод Плотникова Александра

Предисловие переводчика

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

Против распространения не возражаю, единственное условие: оставить все как есть, не внося никаких изменений.
Эту и много другой документации вы сможете найти у меня на страничке.
Приму любые конструктивные замечания и предложения, направляйте их на адрес asp@pvrr.ru.


ABSTRACT

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

Sendmail работает как обьединенное "почтовое отделение", куда может быть доставлена вся почта. Интерпретация адресов контролируется рабочей системой, которая может производить синтаксический анализ адресов на основе доменов и старых адресов в специализированном виде. Рабочая система достаточно мощна для того, чтобы переделывать адреса в заголовках сообщений, чтобы они соответствовали стандартам ряда общедоступных сетей, включая старую (NCP/RFC733) Arpanet, новую (TCP/RFC822) Arpanet, UUCP, и Phonenet. Sendmail также обеспечивает SMTP сервер, организацию очередей сообщений, и совмещение имен (aliasing).

Sendmail представляет средство общей межсетевой почтовой маршрутизации, обеспечивающее совмещение имен (aliasing) и пересылку (forwarding), автоматическую маршрутизацию к сетевым шлюзам, и гибкую конфигурацию.

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

В internet, множество сетей с различными характеристиками и управлением должны связываться. В частности, синтаксис и семантика идентификации ресурса измененяются. Особые конкретные случаи могут быть обработаны заранее используя специальную технологию, типа обеспечения сетевых имен, являющихся локальными для хостов в других сетях, как в случае Ethernet в Xerox PARC. Однако, общий случай чрезвычайно сложен. Например, некоторые сети требуют маршрутизации для соединений точка-точка, что упрощает проблему обновления базы данных, так как в системные таблицы должны быть введены только смежные хосты, в то время как другие используют сквозную адресацию. Некоторые сети используют лево-ассоциативный синтаксис, а другие используют право-ассоциативный синтаксис, вызывая неоднозначность в смешанных адресах.

Стандарты Internet пытаются устранить эти проблемы. Первоначально, они предложили расширять пары адресов, чтобы адресовать тройки, состоящие из сети, хоста, ресурса. Номера сетей должны быть универсально согласованы, и хосты могут быть назначены локально для каждой сети. Представление на пользовательском уровне было быстро расширено, чтобы адресовать домены составленные из локальной идентификации ресурса и иерархической спецификации домена с общим статическим корнем. Технология домена отделяет проблему физической адресации от логической. Например, адрес в виде "eric@a.cc.berkeley.arpa" описывает только логическую организацию адресного пространства.

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

Раздел 1 обсуждает цели проекта sendmail . Раздел 2 дает краткий обзор основных функций системы. В разделе 3 обсуждены детали использования . Раздел 4 сравнивает sendmail с другими программами маршрутизации почты в internet, и в разделе 5 дана оценка sendmail , включая будущие планы.

1. ЦЕЛИ ПРОЕКТА

Цели проекта sendmail включают:

(1)Совместимость с существующими почтовыми программами, включая Bell version 6 mail, Bell version 7 mail [UNIX83], Berkeley Mail [Shoens79], BerkNet mail [Schmidt79], и UUCP mail [Nowitz78a, Nowitz78b]. Так же требуется совместимость с ARPANET mail [Crocker77a, Postel77].

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

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

(4) Простое наращивание в довольно сложных окружениях, включающих многократные соединения с одиночным сетевым типом (типа с многократным UUCP или сетью Ether [Metcalfe76]). Эта цель требует рассмотрения содержания адреса,а также синтаксиса, чтобы определить какой шлюз использовать. Например, ARPANET переходит на протокол TCP, заменяя старый NCP протокол. Ни один хост в Berkeleyне имеет одновременно TCP и NCP, так что необходимо рассмотреть имя хоста ARPANET, чтобы определить, направить ли почту к шлюзу NCP или TCP.

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

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

(7) Каждому пользователю должно быть позволено определять какую почтовую программу (mailer) выполнить для обработки почты, доставляемой для него. Эта особенность позволяет пользователям, использующим специализированные почтовые программы с различными форматами, построить их окружение без изменения системы, и облегчает специализированные функции (типа возврата сообщения " я нахожусь на каникулах ").

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

    ____________________________________________________
         +---------+    +---------+    +---------+
         | sender1 |    | sender2 |    | sender3 |
         +---------+    +---------+    +---------+
              |              |              |
              +----------+   +   +----------+
                         |   |   |
                         v   v   v
                      +-------------+ 
                      |  sendmail   | 
                      +-------------+
                         |   |   | 
              +----------+   +   +----------+
              |              |              |
              v              v              v
        +---------+     +---------+    +---------+
        | mailer1 |     | mailer2 |    | mailer3 |
        +---------+     +---------+    +---------+
            Рис. 1 - Структура системы Sendmail. 
    ____________________________________________________

2. ВВЕДЕНИЕ

2.1. Организация системы

Sendmail не взаимодействует с пользователем и на самом деле не производит доставку почты. Точнее, он собирает сообщения созданные интерфейсной пользовательской программой (user interface program (UIP)) типа Berkeley Mail, MS [Crocker77b], или MH [Borden79], редактирует сообщение так, как этого требует сеть назначения, и вызывает соответствующую программу доставки почты для ее доставки или постановки в очередь для передачи через сеть 2. Этот алгоритм позволяет использовать новую программу доставки почты при минимальной стоимости. В этом смысле sendmail походит на Модуль Обработки Сообщений (Message Processing Module (MPM)) [Postel79b].

2.2. Интерфейсы во Внешний Мир

Для sendmail имеется три способа связи с внешним миром, как для получения, так и для посылки почты. Они используют традиционный UNIX-овый статус вектора/возврата состояния, разговаривая по SMTP через пару UNIX-овых труб (pipe-ов), и разговаривая по SMTP через канал между процессами.

2.2.1. Статус вектора/возврата Состояния

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

2.2.2. SMTP через трубы (pipes)

Протокол SMTP [Postel82] может быть использован для запуска интерактивного интерфейса с программой посылки почты. В этом случае все еще создается подпроцесс, но адреса получателей почты не передаются в посылающую программу через список аргументов. Вместо этого, они передаются во одному в командах, посылаемых на стандартный вход процесса. Все, что приходит на стандартный выход, должно быть кодом возврата в специальном формате.

2.2.3. SMTP через IPC соединение

Эта технология похожа на предыдущую, кроме того, что здесь используется 4.2bsd IPC канал [UNIX83]. Этот метод исключительно гибок в том, что программа посылки сообщений не должна находиться на той же машине. Обычно это используется для соединения с процессом sendmail на другой машине.

2.3. Описание Работы

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

2.3.1. Обработка аргументов и синтаксический разбор адреса

Если sendmail вызывается с использованием одного из двух методов подпроцесса, сначала сканируются аргументы, а потом обрабатываются опции. Затем собираются адреса получателей, как через командную строку, так и через использование команды SMTP RCPT, и создается список получателей. На этом шаге раскрываются псевдонимы (aliases), включая списки рассылки. На этом этапе выполняются все возможные проверки: проверяется синтаксис, проверяются локальные адреса, но детальная проверка имен хостов и адресов откладывается до самой доставки. После проверки локальных адресов также выполняется пересылка (forwarding).

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

2.3.2. Забирание Сообщения

Затем Sendmail забирает сообщение. Сообщение должно иметь в начале заголовок (header). к самому сообщению не выдвигается никаких требований по его формату, кроме того, что оно должно состоять из строк текста (то есть бинарные данные не дозволяются). Заголовок проходит синтаксический разбор и сохраняется в памяти, а тело сообщения сохраняется во временном файле. Для упрощения программного интерфейса, сообщение забирается даже в том случае, если нет ни одного правильного адреса. Просто это сообщение будет возвращено с ошибкой.

2.3.3. Доставка Сообщения

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

Сообщение посылается в программу доставки с использованием одного из трех интерфейсов, используемых для представления сообщения в sendmail. Каждая копия сообщения предваряется приспособленным заголовком. Код статуса программы доставки отлавливается и проверяется, и если что выдается соответствующее сообщение об ошибке. Код выхода должен соответствовать системным стандартам, в противном случае выдается общее сообщение ("Service unavailable").

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

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

2.3.5. Возврат Посылателю

Если во время обработки происходит ошибка, sendmail возвращает сообщение посылателю для повторной передачи. Письмо может быть отослано назад , или записано в файл "dead.letter" в домашнем каталоге посылателя 3.

2.4. Редактирование Заголовка Сообщения

Автоматически происходит некоторое редактирование заголовка сообщения. Строки заголовка могут быть всавлены под управлением файла конфигурации. Некоторые строки могут быть добавлены; например, при некоторых условиях могут быть добавлены строка "From:" и строка "Full-name:".

2.5. Файл Конфигурации

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

Для увеличения скорости чтения конфигурационного файла, может быть использован его имидж в памяти. Это может быть обеспечено "компиллированной" формой конфигурационного файла.

3. ИСПОЛЬЗОВАНИЕ И РЕАЛИЗАЦИЯ

3.1. Аргументы

Аргументами могут быть флаги и адреса. Флаги выставляют различные опции обработки. Пока не запущен режим SMTP, следом за флагами могут быть заданы аргументы адреса. Адреса следуют синтаксису, описанному в RFC822 [Crocker82] для формата адресов ARPANET. В кратце, формат такой:

(1) Все, что находится в круглых скобках выкидывается (как комментарий).

(2) Все, что находится в угловых скобках ("<>") имеет преимущество перед всем остальным. Это правило представляет собой стандарт ARPANET о том, что адрес в виде

user name <machine-address>

будет посылаться на электронный "адрес машины" а не на человеческий "user name".

(3) Двойные кавычки ( " ) отделяют фразы; обратные наклонные линии отделяют символы. Обратные наклонные линии имеют большую силу, так как они могут заставить различные эквивалентные фразы рассматривать по-разному, например, user и "user" эквивалентны, но \user - это что-то совсем от них отличное. Круглые скобки, угловые скобки, и двойные кавычки должны быть соответственно сбалансированы и размещены. Правила переписывания управляют оставшимся синтаксическим разбором 4.

3.2. Посылка Почты в Файлы и Программы

Файлы и программы - законные получатели почты. Файлы обеспечивают архивное хранение сообщений, полезное для администрирования и архивирования. Программы полезны в качестве получателей почты в самых различных ситуациях, например, для поддержания публичного репозитория системных сообщений (тпа программы Berkeley msgs, или системы MARS [Sattley78]).

Любой адрес, проходящий через начальный алгоритм синтаксического разбора локальных адресов (то есть не являющийся действительным адресом для другой почтовой программы) сканируется на два специальных случая. Если он предварен вертикальной чертой ("|"), то оставшаяся часть адреса будет обработана как команда оболочки (shell command). Если имя пользователя начинается со знака косой черты ("/"), то это имя используется как имя файла, вместо имени пользователя. Файлы, имеющие выставленные биты смены владельца (setuid) или смены группы (setgid) но не имеющие битов выполнения имеют эти биты, если sendmail запущен от пользователя root.

3.3. Псевдонимы, Пересылка, Включение

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

3.3.1. Псевдонимы

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

3.3.2. Перенаправление

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

"|/usr/local/newmail myname"

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

3.3.3. Включение

Включение имеет определенный в RFC 733 [Crocker77a] синтаксис:

:Include: pathname

Адрес такого типа считывает файл определенный pathname и рассылка производится по всем адресам, перечисленным в этом файле. Целью является не поддержка прямого использования этой особенности, а скорее использование такой разновидности псевдонимизации. Например, псевдоним в виде:

project: :include:/usr/project/userlist

позволяет project поддерживать список рассылки без взаимодействия с системным администратором, даже если файл псевдонимов защищен. При этом нет необходимости перестраивать индексы в базе данных псевдонимов при изменении списка :include: .

3.4. Сбор Сообщений

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

Заголовок представляет собой некоторое количество строчек следующего вида

имя_поля: значение_поля

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

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

3.5. Доставка Сообщения

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

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

3.6. Очередь сообщений

Если программа отправки почты возвращает статус выхода "temporary failure" (временная неудача), сообщение ставится в очередь. Для описания получателей почты и различных других параметров используется контрольный файл (control file). Этот контрольный файл содержит последовательности строк, каждая из которых описывает отправителя, получателя, время передачи, или некоторые другие явновыраженные параметры сообщения. Заголовок сообщения также сохраняется в контрольном файле, так что соответствующий файл данных в очереди - всего лишь временный файл, который был изначально получен.

3.7. Конфигурация

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

(1) Смена операционной системы (V6, V7/32V, 4BSD).

(2) Удаление или вставка библиотеки DBM (база данных в UNIX).

(3) Изменение кодов ответа ARPANET.

(4) Добавление полей заголовков, требующих специальной обработки.

Добавление программ отправителей или изменение синтаксической обработки (т.е., перезаписи) или информации о маршрутизации не требует перекомпилляции.

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

Файл конфигурации кодирует макроопределения, определения заголовка, определения программы-отправителя, правила перезаписи и опции.

3.7.1. Макросы

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

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

3.7.2.Объявления заголовка

Объявления заголовка информируют sendmail о формате известных строк в заголовка. Знание о нескольких строках заголовка встроены в sendmail, например строки "From:" и "Date:".

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

3.7.3. Объявления Программы-Отправителя

Объявления программы-отправителя говорят sendmail о том, какие программы отправки для него доступны. Объявления определяют внутреннее имя программы-отправителя, путь для его вызова, некоторые флаги, необходимые для него и вектор аргументов, используемый при вызове; этот вектор перед использование может быть расширен макросом.

3.7.4. Правила перезаписи адреса

Сердце синтаксического разбора адреса в sendmail - набор правил перезаписи. Это упорядоченный список правил замены по образцу (порядок здесь очень важен), применяемых к каждому адресу. Адрес буквально переписывается до тех пор, пока он не будет записан в специальной канонической форме (т.е., (mailer, host, user), например {arpanet, usc-isif, postel} для адреса "postel@uscisif"), или пока он в конце концов не дойдет до конца. При соответствии образца, правило будет применяться пока не произойдет ошибки.

Файл конфигурации также поддерживает редактирование адресов в различные форматы. Например, адрес в виде:

ucsfcgl!tef

должен быть переделан в:

tef@ucsfcgl.UUCP

для соответствия синтаксису домена. Так же может быть произведен и обратный перевод.

3.7.5. Установка опций

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

4. СРАВНЕНИЕ С ДРУГМИ ОТПРАВИТЕЛЯМИ ПОЧТЫ

4.1. Delivermail

Sendmail является потомком delivermail. Основные отличия:

(1) Отсутствие вкомпилированной информации о конфигурации. Это изменение упрощает многие проблемы переноса на другие машины. Это также позволяет упростить отладку новых программ отправки почты.

(2) Более гибкий синтаксический анализ адресов. Например, delivermail поддерживает только один шлюз в любую сеть, в то время как sendmail может быть чувствителен к именам хостов может перенаправлять почту через различные шлюзы.

(3) Forwarding и :include: устраняют требование к тому, чтобы системный файл псевдонимов (aliases) должен быть доступен на запись для любого пользователя (или наличия программы обновления, или внесения всех изменений системным администратором).

(4) Sendmail поддерживает группирование сообщений при посылке сообщения многочисленным получателям.

(5) В sendmail обеспечивается почтовая очередь. Почта, которая не может быть доставлена немедренно, но вообще-то потенциально может быть доставлена позже сохраняется в этой очереди для дальнейшей повторной передачи. Очередь также обеспечивает буфер, защищающий от крахов системы; после получения сообщения, оно может быть надежно доставлено, даже если система "упадет" во время первичной доставки.

(6) Sendmail использует поддержку сети, обеспечиваемую 4.2BSD, для обеспечения прямого взаимодествия с сетями типа ARPANET и/или Ethernet, использующими SMTP (Simple Mail Transfer Protocol) поверх соединений TCP/IP.

4.2. MMDF

MMDF [Crocker79] имеет намного больше проблем, чем sendmail. Например, MMDF включает посылатель "phone network", в то время как sendmail во многих случаях производит вызов программмы доставки почты.

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

Конфигурация для MMDF компиллируется вместе с кодом5.

Из-за того, что задача обратной совместимости для MMDF не является одной из целей проекта, синтаксический анализ адресов нем проще, но намного менее гибок.

Интегрирование новых каналов6 в MMDF - что-то очень тяжелое и сложное. В частности, MMDF должен знать местонахождение и формат таблиц хостов для всех каналов, и каналы должны "говорить" на специальном протоколе. Это позволяет MMDF делать дополнительную проверку (типа проверки имен хостов) во время передачи.

MMDF строго разделяет фазы передачи и доставки. Sendmail также имеет концепции каждой из этих стадий, они интегрированы в одну программу, тогда как в MMDF они разбиты на две программы.

4.3. Модуль Обработки Сообщений

Модуль обработки сообщений (Message Processing Module) (MPM) описанный в [Postel79b] очень похож на sendmail в смысле его основной архитектуры. Однако, как и MMDF, MPM включает программное обеспечение для взаимодействия с сетью в виде части самой программы.

MPM также как и MMDF, требует дуплексный канал к приемнику, таким образом делая более простой обработку ошибок программой доставки, чем это возможно в sendmail. Когда сообщение, лежащее в очереди sendmail отослано, любые ошибки должны быть возвращены отправителю самой программой доставки. И у MPM, и у MMDF программы доставки могут немедленно возвращать сообщения об ошибках, и даже одна единственная ошибка может вызвать соответствующую реакцию.

MPM предпочитает передавать сообщение как структурированный объект, с наборами тип-длина-значение7. Такое соглашение требует намного более высокий уровень взаимодействия между программами доставки, чем это требует sendmail. MPM также подразумевает универсальную в пространстве имен internet адресацию (в которой адреса имеют вид набора сеть-хост-пользователь), отсутствующую в sendmail.

5. ОЦЕНКИ И ПЛАНЫ НА БУДУЩЕЕ

Sendmail разработан для работы в негомогенном окружении. Сделано все возможное во избежание возможных ненужных ограничений в основных программах доставки почты. Эта цель была основной в проекте. Одной из основных проблем было отсутствие единого адресного пространства, как это показано в [Postel79a] и [Postel79b].

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

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

Sendmail имеет встроенные знания о сложностях некоторых сред. Он при необходимости выдает сообщения об ошибках, совместимые с ARPANET FTP/SMTP (с числом из трех цифр [Neigus73, Postel74, Postel82]), для некоторых программ доставки может генерировать в стиле UNIX строку "From" в начале сообщения, и знает, как обработать такую строку на входе. Также, для BerkNet может быть определена своя обработка ошибок.

Рассматривалось также и решение об избежании любого типа доставки (и в особенности локальной доставки), что оказалось хорошей идеей. Даже при локальной доставке возникают вопросы о местонахождении почтового ящика, его формата, используемого протокола блокировки, и т.д., которые намного лучше решаются другими программами. Одним из главных недостатков многих средств доставки почты в internet является то, что местонахождение и формат локальной почты встроен в них. Кажется, что локальная почта настолько проста, что это не должно быть очень важным. Это ощущение абсолютно не согласуется с нашим опытом; наоборот, местонахождение и формат почтовых ящиков очень сильно меняется от системы к системе.

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

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

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

Ясно, что скоро общие протоколы изменятся, чтобы приспособиться к изменяющимся требованиям и конфигурациям. Эти изменения будут включать в себя модификацию заголовка (например, [NBS80]) или самого тела сообщения (например, для мультимедийных сообщений [Postel80]). Опыт показывает, что для интеграции с существующими системами эти изменения должны быть относительно просты.

Для жестко связанных конфигураций было бы хорошо иметь интегрированный в почтовую систему сервер имен типа Grapvine [Birrell82]. Это поможет сайтам типа "Berkeley" выступать как одному хосту, а не множеству хостов, что позволит людям спокойно менять машины без изменений своих почтовых адресов. Такая гибкость потребует автоматически обновляющуюся базу данных и какие-то методы разрешения конфликтов. В идеале, это должно работать, даже если све хосты не будут иметь единого управления. Однако, не ясно, должно ли это быть интегрированным в средства псевдонимизации, или это должно рассматриваться как "дополнительное" свойство вне самого sendmail.

Более интересен случай, сервера имен CSNET [Solomon81], обеспечивающего подобные свойства в одной жесткосвязанной среде. Однако, подобная вещь может нормально существовать "снаружи" sendmail.



ACKNOWLEDGEMENTS

Thanks are due to Kurt Shoens for his continual cheerful assistance and good advice, Bill Joy for pointing me in the correct direction (over and over), and Mark Horton for more advice, prodding, and many of the good ideas. Kurt and Eric Schmidt are to be credited for using delivermail as a server for their programs (Mail and BerkNet respectively) before any sane person should have, and making the necessary modifications promptly and happily. Eric gave me considerable advice about the perils of network software which saved me an unknown amount of work and grief. Mark did the original implementation of the DBM version of aliasing, installed the VFORK code, wrote the current version of rmail, and was the person who really convinced me to put the work into delivermail to turn it into sendmail. Kurt deserves accolades for using sendmail when I was myself afraid to take the risk; how a person can continue to be so enthusiastic in the face of so much bitter reality is beyond me.

Kurt, Mark, Kirk McKusick, Marvin Solomon, and many others have reviewed this paper, giving considerable useful advice.

Special thanks are reserved for Mike Stonebraker at Berkeley and Bob Epstein at Britton-Lee, who both knowingly allowed me to put so much work into this project when there were so many other things I really should have been working on.

REFERENCES

[Birrell82] Birrell, A. D., Levin, R., Needham, R. M., and Schroeder, M. D., "Grapevine: An Exercise in Distributed Computing." In Comm. A.C.M. 25, 4, April 82.

[Borden79] Borden, S., Gaines, R. S., and Shapiro, N.Z., The MH Message Handling System: Users' Manual. R-2367-PAF. Rand Corporation. October 1979.

[Crocker77a] Crocker, D. H., Vittal, J. J., Pogran, K. T., and Henderson, D. A. Jr., Standard for the Format of ARPA Network Text Messages. RFC 733, NIC 41952. In [Feinler78]. November 1977.

[Crocker77b] Crocker, D. H., Framework and Functions of the MS Personal Message System. R-2134-ARPA, Rand Corporation, Santa Monica, California. 1977.

[Crocker79] Crocker, D. H., Szurkowski, E. S., and Farber, D. J., An Internetwork Memo Distribution Facility MMDF. 6th Data Communication Symposium, Asilomar. November 1979.

[Crocker82] Crocker, D. H., Standard for the Format of Arpa Internet Text Messages. RFC 822. Network Information Center, SRI International, Menlo Park, California. August 1982.

[Metcalfe76] Metcalfe, R., and Boggs, D., "Ethernet: Distributed Packet Switching for Local Computer Networks", Communications of the ACM 19, 7. July 1976.

[Feinler78] Feinler, E., and Postel, J. (eds.), ARPANET Protocol Handbook. NIC 7104, Network Information Center, SRI International, Menlo Park, California. 1978.

[NBS80] National Bureau of Standards, Specification of a Draft Message Format Standard. Report No. ICST/CBOS 80-2. October 1980.

[Neigus73] Neigus, N., File Transfer Protocol for the ARPA Network. RFC 542, NIC 17759. In [Feinler78]. August, 1973.

[Nowitz78a] Nowitz, D. A., and Lesk, M. E., A Dial-Up Network of UNIX Systems. Bell Laboratories. In UNIX Programmer's Manual, Seventh Edition, Volume 2. August, 1978.

[Nowitz78b] Nowitz, D. A., UUCP Implementation Description. Bell Laboratories. In UNIX Programmer's Manual, Seventh Edition, Volume 2. October, 1978.

[Postel74] Postel, J., and Neigus, N., Revised FTP Reply Codes. RFC 640, NIC 30843. In [Feinler78]. June, 1974.

[Postel77] Postel, J., Mail Protocol. NIC 29588. In [Feinler78]. November 1977.

[Postel79a] Postel, J., Internet Message Protocol. RFC 753, IEN 85. Network Information Center, SRI International, Menlo Park, California. March 1979.

[Postel79b] Postel, J. B., An Internetwork Message Structure. In Proceedings of the Sixth Data Communications Symposium, IEEE. New York. November 1979.

[Postel80] Postel, J. B., A Structured Format for Transmission of Multi-Media Documents. RFC 767. Network Information Center, SRI International, Menlo Park, California. August 1980.

[Postel82] Postel, J. B., Simple Mail Transfer Protocol. RFC821 (obsoleting RFC788). Network Information Center, SRI International, Menlo Park, California. August 1982.

[Schmidt79] Schmidt, E., An Introduction to the Berkeley Network. University of California, Berkeley California. 1979.

[Shoens79] Shoens, K., Mail Reference Manual. University of California, Berkeley. In UNIX Programmer's Manual, Seventh Edition, Volume 2C. December 1979.

[Sluizer81] Sluizer, S., and Postel, J. B., Mail Transfer Protocol. RFC 780. Network Information Center, SRI International, Menlo Park, California. May 1981.

[Solomon81] Solomon, M., Landweber, L., and Neuhengen, D., "The Design of the CSNET Name Server." CS-DN-2, University of Wisconsin, Madison. November 1981.

[Su82] Su, Zaw-Sing, and Postel, Jon, The Domain Naming Convention for Internet User Applications. RFC819. Network Information Center, SRI International, Menlo Park, California. August 1982.

[UNIX83] The UNIX Programmer's Manual, Seventh Edition, Virtual VAX-11 Version, Volume 1. Bell Laboratories, modified by the University of California, Berkeley, California. March, 1983.


1 Значительная часть этой работы была выполнена во время работы над проектом INGRES в University of California в Berkeley и Britton Lee. [назад]

2 за исключением случая, когда посылка производится в файл, в этом случае sendmail происводит прямую доставку сам. [назад]

3 Конечно, если узел сети, выдающий ошибку, не является исходящим узлом, единственным правильным решением будет послать почту назад, к отправителю. Также, имеется намного больше опций определения ошибок, но все они приводят к сообщению об ошибке - функция "return to sender" всегда обслуживается одним из этих двух способов. [назад]

4 Примечание: после перезаписи локальных имен производится некоторая особая обработка; смотри ниже. [назад]

5 В настоящее время для MMDF рассматриваются динамические таблицы конфигурации; позволяющие выбыирать при инсталляции выбирать или вкомпиллированые, или динамические таблицы. [назад]

6 MMDF - эквивалентен "программе доставки" для sendmail. [назад]

7 Это соответствует стандарту NBS. [назад]

 

Rambler's Top100 Service Яндекс цитирования