Пособие по Установке и Конфигурированию Sendmail
Все вместе в виде .tgz. (брали более 2500 раз)
SENDMAIL
INSTALLATION AND OPERATION GUIDE
Eric Allman
eric@Sendmail.ORG
Version 8.106
For Sendmail Version 8.8
Перевод Плотникова А.С.
SENDMAIL - Межсетевой почтовый роутер
Eric Allman1
University of California, Berkeley Mammoth Project
Перевод Плотникова АлександраПредисловие переводчика
Это первый документ, который я взялся переводить при моей разборке с sendmail. Супер-точности перевода не гарантирую, но основной смысл я, надеюсь, сумел донести.
Против распространения не возражаю, единственное условие: оставить все как есть, не внося никаких изменений.
Эту и много другой документации вы сможете найти у меня на страничке.
Приму любые конструктивные замечания и предложения, направляйте их на адрес aplotnikov@pisem.net.
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. [назад]
ПРИЛОЖЕНИЕ A
ФЛАГИ КОМАНДНОЙ СТРОКИ
Аргументы должны быть представлены флагами перед адресами. Вот какие бывают флаги:
|
-bx |
Установить режим работы x. Режимы работы таковы: |
|
|
m |
Доставка почты (по умолчанию) |
|
|
s |
На входе говорить на SMTP |
|
|
a |
Режим "Arpanet" (получать информацию о конвертном отправителе из заголовка). |
|
|
d |
Работать в фоне как демон |
|
|
D |
Работать как демон, но не в фоне |
|
|
t |
Работать в тестовом режиме |
|
|
v |
Просто проверять адреса, не собирать и не доставлять |
|
|
i |
Инициализировать базу данных псевдонимов |
|
|
p |
Распечатать почтовую очередь |
|
|
-Btype |
Указывает тип тела. |
|
|
-Cfile |
Использовать другой файл конфигурации. При указании этого флага, sendmail будет работать от запустившего его пользователя (отличного от root). |
|
|
-dlevel |
Устанавливает уровень отладки. |
|
|
-f addr |
Адрес машины отправителя есть addr. |
|
|
-Fname |
Устанавливает полное имя этого пользователя в name. |
|
|
-h cnt |
Устанавливает "счетчик пересылок" равным cnt. Он говорит о том, сколько раз это сообщение было обработано sendmail'ом (в том смысле, что это поддерживается основными сетями). Cnt увеличивается при каждой обработке, и если он достигает значения MAXHOP (в настоящее время 30) sendmail выкидывает сообщение с ошибкой. |
|
|
-n |
Не производить псевдонимизации и пересылки. |
|
|
-N уведомления |
Отмечает все отправленные адреса как хотящие указанных уведомлений, состоящих из слова "NEVER" или списка, разделенного запятыми из слов "SUCCESS", "FAILURE", и "DELAY" для успешной доставки, неудачи, и сообщения застрявшего где-то в очереди. По умолчанию "FAILURE,DELAY". |
|
|
-r addr |
Устарелая форма от -f. |
|
|
-oxзначение |
Установить опцию x в указанное значение. Эти опции описаны в Разделе 5.6. |
|
|
-Oопция=значение |
Установить для опции указанное значение (для длинных имен опций). Эти опции описаны в Разделе 5.6. |
|
|
-Mxзначение |
Установить макрос x в значение. |
|
|
-pprotocol |
Установит протокол отправки. Программы поощряют установку этой опции. Поле протокола может быть в виде protocol:host для указания и протокола отправки, и отсылающего хоста. Например, "-pUUCP:uunet" выставляет протокол отправки UUCP и отправляющий хост uunet. (Некоторые существующие программы используют -oM для выставки макросов r и s; это эквивалентно использованию флага -p.) |
|
|
-qвремя |
Попробовать обработать почту в очереди. Если задано время, sendmail будет обрабатывать почту в очереди через указанный интервал времени, иначе он запустится только один раз. |
|
|
-qXстроку |
Обработать очередь один раз, ограничивая работу теми сообщениями, которые соответствуют Xstring. Ключевая буква X может быть I для ограничений основанных на идентификаторе очереди, R для ограничений основанных на получателе, или S для ограничений основанных на отправителе. Конкретная работа в очереди принимается, если один из соответствующих адресов содержит указанную строку. |
|
|
-R ret |
Информация, возвращаемая при срыве доставки сообщения; ret может быть "HDRS" для заголовков, "FULL" - для заголовков и тела; при этом не требуется, чтобы другой конец принимал этот параметр. |
|
|
-t |
Выбрать из заголовка строки "To:", "Cc:", и "Bcc:", и послать всем в этих списках. Строка "Bcc:" перед отправкой будет уничтожена. Любые адреса из вектора аргументов будут удалены из списка отправки. |
|
|
-U |
Указывает, что это первичное представление User Agent. В будущих выпусках, если этот влаг установлен, sendmail может жаловаться на синтаксически неправильные сообщения вместо их подправки. |
|
|
-V envid |
Указанный envid передается с конвертом сообщения и возвращается при "отскоке" сообщения. |
|
|
-X logfile |
Протоколировать весь трафик, входящий в и выходящий из sendmail в указанный logfile при проблемах отладки почтовых программ. При этом быстро выдается большое количество данных, поэтому эта опция должна использоваться умеренно. |
|
Существует некоторое количество опций, которые могут быть определены как простые флаги. Это опции e, i, m, и v.
Также, опция f может быть определена как флаг -s.
ПРИЛОЖЕНИЕ B
ФОРМАТЫ ФАЙЛОВ ОЧЕРЕДИ
Это приложение описывает формат файлов очереди. Эти файлы живут в каталоге, определенном опцией Q sendmail.cf, обычно /var/spool/mqueue или /usr/spool/mqueue.
Все файлы очереди имеют имена xfAAA99999, где AAA99999 - идентификатор этого сообщения, а x - его тип. Первая буква идентификатора кодирует время дня получения сообщения системой (буква A означает часы между полуночью и 1:00AM). Все файлы с одним идентификатором вместе определяют одно сообщение.
Типы сообщений:
| d | Файл данных. Тело сообщения (исключая заголовок) хранится в этом файле. |
| q | Контрольный файл очереди. Этот файл содержит информацию, необходимую для обработки. |
| t | Временный файл. Это имидж файла qf во время его перестройки. Он должен очень быстро переименоваться в файл qf . |
| x | Файл переписи, существует во время сессии, показывая все, что случается во время этой сессии. |
Файл qf структурируется как последовательность строк, каждая из которых начинается с кодовой буквы. Существуют следующие строки:
| V | Номер версии формата файла очереди, используется для того, чтобы позволить новым бинарникам sendmail читать файлы очереди, созданные более ранними версиями. По умолчанию ноль. Если есть, то должна быть первой строкой в файле. |
| H | Определение заголовка. Таких строк может быть несколько. Порядок их очень важен: Он представляет собой порядок в конечном сообщении. используется тот же синтаксис, как и для определений заголовков в файле конфигурации. |
| C | Контрольный адрес. Синтаксис "localuser:aliasname". Адрес получателя, следующий за этой строкой будет иметь такие флаги, что доставка будет производиться от localuser (имя пользователя из файла /etc/passwd file); aliasname - это имя псевдонима, расширяющегося на этот адрес (используеися для печати сообщений). |
| Q | "Оригинальный получатель", определяемый полем ORCPT= в транзакции ESMTP. Используется только для Уведомлений о Статусе Доставки. Применяется только сразу после строки "R". |
| R | Адрес получателя. Будет по одной строке на каждого получателя. Файлы qf Версии 1 также включают ведущий список флагов, заканчивающийся двоеточием, которые могут быть "S" для возврата сообщения при успешной заключительной доставке, "F" для возврата сообщения при неудаче, "D" для возврата сообщения, если оно отложено, "B" для указания того, что должно быть возвращено тело, "N" для подавления возврата тела, и "P" для декларации этого адреса как "первичного" (primary) (командная строка или сессия SMTP). |
| S | Адрес отправителя. Такая строка может быть только одна. |
| T | Время создания работы. Используется для подсчета истечения таймаута работы. |
| P | Текущий приритет сообщения. Используется для упорядочивания очереди. Более высокие числа означают более низкий приоритет. Во время нахождения сообщения в очереди приоритет изменяется. Изначальный приритет зависит от класса сообщения и его размера. |
| M | Сообщение. Эта строка печатается командой mailq, и обычно используется для хранения информации о статусе. Может содержать любой текст. |
| F | Флаговые биты, одна буква на флаг. Определенные флаговые биты: r - показывает, что это ответное сообщение и w - показывает что было послано сообщение с предупреждением о задержке почты. |
| N | Общее количество попыток доставки. |
| K | Время последней попытки доставки (в секундах с 1 Января 1970г.). |
| I | Идентификационный номер файла данных; может быть использован для восстановления почтовой очереди после катастрофического "падения" диска. |
| $ | Определение макроса. Значения конкретных макросов (во время написания этого документа, только $r и $s) передаваемые во время обработки очереди. |
| B | Тип тела. Конец строки - текстовое описание типа тела. Если это поле отсутствует, тип тела считается "неопределенным" ("undefined") и не производится никакой специальной обработки. Легальные значения "7BIT" и "8BITMIME". |
| O | Оригинальное значение MTS (из транзакции ESMTP). Только для Уведомлений о Статусе Доставки. |
| Z | Оригинальный конвертный идентификатор (из транзакции ESMTP). Только для Уведомлений о Статусе Доставки. |
Например, файл из очереди6 посланный к "eric@mammoth.Berkeley.EDU" и "bostic@okeeffe.CS.Berkeley.EDU":
P835771
T404261372
Seric
Ceric:sendmail@vangogh.CS.Berkeley.EDU
Reric@mammoth.Berkeley.EDU
Rbostic@okeeffe.CS.Berkeley.EDU
H?P?return-path: <owner-sendmail@vangogh.CS.Berkeley.EDU>
Hreceived: by vangogh.CS.Berkeley.EDU (5.108/2.7) id AAA06703;
Fri, 17 Jul 92 00:28:55 -0700
Hreceived: from mail.CS.Berkeley.EDU by vangogh.CS.Berkeley.EDU (5.108/2.7)
id AAA06698; Fri, 17 Jul 92 00:28:54 -0700
Hreceived: from [128.32.31.21] by mail.CS.Berkeley.EDU (5.96/2.5)
id AA22777; Fri, 17 Jul 92 03:29:14 -0400
Hreceived: by foo.bar.baz.de (5.57/Ultrix3.0-C)
id AA22757; Fri, 17 Jul 92 09:31:25 GMT
H?F?from: eric@foo.bar.baz.de (Eric Allman)
H?x?full-name: Eric Allman
Hmessage-id: <9207170931.AA22757@foo.bar.baz.de>
HTo: sendmail@vangogh.CS.Berkeley.EDU
Hsubject: this is an example message
Здесь видно от кого послано это сообщение, время представления сообщения (в секундах с 1 Января1970г.), приоритет сообщения, его класс, получателей, и заголовки для сообщения.
ПРИЛОЖЕНИЕ C
КРАТКОЕ ОПИСАНИЕ СОПРОВОЖДАЮЩИХ ФАЙЛОВ
Это краткое описание сопровождающих файлов создаваемых или генерируемых sendmail'ом. Большинство из них могут быть изменены редактированием файла sendmail.cf; для того, чтобы найти действительные пути к файлам нужно смотреть именно там.
| /usr/sbin/sendmail | Бинарник sendmail. |
| /usr/bin/newaliases | Ссылка на /usr/sbin/sendmail; заставляет перестраивать базу данных псевдонимов. Запуск этой программы полностью равнозначен заданию sendmail флага -bi. |
| /usr/bin/mailq | Распечатывает спок почтовой очереди. Эта программа эквивалентна изпользованию флага -bp в sendmail. |
| /etc/sendmail.cf | Файл конфигурации в текстовом виде. |
| /usr/lib/sendmail.hf | Файл помощи SMTP. |
| /etc/sendmail.st | Файл статистики; его наличие не необходимо. |
| /etc/sendmail.pid | Создается в режиме демона; содержит идентификатор процесса текущего демона SMTP. Если вы используете его в сценариях, используйте "head -1" для получения только первой строки; поздние версииl sendmail могут добавлять информацию в последующие строки. |
| /etc/aliases | Текстовая версия файла псевдонимов. |
| /etc/aliases.{pag,dir} | Псевдонимы в формате dbm(3). |
| /var/spool/mqueue | Каталог, содержащий почтовую очередь и временные файлы. |
| /var/spool/mqueue/qf* | Контрольные (для очереди) файлы сообщений. |
| /var/spool/mqueue/df* | Файлы данных. |
| /var/spool/mqueue/tf* | Времменные версии файлов qf, используемые во время перестроения файла очереди. |
| /var/spool/mqueue/xf* | Описание текущей сессии. |
SENDMAIL
INSTALLATION AND OPERATION GUIDE
Eric Allman
eric@Sendmail.ORG
Version 8.129
For Sendmail Version 8.9
Перевод Плотникова А.С.
Самую последнюю версию этой документации, и не только ее, вы можете найти здесь.
3. АРГУМЕНТЫ
4. Настройка
5. Полное Описание Файла Конфигурации
8. ACKNOWLEDGEMENTS
ПРИЛОЖЕНИЕ A. ФЛАГИ КОМАНДНОЙ СТРОКИ
ПРИЛОЖЕНИЕ B. ФОРМАТЫ ФАЙЛОВ ОЧЕРЕДИ
ПРИЛОЖЕНИЕ C. КРАТКОЕ ОПИСАНИЕ СОПРОВОЖДАЮЩИХ ФАЙЛОВ
Есть два основных шага при установке sendmail. Во-первых, вы должны скомпилировать и установить бинарные файлы. Это будет достаточно просто, если sendmail уже перенесен в вашу операционную систему. Во-вторых, вы должны - построить рабочий файл конфигурации. Это файл читается sendmail при запуске, и в нем описываются все известные ему почтовые программы, как ему анализировать адреса, как переписывать заголовок сообщения, а также настройки различных опций. Хотя файл конфигурации достаточно сложен, обычно конфигурацию можно построить используя основанный на M4 язык конфигурации.
Остаток этого раздела описывает установку sendmail в том случае, если вы используете одну из существующих конфигураций, и можете использовать стандартные параметры установки. Все пути к файлам и примеры заданы от корня поддерева sendmail, для 4.4BSD обычно /usr/src/usr.sbin/sendmail.
Если вы загружаете его с ленты, продолжайте со следующего раздела. Если в вашей системе уже имеется работающий бинарный файл, то вы вполне можете сразу переходить к разделу 1.2.
Все исходные файлы для sendmail находятся в подкаталоге src. Для компиляции sendmail перейдите в каталог src и запустите
./Build
Это оставит бинарные файлы в соответствующе названном каталоге, например obj.BSD-OS.2.1.i386.
Команде Build можно задавать параметры. Во многих случаях они используются только после создания каталога obj.* . Эти команды включают:
|
-L libdirs |
Список каталогов для поиска библиотек |
|
-I incdirs |
Список каталогов для поиска включаемых файлов |
|
-E envar= значение |
Назначить перед компиляцией переменной окружения указанное значение. Обычно используется для выставки ABI в Irix. |
|
-c |
Перед запуском создать новое дерево obj.* |
|
-f siteconfig |
Считать указанный файл конфигурации узла. Если этот параметр не указан, Build включает все файлы из $BUILD-TOOLS/Site/site.$oscf.m4 и $BUILD-TOOLS/Site/site.config.m4 , где $BUILDTOOLS обычно ../BuildTools , а $oscf - то же имя, что используется в каталоге obj.* . Ниже имеется описание файла конфигурации узла. |
|
-S |
Пропустить автоконфигурацию. Build не будет автоматически находить библиотеки. Все библиотеки и определения преобразований должны быть указаны в файле конфигурации узла. |
Все остальные параметры передаются в программу make.
Эта секция еще не готова. Пока что лучше всего смотреть файл BuildTools/README.
XXX Все это должно быть в разделе Файл Конфигурации Узла.
Sendmail поддерживает два различных формата для локальных (находящихся на диске) версий баз данных, в особенности базы данных aliases . По крайней мере, одна из них должна быть определена, если это вообще возможно.
|
NDBM |
Формат "new DBM", доступный в настоящее время почти во всех системах. До 4.4BSD это был предпочтительный формат. Он позволяет такие сложные вещи, как множество баз данных и закрытие открытой на этот момент базы данных. |
|
NEWDB |
Новый пакет базы данных от Berkeley. Если он у вас есть, то используйте его. Он позволяет длинные записи, множество открытых баз данных, кэширование в памяти и многое другое. Вы можете определить его вместе с NDBM; если вы так сделаете, то старые базы данных будут считываться, но когда будет создаваться новая база данных, то она будет уже в формате NEWDB. В случае, если у вас определены NEWDB, NDBM, и NIS, и имя файла aliases будет содержать подстроку "/yp/", при выполнении команды newalias, sendmail создаст и новую и старую версии файла алиасов. Это требуется из-за того, что система Sun NIS/YP считывает версию DBM файла алиасов. Это ужасно, но работает. |
Если ни одна из них не определена, sendmail при каждом запуске будет считывает файл алиасов в память. Этого нужно избегать, так как это может быть достаточно медленно. Существует также несколько методов доступа к удаленным базам данных:
|
NIS |
Sun's Network Information Services (бывший YP). |
|
NISPLUS |
Sun's NIS+ services. |
|
NETINFO |
NeXT's NetInfo service. |
|
HESIOD |
Hesiod service (from Athena). |
Другие флаги компиляции выставляются в conf.h и должны быть предопределены для вас, если только вы не занимаетесь портированием в другую систему.
После описанного выше системного конфигурирования, вы должны скомпилировать и установить систему. Во многих системах лучший для этого способ - сценарий "Build ":
./Build
Он использует uname (1) для выбора подходящего для вашей системы Makefile.
Если вы устанавливаете все на стандартные места, то произвести установку можно с помощью
./Build install
Это должно установить бинарный файл в /usr/sbin и создать связи /usr/bin/newaliases и /usr/bin/mailq с /usr/sbin/sendmail. В системах 4.4BSD это также сформатирует и установит инструкции (man pages).
Sendmail не может работать без файла конфигурации. Конфигурация определяет механизмы доставки почты, понимаемые этим узлом, как перенаправлять почту на удаленные почтовые системы, и многие другие настроечные параметры. Этот файл конфигурации подробнее описан в дальнейших частях этого документа.
Поначалу конфигурация sendmail может напугать и запутать вас. Мир сложен, и почтовая конфигурация - всего лишь его отражение. Комплект поставки включает конфигурационный пакет, основанный на m4, скрывающий большинство из сложностей.
Файлы конфигурации, по сравнению с предыдущими версиями, стали проще, во многом из-за того, что и мир стал проще; в частности, текстовые файлы хостов официально устранены, и теперь нет необходимости "прятать" хосты за зарегистрированным шлюзом в Internet.
Эти файлы также учитывают, что большинство ваших соседей используют UUCP адресацию на основе доменов; что означает, что вместо именования хостов как "host!user" они будут использовать "host.domain!user". Файлы конфигурации могут быть переделаны так, чтобы работать помимо этого, но это намного сложнее.
Наши файлы конфигурации обрабатываются m4 для облегчения внесения локальных изменений; каталог cf в поставке sendmail содержит исходные файлы. Этот каталог содержит несколько подкаталогов:
|
cf |
И зависящие, и не зависящие от узла описания хостов. Это могут быть литерные имена хостов (например, "ucbvax.mc"), если хосты являются шлюзами, или более общие описания (типа "generic-solaris2.mc" - как общее описание хостов, соединенных по SMTP под управлением ОС Solaris 2.x. ). Файлы, имена которых заканчиваются на .mc ("Master Configuration") являются входными описаниями; выходные находятся в соответствующих файлах .cf . Общая структура этих файлов описывается ниже. |
|
domain |
Зависящие от узла описания поддоменов. |
|
feature |
Определения специфических особенностей, которые могут быть нужны какому-либо определенному хосту в вашем узле. На них ссылаются, используя m4 макрос FEATURE. Например - use_cw_file (говорит sendmail считать при запуске файл /etc/sendmail.cw, чтобы найти список локальных имен). |
|
hack |
Локальные особенности. На него ссылаются, используя m4 макрос HACK. Лучше всего не использовать |
|
m4 |
Независимые от узла m4 (1) файлы, содержащие общую для всех конфигурационных файлов информацию. Этот каталог можно рассматривать как каталог "#include". |
|
mailer |
Определения почтовых программ, на которые ссылаются используя m4 макрос MAILER. Типы почтовых программ, известных в этой поставке: fax, local, smtp, uucp, и usenet. Например, чтобы включить поддержку почтовых программ основанных на UUCP, используйте "MAILER(uucp)". |
|
ostype |
Определения, описывающие среды различных операционных систем (например, местонахождения поддерживаемых файлов). На них ссылаются используя m4 макрос OSTYPE. |
|
sh |
Файлы оболочки, используемые процессом постройки m4 . С этим у вас не должно быть проблем. |
|
siteconfig |
Локальная информация о связях UUCP. Этот каталог был замещен mailertable ; все новые конфигурации должны использовать mailertable для осуществления маршрутизации UUCP (и всего остального). |
Если вы в новом домене (т.е., компании), вам, возможно, захочется создать файл cf/domain для вашего домена. В основном он состоит из описаний ретрансляторов (relay definitions) и особенностей, которые бы использовались на всех узлах: например, описание домена Berkeley определяет ретрансляторы для BitNET и UUCP. Они очень специфичны для Berkeley и должны быть доменными именами internet. Пожалуйста, проверьте их приемлемость для вашего домена.
Поддомены в Berkeley также представлены в каталоге cf/domain. Например, домен CS.Berkeley.EDU - поддомен Computer Science, EECS.Berkeley.EDU- поддомен Electrical Engineering and Computer Sciences , а S2K.Berkeley.EDU - это поддомен Sequoia 2000. Возможно, вам захочется добавить соответствующие вашему домену файлы.
Вам нужно будет использовать или создать файлы .mc для ваших хостов в подкаталоге cf/cf . Это детально описано в файле cf/README.
Этот раздел описывает файлы, необходимые для установки sendmail.
Бинарный файл sendmail находится в /usr/sbin1 . Он может иметь бит смены владельца на пользователя root. В целях безопасности, владельцем каталогов /, /usr, и /usr/sbin должен быть root, а их пермиссии должны быть 7552.
Это файл конфигурации для sendmail3. Это единственный не библиотечный файл, имя которого вкомпилировано в sendmail4.
Файл конфигурации обычно создается с использованием описанных выше файлов из поставки. Если у вас необычная конфигурация системы, то, возможно, вам понадобиться создать специальную версию. Формат этого файла более подробно описан в последующих разделах этого документа.
Команда newaliases должна быть всего лишь ссылкой на sendmail:
rm -f /usr/bin/newaliases
ln -s /usr/sbin/sendmail /usr/bin/newaliases
Он должен быть создан там, где его найдет системный путь поиска.
Командаhoststat также должна быть всего лишь ссылкой на sendmail , таким же образом, что и newaliases . Эта команда выдает статус последней почтовой транзакции со всеми удаленными хостами. Флаг -v не даст обрезать показываемый статус. Он работает только если выставлена опция HostStatusDirectory.
Эта команда также является ссылкой на sendmail . Она обнуляет всю информацию, сохраненную в дереве HostStatusDirectory.
Для хранения почтовой очереди должен быть создан каталог /var/spool/mqueue . Этот каталог должен иметь пермиссии 700 и принадлежать пользователю root.
Настоящий путь к этому каталогу определяется оцией Q в файле sendmail.cf.
Это обычное значение опции HostStatusDirectory , содержащей один файл на хост, с которым этот sendmail недавно разговаривал. Обычно это подкаталог mqueue.
Системные псевдонимы содержатся в "/etc/aliases". Пример этого файла имеется в "lib/aliases", в нем имеются некоторые псевдонимы, которые должны быть определены:
cp lib/aliases /etc/aliases
edit /etc/aliases
Вы должны добавить в этот файл любые псевдонимы, необходимые в вашей системе.
Обычно sendmail смотрит на версии этих файлов в виде баз данных, хранящихся и в "/etc/aliases.dir" и в "/etc/aliases.pag" или "/etc/aliases.db", в зависимости от используемой вами пакета баз данных. Путь к этому файлу определяется опцией AliasFile в файле sendmail.cf.
При перезагрузке системы необходимо запускать демон sendmail . Этот демон обеспечивает две функции: он слушает сокет SMTP на случай соединений (чтобы получать почту с удаленных систем), а также периодически обрабатывает очередь, чтобы, как только удаленные хосты станут доступны, доставить на них почту.
Добавьте в ваш "/etc/rc" (или "/etc/rc.local" в зависимости от системы) в то место, где он запускает демоны (для систем на основе BSD) , или в один из файлов запуска, обычно это "/etc/init.d/sendmail" ( в системах на основе System-V), следующие строчки:
if [ -f /usr/sbin/sendmail -a -f /etc/sendmail.cf ]; then
(cd /var/spool/mqueue; rm -f [lnx]f*)
/usr/sbin/sendmail -bd -q30m &
echo -n ' sendmail' /dev/console
fi
Команды "cd" и "rm" здесь даются для того, чтобы гарантировать, что все файлы-замки (lock files) были уничтожены; посторонние файлы-замки могут остаться, если система вдруг "упадет" посреди обработки сообщения. Строка, которая на самом деле запускает sendmail , имеет два флага: "-bd" заставляет его слушать на порту SMTP, а "-q30m" заставляет его производить обработку очереди каждые полчаса.
Некоторые используют более сложный сценарий запуска, удаляющий файлы qf нулевой длины, и файлы df, для которых нет ни одного файла qf. Пример сложного сценария запуска представлен на рис.1.
|
# remove zero length qf files for qffile in qf* do then then rm -f $qffile # rename tf files to be qf if the qf does not exist for tffile in tf* do if [ -r $tffile -a ! -f $qffile ] then mv $tffile $qffile rm -f $tffile # remove df files with no corresponding qf files for dffile in df* do if [ -r $dffile -a ! -f $qffile ] then mv $dffile `echo $dffile | sed 's/d/D/'` # announce files that have been saved during disaster recovery for xffile in [A-Z]f* do |
рис.1 - Комплексный сценарий запуска
Если ваша версия UNIX не поддерживает Berkeley TCP/IP, не включайте флаг -bd.
1.3.10. /usr/lib/sendmail.hf
Это файл помощи, используемый командой SMTP HELP . Он должен быть скопирован из "lib/sendmail.hf":
cp lib/sendmail.hf /usr/lib
Настоящий путь к этому файлу определяется опцией HelpFile в файле sendmail.cf.
Если вы хотите собирать статистику о количестве прошедшей почты, вы должны создать файл "/etc/sendmail.st":
cp /dev/null /etc/sendmail.st
chmod 666 /etc/sendmail.st
Этот файл не увеличивается. Он распечатывается программой "mailstats/mailstats.c." Настоящий путь к этому файлу определяется опцией S в файле sendmail.cf.
Если sendmail запущен как "mailq," то это будет равнозначно запуску sendmail с флагом -bp (т.е., sendmail распечатает содержание почтовой очереди, см далее). Он должен быть ссылкой на /usr/sbin/sendmail.
1. В 4.4BSD и более новых системах это обычно /usr/sbin; многие системы устанвливают его в /usr/lib. И насколько я понимаю это /usr/ucblib в System V Release 4. [назад]
2. Некоторые поставщики поставляют его так, что его владельцем является bin; это может создать дыру в безопасности, которая не связана напрямую с sendmail. Другие каталоги, которые должны иметь ограничения по владельцу и пермиссиям - это /bin, /usr/bin, /etc, /usr/etc, /lib, и /usr/lib. [назад]
3. На самом деле, пути могут различаться, от системы к системе; /etc - наиболее предпочтительный каталог. Некоторые старые системы устанавливают его в /usr/lib/sendmail.cf, и я также видел его в /usr/ucblib и /etc/mail. Если вы хотите поместить его в другое место, добавьте к передаваемым в компилятор флагам флаг D_PATH_SENDMAIL.CF=\"/file/name\". Перемещать этот файл не рекомендуется: другие программы и сценарии знают об этом местонахождении. [назад]
4. Системные библиотеки могут взаимодействовать с другими файлами; в частности, системные библиотечные подпрограммы, вызываемые sendmail, возможно могут обращаться к /etc/passwd и /etc/resolv.conf. [назад]
Системный протокол поддерживается программой syslogd(8). Все сообщения от sendmail протоколируются посредством LOG_MAIL1.
Каждая строка в системном протоколе состоит из временной отметки, имени машины, создавшей ее (для протоколирования с нескольких машин через локальную сеть), слова "sendmail:", и самого сообщения2 . Большинство сообщений являются последовательностью пар имя=значение.
После обработки сообщения обычно протоколируются две строки. Первая отмечает получение сообщения; на каждое сообщение будет ровно одна такая строка. Некоторые поля могут быть пропущены, если они не содержат интересной информации. Поля такие:
| from | Конвертный адрес отправителя |
| size | Размер сообщения в байтах |
| class | Класс (т.е. числовой приоритет) сообщения |
| pri | Начальный приоритет сообщения (используется для сортировки очереди) |
| nrcpts | Количество почтовых получателей для этого сообщения (после обработки псевдонимов и перенаправлений) |
| msgid | Идентификационный номер сообщения (из заголовка) |
| proto | Протокол, использовавшийся при получении этого сообщения (например, ESMTP или UUCP) |
| relay | Машина, от которой было получено сообщение |
На каждую попытку доставки сообщения записываетя еще одна строка (так что каждое сообщение таких строк может быть несколько, например, если оно отложено, или если имеется несколько получателей). Поля в этой строке таковы:
| to | Список получателей для этой почтовой программы, разделенный запятыми. |
| ctladdr | "Контрольный пользователь", то есть, имя пользователя, чьи параметры мы используем при доставке. |
| delay | Общее время задержки между получением и доставкой сообщения. |
| xdelay | Время, понадобившееся для попытки доставки (обычно показывает скорость соединения). |
| mailer | Имя почтовой программы, использовавшейся для доставки к данному получателю. |
| relay | Имя хоста, принявшего сообщение для данного получателя (или отказавшего в доставке). |
| stat | Статус доставки. |
Не все эти поля присутствуют для всех сообщений; например, для локальных сообщений отсутствует поле relay.
Если у вас установлен syslogd(8) или его эквивалент, то вы можете производить протоколирование. Имеется большое количество информации, которое можно запротоколировать. Протокол организован как последовательность уровней. На самом нижнем уровне протоколируются только самые странные ситуации. На самом высоком уровне даже самые обычные и неинтересные события записываются для потомства. Согласно соглашению, уровни протоколирования ниже десятого обычно считаются "полезными"; уровни протоколирования выше 64 зарезервированы для целей отладки. Уровни с 11 по 64 зарезервированы для многословной информации, что могут захотеть некоторые узлы.
Полное описание уровней протоколирования дано в разделе 4.6.
Вы можете попросить sendmail запротоколировать сброс открытых файлов и кэша соединений, послав ему сигнал SIGUSR1. Результаты протоколируются по очередности LOG_DEBUG.
Время от времени sendmail не может обслужить сообщение немедленно. Например, он может быть перегружен, или вообще "упасть", последствием чего будет отказ от соединений. Тогда посылающий хост должен будет сохранить это сообщение в своей почтовой очереди и попытаться доставить его позже.
При нормальных условиях почтовая очередь будет обрабатываться прозрачно. Однако вы можете обнаружить, что иногда необходимо вмешаться руками. Например, если основной хост долгое время отключен, очередь может засориться. Хотя sendmail должен нормально восстановить все при загрузке хоста, тем временем вы можете найти его производительность неприемлемо низкой.
Содержимое очереди можно распечатать, используя команду mailq (или указав sendmail флаг -bp):
Результатом ее выполнения будет список идентификаторов сообщений, находящихся в очереди, размеров сообщений, даты поступления сообщения в очередь, и отправитель с получателями.
Sendmail должен обрабатывать очередь автоматически через определенный интервал. Алгоритм такой: прочитать и отсортировать очередь, а затем обработать все сообщения по порядку. При попытке запустить работу, sendmail сначала проверяет, не заблокирована ли она. Если блокировка имеется, то он игнорирует эту работу.
Не производится ни одной попытки удостовериться в том, что только один обработчик очереди существует в любое время, поэтому нет никакой гарантии, что работа не будет производиться вечно (однако, sendmail имеет некоторую эвристику, чтобы попытаться прекратить работу, занимающую абсурдно большое количество времени; технологически, это нарушает требования RFC 821, но одобряется в RFC 1123). Согласно алгоритму блокировки, одна работа не может заморозить всю очередь. Однако, недружественный принимающий хост, или программа приема, которая никогда ничего не возвращает, может собрать большое количество процессов в вашей системе. К несчастью, нет никакого общего решения для разрешения подобных проблем.
В некоторых случаях, вы можете заметить, что основной хост второй день как упал, и у вас накопилась невероятно большая очередь. В результате sendmail большую часть времени будет проводить, сортируя эту очередь. Эта ситуация может быть исправлена, если вы уберете очередь в какое-то временное место и создадите новую очередь. Старую очередь можно будет обработать позже, когда хост-нарушитель опять начнет работать.
Чтобы это сделать, вполне возможно перенести весь каталог очереди:
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue
Затем вы должны убить работающий демон (потому что он все еще будет продолжать обрабатывать старый каталог очереди) и создать нового демона.
Чтобы обработать старую очередь, запустите следующую команду:
Флаг -oQ определит альтернативный каталог очереди, а флаг -q скажет о том, что нужна всего лишь обработка каждого сообщения в очереди. Если у вас имеется тяга к вуайеризму, вы можете использовать флаг -v, чтобы посмотреть, что будет происходить.
Когда в очереди наконец-то не останется ни одного сообщения, вы сможете удалить этот каталог:
О каждой удаленной системе, с которой было соединение, sendmail сохраняет в памяти большое количество информации. Теперь стало возможным сохранять некоторую часть этой информации на диске, используя опцию HostStatusDirectory , которая может одновременно использоваться несколькими процессами sendmail. Это позволяет немедленно ставить почту в очередь, или пропустить ее при обработке очереди, если недавно было неудачное соединение с удаленной машиной.
Дополнительно, включение опции SingleThreadDelivery даст дополнительный эффект доставки почты к месту назначения одной цепочкой. Это может очень помочь, если на удаленной машине работает сервер SMTP, который легко перегружается, или может работать только с одним соединением за раз. Она применяется ко всем хостам, поэтому установите ее, если на вашем узле для доставки почты используется одна машина, на которой работает дополнительное программное обеспечение, увеличивающее загрузку машины, что может привести к замедлению доставки почты на другие хосты. Установите эту опцию, если вы имеете на вашем узле одну почтовую машину, и на ней еще работают приложения, которые могут увеличить ее загрузку, замедлив обработку почты. Если эта опция выставлена, то вам, возможно, захочется выставить опцию MinQueueAge, чтобы ваша очередь обрабатывалась достаточно часто; в результате работы, пропущенные по причине того, что другой процесс sendmail разговаривал с тем же хостом, вскоре были опробованы снова, а не отложены на долгое время.
Информация о хостах сохраняется на диске в подкаталоге .hoststat3 каталога mqueue. Удаление этого каталога с его подкаталогами равносильно команде purgestat и вполне безопасно. Информация из этих каталогов может быть просмотрена командой hoststat, которая покажет имя хоста, последний доступ и статус этого доступа. Звездочка в самой левой колонке означает, что процесс sendmail в настоящее время имеет блокировку на доставку почты на этот хост.
В целях оптимизации таймаутов, информация, сохраняемая на диске, обслуживается таким же образом, что и информация, хранимая в памяти. По умолчанию, информация об ошибках хостов действительна в течение 30 минут. Это значение может быть изменено опцией Timeout.hoststatus.
Информация о соединении, сохраненная на диске, может быть очищена в любой момент командой purgestat, или запуском sendmail с ключом -bH. Информацию о соединении можно просмотреть командой hoststat, или запуском sendmail с ключом -bh.
Реализация системных сервисов, таких, как определение имени хоста и пользователя управляется сервисным переключателем. Если операционная система хоста поддерживает такой переключатель, то sendmail будет использовать родную версию. Ultrix, Solaris, и DEC OSF/1 - примеры таких операционных систем. И хотя HP-UX 10 имеет поддержку сервисного переключателя, но, так как API не поддерживается библиотеками, sendmail в этот раз не использует родной сервисный переключатель.
Если операционная система не поддерживает сервисный переключатель (например, SunOS, HP-UX, BSD), то sendmail будет использовать свою реализацию. Опция ServiceSwitchFile указывает на имя файла, содержащего определения сервисов. Каждая строка содержит имя сервиса и возможные реализации этого сервиса. Например, файл:
попросит sendmail просматривать имена хостов сначала в Domain Name System. Если запрошенное имя хоста не найдено, он попробует локальные файлы, если и там не найдет, то попробует NIS. Точно также, при просмтре псевдонимов, сначала он попробует локальные файлы, а затем NIS.
Сервисные переключатели не полностью интегрированы. Например, несмотря на то, что в вышеописанном примере имя хоста необходимо смотреть в NIS, в SunOS этого не произойдет, из-за того, что системная реализация gethostbyname(3) не понимает этого. Если имеется достаточно причин, sendmail может использовать свои реализации gethostbyname(3), gethostbyaddr(3), getpwent(3), и других системных подпрограмм, которые необходимы для его нормальной работы.
После получения адресов получателей из соединения SMTP или командной строки, они обрабатываются согласно набору правил 0, которые должны определить тройку {mailer, host, user}. Если флаги выбранные mailer'ом включают флаг A (aliasable), часть тройки user рассматривается как ключ (т.е., левосторонняя) в базе данных псевдонимов (aliases). Если имеется совпадение, адрес удаляется из очереди на отсылку, а все адреса с правой стороны псевдонима добавляются вместо найденного псевдонима. Эта операция является рекурсивной, поэтому псевдонимы, найденные в правосторонней части псевдонима обрабатываются таким же образом.
База данных псевдонимов существует в двух видах. Один - текстовая форма, содержащаяся в файле /etc/aliases. Псевдонимы имеют следующий вид
Только локальные имена могут быть псевдонимизированы; например,
не возымеет ожидаемого эффекта (если это не на prep.ai.MIT.EDU, но я им точно не нужен)4.Псевдонимы могут быть продолжены началом любых строк-продолжений с пробелом или табуляцией. Пустые строки и строки, начинающиеся со знака диез ("#") считаются комментариями.
Вторая форма обрабатывается библиотекой ndbm(3)5. Эта форма находится в файлах /etc/aliases.db (если используется NEWDB) или /etc/aliases.dir и /etc/aliases.pag (если используется NDBM). Эта именно та форма, которую использует sendmail при определении псевдонимов. Эта технология используется для увеличения производительности.
Управление порядком поиска выставляется непосредственно сервисным переключателем. По существу, вхождение
всегда добавляется как первое вхождение псевдонимов; также, первое имя файла псевдонимов без класса (например, без "nis:" вначале) будет использовано как имя файла для вхождения "files" в переключателе псевдонимов. Например, если конфигурация содержит
а сервисный переключатель содержит
то псевдонимы будут сначала искаться в базе данных NIS, затем в /etc/aliases, а затем в базе данных NIS+.
Вы также можете использовать файлы псевдонимов на основе NIS. Например, определение:
OAliasFile=nis:mail.aliases@my.nis.domain
будет сначала искать файл /etc/aliases, а затем карту с именем "mail.aliases" в "my.nis.domain". Внимание: если вы строите свой собственный файл псевдонимов на основе NIS, обязательно поставьте флаг -l для makedbm(8) для преобразования заглавных букв в ключах в строчные; иначе псевдонимы с заглавными буквами в именах не будут совпадать с входящими адресами.
Дополнительные флаги могут быть добавлены после двоеточия, точно как строка K; например:
будет искать соответствующую карту NIS и всегда иметь ноль байт в ключе. Также
удержит sendmail от преобразования ключа в символы нижнего регистра перед просмотром псевдонимов.
Версия базы данных в виде hash или dbm может быть перестроена выполнением команды
Это эквивалентно заданию sendmail флага -bi:
Если в конфигурации определена опция RebuildAliases (раннее D), sendmail будет перестраивать базу данных псевдонимов автоматически, если она может быть старой. Автоматическая перестройка может быть опасной на сильно загруженных машинах с большими файлами псевдонимов; если перестроение базы займет больше чем таймаут перестройки базы (опция AliasWait, ранее a, нормальное значение которой равно пяти минутам), то вполне возможно, что будут запущены одновременно несколько процессов перестройки.
Если вы определили несколько баз данных псевдонимов, флаг -bi перестроит все типы баз данных, которые он понимает (например, он может перестраивать базы данных NDBM, но не может базы данных NIS).
Существует несколько проблем, которые могут случиться с базой данных псевдонимов. Все они происходят из того, что процесс sendmail может начать использовать DBM-версию псевдонимов, когда она будет построена только частично. Это может случиться при двух условиях: один процесс использует базу данных, в то время как второй ее перестраивает, или процесс, занимающийся перестройкой базы данных, умирает (из-за того, что его убили, или система вдруг упала) до полного завершения перестройки.
Sendmail имеет три метода, чтобы попытаться избавиться от этих проблем. Первый - он игнорирует прерывания во время перестройки базы данных; это позволяет избежать случая, когда кто-нибудь прекращает процесс, оставляя частично перестроенную базу данных. Второй - он блокирует исходный файл базы данных во время перестройки - но это может не работать поверх NFS или если файл защищен на запись. Третий - в конце перестройки он добавляет псевдоним в виде
(что вообще-то нелегально). Перед тем, как sendmail будет использовать базу данных, он произведет проверку на наличие этого вхождения6.
Если при посылке на определенный адрес, скажем ,"x", произойдет ошибка, sendmail будет искать псевдоним вида "owner-x" для получения ошибки. Это обычно полезно для списков рассылки, где подписчик сам не имеет управления поддержкой списка; в этом случае, держатель списка может быть владельцем списка. Например:
owner-unix-wizards: unix-wizards-request
unix-wizards-request: eric@ucbarpa
заставит "eric@ucbarpa" получать ошибки, которые произойдут, когда кто-нибудь посылает в unix-wizards и попадает под вхождение "nosuchuser" в списке.
Владельцы списков также изменяют почтовый адрес отправителя. Используется содержимое псевдонима владельца, если оно указывает на одного пользователя, иначе будет использоваться само имя псевдонима. По этой причине, и в соответствии с соглашениями Internet, адрес "owner-" обычно указывает на адрес "-request"; это позволяет сообщениям следовать типичным соглашениям Internet об использовании "listrequest" как обратный адрес.
Если вы имеете версию sendmail с вкомпиллированной базой данных пользовательской информации, и определили одну или несколько баз данных используя опцию U, базы данных будут просмотрены в поисках вхождения user:maildrop. Если такое будет найдено, почта будет послана по указанному адресу.
Как альтернативу базе данных псевдонимов, каждый пользователь может создать в своем домашнем каталоге файл с именем ".forward". Если такой файл существует, sendmail перенаправляет почту для этого пользователя по списку адресов, указанных в файле .forward. Например, если домашний каталог пользователя "mckusick" содержит файл .forward содержащий:
kirk@calder
то любая почта, поступившая для "mckusick" будет перенаправлена по указанным адресам.
На самом деле, файл конфигурации определяет последовательность проверяемых имен файлов. По умолчанию, это пользовательский файл .forward, но может быть определен по-другому, используя опцию ForwardPath. Если вы ее измените, вы должны будете проинформировать ваших основных пользователей об изменении; .forward очень хорошо вошло в коллективное подсознание.
Несколько строк заголовка имеют особые интерпретации, определенные файлом конфигурации. Остальные имеют интерпретации, которые встроены в sendmail и не могут быть изменены без изменения кода. Здесь описаны эти встроенные интерпретации.
Если во время обработки происходит ошибка, этот заголовок заставит отослать сообщение об ошибке по указанному адресу. Это предназначено для списков рассылки.
Заголовок Errors-To: был создан в плохие старые времена, когда UUCP не понимал различий между содержимым и заголовком; Это было встроено для того, чтобы указать, что должно быть теперь пропущено как адрес отправителя сообщения. Это должно уйти, но пока еще используется, если выставлена опция UseErrorsTo.
Заголовок Errors-To: официально уже убран, и в последующих выпусках должен отсутствовать.
RFC 822 требует в каждом сообщении иметь по крайней мере одно поле получателя (строку To:, Cc:, или Bcc:). Если сообщение приходит без указания какого-либо получателя в сообщении, sendmail добавит заголовок на основе опции "NoRecipientAction". Одним из возможных действий будет добавка в заголовок строки "Apparently-To:" для каждого получателя, о котором он знает.
Заголовок Apparently-To: не стандартен и удален.
Заголовок Precedence: может быть использован как грубое управление приоритетом сообщения. Он перестраивает порядок в очереди и может быть сконфигурирован на изменение значений таймаутов для сообщения.
Sendmail поддерживает протокол IDENT, определенный в RFC 1413. Хотя это улучшает идентификацию автора сообщения в электронной почте посредством производства "обратного звонка" в систему, откуда исходит сообщение для определения владельца соединения, это не идеально; протокол IDENT можно достаточно легко обмануть. Следующее описание было взято из RFC 1413:
6. Положения Безопасности
Информации, возвращаемой этим протоколом можно доверять настолько, насколько можно доверять хосту ИЛИ организации, в которой находится этот хост. Например, PC в открытой лаборатории имеет немного, если вообще имеет вообще что-либо запрещающее пользователю указать этому протоколу возвращать любой идентификатор, какой он захочет. Точно так же, если хост был скомпрометирован, возвращаемая им информация может быть полностью ошибочна и неверна.
Протокол Идентификации не предназначен для авторизации или управления доступом. В лучшем случае, он обеспечивает некоторую дополнительную проверочную информацию в отношении соединения TCP. В худшем, он обеспечит дезориентирующую, неверную или злобно некорректную информацию.
Использование информации, полученной из этого протокола для чего-либо иного, чем удостоверение, очень не советуется. В особенности, использование Идентификационного Протокола для выноса решений о доступе - как в качестве главного метода (т.е. единственной проверки) так и в качестве дополнения к другим методам может привести к ослаблению нормальной безопасности хоста.
Сервер Идентификации может обнаружить информацию о пользователях, сущностях, объектах или процессах, которая обычно может быть рассмотрена как конфиденциальная. Сервер Идентификации обеспечивает сервис, являющийся грубым аналогом сервисов CallerID, обеспечиваемых некоторыми телефонными компаниями, а многие из таких же частных определений и аргументов, применяемых в сервисе CallerID, подходят к Идентификации. Если вы не будете запускать сервер "finger" по причинам сохранения тайны, то вы можете не захотеть использовать этот протокол.
В некоторых случаях ваша система может не работать нормально с поддержкой IDENT из-за ошибки в реализации TCP/IP. Симптомы будут таковы: для некоторых хостов соединение SMTP будет закрываться почти емедленно. Если это действительно так происходит, или вы не хотите использовать IDENT, вы должны установит таймаут IDENT равным нулю; это отключит протокол IDENT.
1. Кроме Ultrix, не поддерживающего в syslog различные средства. [назад]
2. Этот формат может быть немного другим, если ваш поставщик изменил синтаксис. [назад]
3. Это обычное значение опции HostStatusDirectory; конечно же, если вы этого захотите, она может указывать на любое место в вашей файловой системе. [назад]
4. На самом деле, любая почтовая программа, имеющая выставленный почтовый флаг "A" будет позволять псевдонимизирование; обычно это ограничено локальной почтовой программой. [назад]
5. Пакет gdbm не работает. [назад]
6. Для того, чтобы можно было произвести это действие, в файле конфигурации требуется опция AliasWait. Обычно она должна быть определена. [назад]
Полный список аргументов для sendmail детально описан в Приложении A. Некоторые важные аргументы описаны здесь.
Количество времени между разветвлением процесса для обработки очереди определяется флагом -q. Если вы работаете в режиме приема, назначенного i или b, то это значение может быть относительно большим, как и в том случае, если ваш хост долго был отключен. Если вы запускаете sendmail в режиме q, то это значение должно быть относительно небольшим, потому что оно определяет максимальное время нахождения сообщения в очереди. (Смотри также опцию MinQueueAge.)
Секция 5.3.1.1 RFC 1123 говорит, что это значение должно быть как минимум 30 минут (но, если вы работаете в режиме "queue-only", то это не важно).
Если вы позволяете принимать почту через соединение IPC, у вас должен работать демон. Он должен запускаться из файла /etc/rc с флагом -bd. Флаги -bd и -q могут быть скомбинированы в одном вызове:
В качестве альтернативы можно запускать sendmail из inetd(8) (используя флаг -bs, чтобы сказать sendmail использовать SMTP на его стандартном вводе и выводе). Это будет работать и позволит вам завернуть sendmail в программу обработки TCP, но может быть несколько медленнее из-за того, что файл конфигурации будет перечитываться при получении любого входящего сообщения. Если вы так сделаете, то вам все равно понадобится работающий sendmail для обработки очереди:
В некоторых случаях, вы можете заметить, что по какой-либо причине ваша очередь застряла. Вы можете ускорить очередь, используя флаг -q (без значения). При этом очень интересно использовать флаг -v (verbose), чтобы посмотреть, что будет происходить:
Вы также можете ограничить количество работ с определенным идентификатором очереди, отправителем или получателем, используя один из модификаторов очереди. Например, "-qRberkeley" ограничит работу по обработке очереди только сообщениями со строчкой "berkeley" в любом из адресов получателей. Точно также, "-qSstring" ограничит обработку сообщениями с определенными отправителями, а "-qIstring" ограничит ее конкретными идентификаторами очереди.
Существует большое количество втроенных в sendmail флагов отладки. Каждый флаг отладки имеет номер и уровень, где большие уровни означают большее количество выдаваемой информации. Существует соглашение, что уровни выше девятого "абсурдны", то есть, они выдают так много информации, что обычно вы ее даже не захотите увидеть, за исключение отладки конкретного куска кода. Флаги отладки выставляются опцией -d; синтаксис таков:
| debug-flag: | -d debug-list |
| debug-list: | debug-option [ , debug-option ]* |
| debug-option: | debug-range [ . debug-level ] |
| debug-range: | integer | integer - integer |
| debug-level: | integer |
где пробелы используются только для облегчения чтения. Например,
| -d12 | Выставляет флаг 12 на уровень 1 |
| -d12.3 | Выставляет флаг 12 на уровень 3 |
| -d3-17 | Выставляет флаги с 3 по 17 на уровень1 |
| -d3-17.4 | Выставляет флаги с 3 по 17 на уровень 4 |
Для полного списка доступных отладочных флагов, вы должны посмотреть в исходный код (они слишком динамичны, чтобы быть отраженными в этой документации).
Опции могут быть преодолены использованием в командной строке флагов -o или -O. Например,
выставляет опцию T (таймаут) на две минуты только для этого запуска; эквивалентная строка, использующая длинное имя опции такова:
Некоторые опции имеют ограничения по безопасности. Sendmail позволяет вам выставить их, но с этого момента убирает свои пермиссии смены uid на root 1.
Альтернативный файл конфинурации может быть определен флагом -C; например,
использует файл конфигурации test.cf вместо обычного /etc/sendmail.cf. Если флаг -C не имеет значения, то по умолчанию он использует файл sendmail.cf в текущем каталоге.
Когда вы используете этот флаг, sendmail не использует пермиссии смены uid на root, поэтому обычно, во время тестирования, для каталога подкачки используют каталог, который открыт всем на запись (типа /tmp) (опция QueueDirectory или Q).
Многие реализации SMTP не полностью реализуют протокол. Например, некоторые SMTP для персональных компьютеров не понимают строк-продолжений в кодах возврата. Это может быть очень трудно отследить. Если вы подозреваете такую проблему, вы можете включить протоколирование траффика, используя флаг -X. Например,
будет вести протокол всего траффика в файле /tmp/traffic.
Это протоколирует большое количество данных очень быстро, и при нормальной работе вы НИКОГДА не должны ее использовать. После запуска такого демона, заставьте странную реализацию послать сообщение на ваш хост. Весь траффик сообщений из и в sendmail, включая входящий траффик SMTP, будет запротоколирован в этом файле.
При построениии таблицы конфигурации, вы можете произвести некоторое тестирование, используя "тестовый режим" sendmail. Например, вы можете запустить sendmail так:
что заставит sendmail прочитать файл конфигурации "test.cf" и войти в тестовый режим. В этом режиме, вы вводите строки типа:
где rwset - набор правил перезаписи, который вы хотите использовать, а address - это адрес, к которому вы хотите его применить. Тестовый режим покажет вам шаги при обработке, показав в конце окончательно полученный адрес. Вы можете использовать список правил перезаписи, разделенный запятыми, для последовательного применения на входе. Например:
сначала применит набор правил три на адрес "monet:bollard." Затем к выходу набора правил три будет применен набор правил один, затем точно также наборы правил двадцать один и четыре.
Если вам нужна большая детализация, вы можете также использовать флаг "-d21" для включения режима отладки. Например,
включит невероятное количество информации; адрес из одного слова может выдать в результате несколько страниц нужной информации.
Необходимо предупредить, что внутренне sendmail применяет набор правил 3 ко всем адресам. В тестовом режиме, вы должны делать это вручную. Например, старые версии позволяли вам использовать
Эта версия требует, чтобы вы использовали:
Начиная с версии 8.7, в тестовом режиме стали доступны и некоторые другие вещи:
| +o .Dxзначение | Указывает макросу x иметь указанное значение. Это полезно, когда отлаживаемые правила используют синтаксис $&x. |
| +o .Ccзначение | Добавляет указанное значение к классу c. |
| +o .Sнабор_правил | Распечатывает содержимое указанного набора правил. |
| +o -ddebug-spec | Эквивалентно флагу командной строки. |
При включенном HostStatusDirectory, информация о статусе хостов находится на диске, и поэтому может быть использована одновременно несколькими процессами sendmail. Статус последнего соединения с каждым удаленным хостом может быть просмотрен командой:
Эта информация может быть обнулена командой:
Опустошение информации предотвращает ее загрузку новыми процессами sendmail, но не обнуляет уже имеющуюся у запущенных процессов информацию о статусе.
1. То есть, он выставляет свой эффективный uid соответственно настоящему uid; таким образом, если вы запускаете его как root, или из root'овского файла crontab, или во время запуска системы, пермиссии root будут учтены. [назад]
В зависимости от потребностей вашего узла, вы можете захотеть изменить те или иные конфигурационные параметры. Большинство из них устанавливаются опциями в файле конфигурации. Например, строка "O Timeout.queuereturn=5d" устанавливает опции "Timeout.queuereturn" значение "5d" (пять дней).
Многие из этих опций имеют такие значения по умолчанию, которые подходят к большинству узлов. Однако, на узлах с большой почтовой нагрузкой может понадобиться некоторая соответствующая настройка под их почтовую загрузку. В частности, на узлах, через которые проходит большое количество небольших почтовых сообщений, доставляемых многим получателям, может понадобиться подправить параметры, связанные с приоритетами очереди.
Все версии sendmail до 8.7 имели имена опций, состоящие из одного символа. С 8.7, опции имеют длинные (состоящие из нескольких символов) имена. Хотя старые короткие имена до сих пор принимаются, многие новые опции не имеют коротких эквивалентов.
Этот раздел описывает только те опции, которые вам, вероятно, захочется изменить; более детальное описание опций дано в разделе 5.
Все временные интервалы устанавливаются с использованием масштабного синтаксиса. Например, "10m" означает десять минут, в то время как "2h30m" означает два с половиной часа. Вот полный набор масштабов:
s |
Секунды |
m |
Минуты |
h |
Часы |
d |
Дни |
w |
Недели |
Аргумент для флага -q определяет, как часто поддемон будет обрабатывать очередь. Обычно это значение меняется от пятнадцати минут до одного часа. Секция 5.3.1.1 RFC 1123 рекомендует устанавливать его равным как минимум 30 минутам.
Все таймауты имеют имена типа "Timeout.подопция". Все распознаваемые подопции, их значения по умолчанию, и минимальные значения, позволяемые секцией 5.3.2 RFC 1123 таковы:
| connect | Время ожидания открытия SMTP соединения (системный вызов connect(2)) [0, неопределенное]. Если оно равно нулю, то используется значение из ядра системы. Эта опция ни в каком случае не может иметь значение больше, чем это позволяет ядро, но может быть меньше. Это сделано, чтобы обойти ядра, позволяющие абсурдно длительный таймаут соединения (в некоторых случаях 90 минут). |
| iconnect | То же самое, что connect, кроме того, что оно применяется только для первичной попытки соединения с хостом для заданного сообщения [0, неопределенное]. Концепция такова: это значение должно быть очень небольшим (несколько секунд); хосты с хорошим соединением и отвечающие хосты, таким образом, будут обслужены немедленно. Медленные хосты не будут задерживать остальные доставки на стадии начальной попытки доставки. |
| initial | Ожидание начального приветственного сообщения 220 [5m, 5m]. |
| helo | Ожидание ответа на команду HELO или EHLO [5m, неопределенное]. Это может потребовать просмотра имени хоста, поэтому пять минут, возможно, вполне приемлемый минимум. |
| mail| | Время ожидания ответа на команду MAIL [10m, 5m]. |
| rcpt| | Время ожидания ответа на команду RCPT [1h, 5m]. Это значение должно быть большим, из-за того, что оно может указывать на список, и его расширение может занять много времени (смотри ниже). |
| datainit| | Время ожидания ответа на команду DATA [5m, 2m]. |
| datablock| | Ожидание прочтения блока данных (то есть, тела сообщения). [1h, 3m]. Это значение должно быть большим, потому что оно также применяется к программам, которые могут достаточно медленно выводить данные в sendmail. |
| datafinal| | Время ожидания ответа на точку, завершающую сообщение. [1h, 10m]. Если это значение короче, чем время, необходимое получателю для получения сообщения, будет сделана повторная передача. Это описывается в RFC 1047. |
| rset | Время ожидания ответа на команду RSET [5m, неопределенное]. |
| quit | Время ожидания ответа на команду QUIT [2m, неопределенное]. |
| misc | Время ожидания ответа на различные (но короткие) команды, типа NOOP (нет операции) и VERB (переход в подробный режим). [2m, неопределенное]. |
| command| | Для сервера SMTP, время ожидания следующей команды. [1h, 5m]. |
| ident | Время ожидания ответа на запрос IDENT [30s1, неопределенное]. |
| hoststatus | Сколько времени информация о хосте (например, о том, что он отключен) будет кэширована, прежде чем она устареет [30m, неопределеное]. |
Для совместимости со старыми файлами конфигурации, если ни одна подопция не определена, таймауты обозначенные знаком | устанавливаются равными указанному значению.
Многие из минимальных значений в RFC 1123 слишком малы. Sendmail был разработан для протоколов RFC 822, которые не определяют таймауты чтения; следовательно, версии sendmail до 8.1 не гарантируют быстрого ответа на сообщения. В частности, команда "RCPT" определяющая список рассылки будет расширена и проверит весь список полностью; большой список на медленной системе может запросто занять времени больше, чем пять минут2. Я рекомендую таймаут в один час - так как обрыв соединения во время фазы RCPT достаточно редки, длительный таймаут не обременителен, но может сильно помочь в уменьшении загрузки сети и повторных сообщений.
Например, строки:
O Timeout.datablock=3h
Устанавливает серверу SMTP таймаут на команды 25 минут и таймаут на ввод блока данных 3 часа.
Если сообщение будет находиться в очереди несколько дней, то время его обработки закончится. Это делается для того, чтобы быть уверенным, что отправитель, по крайней мере, предупрежден о невозможности доставки сообщения. Обычно таймаут равен пяти дням. Иногда удобно также посылать предупреждение, если сообщение находится в очереди на протяжении нескольких часов (подразумевается, что обычно у вас хорошая связь; если же обычно отсылка ваших сообщений занимает несколько часов, то вам не захочется получать такие сообщения, так как это вполне нормальное событие). Эти таймауты выставляются опциями Timeout.queuereturn и Timeout.queuewarn в файле конфигурации (раньше оба значения выставлялись опцией T).
Так как эти опции глобальны, и вы не знаете заранее, сколько времени хост вне вашего домена будет отключен, рекомендуемый таймаут составляет пять дней. Это позволяет получателю исправить проблему, даже если она случилась в самом начале длительных выходных. Секция 5.3.1.1 RFC 1123 говорит, что этот параметр должен быть "как минимум 4-5 дней".
Значение Timeout.queuewarn может быть вложено в опцию T указанием времени, по истечении которого должно быть послано предупреждение; два таймаута разделяются слешем. Например, строка
говорит о том, что посылка сообщения должна быть прекращена через пять дней, а предупреждение должно быть послано через четыре часа. Это значение должно быть достаточно большим, чтобы несколько раз попытаться доставить сообщение.
Указанием опции ForkEachJob (Y), можно заставить sendmail ветвиться перед каждым отдельным сообщением во время прохода очереди. Это защитит вас от потребления sendmail большого количества памяти, что очень полезно, если у вас не очень много памяти. Однако если опция ForkEachJob не выставлена, sendmail во время прохода очереди будет помнить об отключенных хостах, что может повысить производительность системы.
Если опция ForkEachJob не выставлена, sendmail не может использовать кэшированные соединения.
Каждому сообщению при первичной обработке назначается приоритет, состоящий из размера сообщения (в байтах) минус класс сообщения (определяемый из заголовка Precedence:) умноженный на "рабочий коэффициент класса" и количества получателей, умноженного на "рабочий коэффициент получателя". Приоритет используется для построения порядка очереди. Более высокое значение приоритета подразумевает, что сообщение будет обработано позднее при проходе очереди.
Размер сообщения здесь используется для того, чтобы более большие сообщения обрабатывались после относительно небольших. Класс сообщения позволяет пользователям посылать "высокоприоритетные" сообщения включая поле "Precedence:" в свои сообщения; Значение этого поля просматривается в строках P файла конфигурации. Вследствие того, что количество получателей сообщения может влиять на загрузку, оно также включено в приоритет.
Коэффициенты получателя и класса могут быть установлены в файле конфигурации, используя опции RecipientFactor (y) и ClassFactor (z) соответственно. По умолчанию, они равны: 30000 (для коэффициента получателя) и 1800 (для коэффициента класса). Первичный приоритет таков:
pri = msgsize - (class умноженный на ClassFactor) + (nrcpt умноженное на RecipientFactor)
(Запомните, более высокое значение этого параметра на самом деле означает, что работа будет обработана с низким приоритетом.)
Приоритет работы скорректирован при каждой обработке сообщения (то есть, при каждой попытке его доставки) использованием "рабочего коэффициента времени", установленного опцией RetryFactor (Z). Он добавляется к приоритету, поэтому обычно он уменьшает старшинство работы, на основании того, что работа, не выполненная много раз, вполне может быть не выполнена опять. Опция RetryFactor по умолчанию равна 90000.
Sendmail можно попросить принимать и откладывать в очередь (но не доставлять) почту, если средняя загрузка системы становиться слишком большой. Для этого используется опция QueueLA (x). Когда средняя загрузка системы превышает значение опции QueueLA, устанавливается режим q (только очередь), если опция QueueFactor (q) деленная на разность средней загрузки системы и значения опции QueueLA плюс единица, превысит приоритет сообщения - то есть, сообщение откладывается в очередь, если, и только если:
pri > { QueueFactor } / { LA - { QueueLA } + 1 }
По умолчанию опция QueueFactor равна 600000, так что каждая единица средней загрузки стоит 600000 пунктов приоритета (как описано выше).
Для крутых случаев, опция RefuseLA (X) определяет среднюю загрузку, при которой sendmail будет отказываться принимать сетевые соединения. Локально созданная почта (включая входящую почту UUCP) будет приниматься.
Существует большое количество режимов доставки, в которых может работать sendmail, указанных конфигурационной опцией DeliveryMode (d). Эти режимы определяют, как быстро почта будет доставлена. Доступные режимы:
i |
Интерактивная доставка (синхронная) |
b |
Доставка в фоне (асинхронная) |
q |
Только очередь (не доставлять) |
d |
Отложить попытку доставки (не доставлять) |
Есть и компромиссы. Режим "i" дает отправителю быстрейшую обратную связь, но может замедлить некоторые почтовые программы намного больше необходимого. Режим "b" доставляет быстро, но может наплодить кучу процессов, если ваша почтовая программа тратит много времени на доставку сообщений. Режим "q" минимизирует загрузку вашей машины, но доставка сообщений будет задержана до наступления очередного интервала. Режим "d" идентичен режиму "q", за исключением того, что он также предотвращает работу всех просмотров; он предназначен для узлов "dial on demand", где просмотр DNS может стоить реальные деньги. Некоторые простые сообщения об ошибках (например, host unknown during the SMTP protocol) в этом режиме будут задержаны. По умолчанию обычно используется режим "b".
Если вы запускаете sendmail в режиме "q" (только очередь), "d" (отсрочка), или "b" (доставка в фоне), то он не будет разворачивать псевдонимы и следовать файлам .forward, вплоть до первого получения почты. Это ускоряет ответ на команду RCPT. Режим "i" не может быть использован сервером SMTP.
Sendmail'у может быть указан уровень протоколирования. По умолчанию стандартной таблицей конфигурации используется уровень 9. Имеются следующие уровни:
0 |
Минимальный протокол |
1 |
Серьезные системные ошибки и потенциальные проблемы безопасности |
2 |
Потери соединений (сетевые проблемы) и ошибки протокола |
3 |
Другие серьезные ошибки, неправильные адреса, временные ошибки forward/include, таймауты соединений. |
4 |
Несущественные неисправности, устаревание базы данных псевдонимов, отказы соединений из-за проверочных наборов правил (check_rulests) |
5 |
Статистика сбора сообщений |
6 |
Создание сообщений об ошибках, командах VRFY и EXPN. |
7 |
Ошибки доставки (хост или пользователь не известен и т.д.) |
8 |
Успешные доставки и перестроения базы псевдонимов. |
9 |
Отложенные сообщения (из-за того, что хост отключен и т.д.) |
10 |
Расширение базы данных (просмотры псевдонимов, перенаправлений и пользователей) |
11 |
Ошибки NIS и окончание обработок |
12 |
Протоколирование всех соединений SMTP. |
13 |
Протоколирование плохих пользовательских оболочек, файлов с несоответствующими пермиссиями, и других спорных ситуаций. |
14 |
Протоколирование всех отказов от соединений |
15 |
Протоколирование всех входящих и исходящих команд SMTP. |
20 |
Протоколирует попытки обработки заблокированных файлов в очереди. Это не ошибки, но может быть полезно, если ваша очередь становится перегруженной. |
30 |
Потерянные блокировки (только если вы используете lockf вместо flock). |
Дополнительно, значения выше 64 зарезервированы для очень болтливого вывода при отладке. Никто в здравом уме не поставит такой уровень.
Режимы, используемые для файлов, зависят от желаемой функциональности и требуемого уровня безопасности. Во многих случаях sendmail производит осторожную проверку режимов доступа к файлам и каталогам, во избежание различных опасных ситуаций; если вам нужно, чтобы группа имела разрешение на запись в поддерживающие файлы, то вам нужно использовать опцию DontBlameSendmail для отключения некоторых из этих проверок.
Sendmail может вполне безопасно сделан setuid на root. Тогда, когда он собирается запустить с помощью exec(2) почтовую программу, он проверяет, равен ли userid нулю; если равен, то он переустанавливает userid и groupid на значения по умолчанию (выставляемые равенством U= в строке почтовой программы; если это равенство не установлено, используется опция DefaultUser). Это может быть преодолено выставкой флага S у почтовой программы для доверенных почтовых программ, которые могут быть запущены от root. Однако, это заставит обработку почты быть засчитанной sa(8) как потребление пользователем root системных ресурсов, вместо того, чтобы засчитать это пользователю, посылающему почту.
Если вы не делаете sendmail setuid'ным на root, он все равно будет работать, но вы потеряете большиую часть функциональности и конфиденциальности, а так же вам придется открыть всем на запись каталог очереди. Также вы можете сделать sendmail setuid'ным на какого-либо псевдопользователя (например, создав пользователя "sendmail" и сделав sendmail setuid'ным на него) что исправит проблему конфиденциальности, но не вопросы функциональности. Также, это не будет являться гарантией безопасности: например, пользователь root посылает почту, и демон будет часто работать от пользователя root.
В качестве компромисса можно сделать sendmail setuid'ным на пользователя root, но выставить опцию RunAsUser. В результате это заставит sendmail стать указанным пользователем сразу же после запуска, требующего привилегии пользователя root (главным образом, открытия порта SMTP). Если вы используете опцию RunAsUser, каталог очереди (обычно /var/spool/mqueue) должен принадлежать этому пользователю, а все файлы и базы данных (включая пользовательские файлы .forward, файлы псевдонимов, файлы :include, и внешние базы данных) должны быть открыты для этого пользователя на чтение. RunAsUser скорее всего наиболее подходит для конфигурации на брандмауэрах, не имеющих регулярных заходов пользователей.
Sendmail очень сильно обращает внимание на режимы доступа к файлам, которые он читает и в которые пишет. Например, по умолчанию, он отказывается читать большинство файлов, открытых на запись для группы на основании того, что они могут быть искажены кем-либо из группы, а не владельцем; он даже откажется прочитать файлы в каталогах, открытых на запись для группы.
Если вы совершенно уверены, что ваша конфигурация находится в безопасности, и вы хотите, чтобы sendmail не производил таких проверок, вы можете отключить конкретные проверки, используя опцию DontBlameSendmail. Эта опция берет одно или более имен, для которых проверка отключена. В последующем описании под "небезопасным каталогом" считается каталог, в который может писать кто-либо еще кроме владельца. Значения могут быть такие:
| Safe | Никакой специальной обработки |
| AssumeSafeChown | Считать, что системный вызов chown запрещен пользователю root. Из-за того, что некоторые версии Unix разрешают обычным пользователям отдавать свои файлы другим пользователям на некоторых файловых системах, sendmail часто не может считать, что данный файл был создан владельцем, в частности, если он находится в откытом на запись каталоге. Вы можете выставить этот флаг, если вы знаете, что отдача файлов в вашей системе запрещена. |
| ClassFileInUnsafeDirPath | Во время чтения файлов класса (используя строку F в файле конфигурации), разрешать файлы, находящиеся в небезопасных каталогах. |
| ErrorHeaderInUnsafeDirPath | Разрешить файлу названному в опции ErrorHeader находиться в небезопасном каталоге. |
| GroupWritableDirPathSafe | Изменить определение "небезопасного каталога" так, чтобы каталоги, открытые на запись для группы считались безопасными. Каталоги, открытые на запись для всех всегда считаются небезопасными. |
| GroupWritableForwardFileSafe | Разрешить файлы forward открытые на запись для группы. |
| GroupWritableIncludeFileSafe | Разрешить файлы :include: открытые на запись для группы. |
| GroupWritableAliasFile | Разрешить файлы псевдонимов открытые на запись для группы. |
| HelpFileInUnsafeDirPath | Разрешить файлу, названному в опции HelpFile находиться в небезопасном каталоге |
| WorldWritableAliasFile | Принимать файлы псевдонимов, открытые на запись для всех. |
| ForwardFileInGroupWritableDirPath | Разрешить файлы .forward находящиеся в каталогах, открытых на запись для группы. |
| IncludeFileInGroupWritableDirPath | Разрешить файлы :include: находящиеся в каталогах, открытых на запись для группы. |
| ForwardFileInUnsafeDirPath | Разрешить файлы .forward находящиеся в небезопасных каталогах. |
| IncludeFileInUnsafeDirPath | Разрешить файлы :include: находящиеся в небезопасных каталогах |
| ForwardFileInUnsafeDirPathSafe | Разрешить файлам .forward находящимся в небезопасных каталогах включать ссылки на программы и файлы. |
| IncludeFileInUnsafeDirPathSafe | Разрешить файлам :include: находящимся в небезопасных каталогах включать ссылки на программы и файлы. |
| MapInUnsafeDirPath | Разрешить файлы преобразований (например, файлы hash, btree, и dbm) в небезопасных каталогах. |
| LinkedAliasFileInWritableDir | Разрешить файл псевдонимов, являющийся ссылкой в каталоге, открытом на запись. |
| LinkedClassFileInWritableDir | Разрешить файлы классов, являющиеся ссылками в каталогах, открытых на запись. |
| LinkedForwardFileInWritableDir | Разрешить файлы .forward, являющиеся ссылками в каталогах, открытых на запись. |
| LinkedIncludeFileInWritableDir | Разрешить файлы :include:, являющиеся ссылками в каталогах, открытых на запись. |
| LinkedMapInWritableDir | Разрешить файлы преобразований, являющиеся ссылками в каталогах, открытых на запись. |
| LinkedServiceSwitchFileInWritableDir | Разрешить файлу сервисного переключателя быть ссылкой, даже если каталог открыт на запись. |
| FileDeliveryToHardLink | Разрешить доставку в файлы, являющиеся жесткими ссылками. |
| FileDeliveryToSymLink | Разрешить доставку в файлы, являющиеся символическими ссылками. |
| RunProgramInUnsafeDirPath | Поехали, давайте еще и запускать программы в каталогах, открытых на запись. |
| RunWritableProgram | Ну, давайте еще и запускать те программы, в которые может писать и группа, и вообще кто угодно. |
| WriteMapToHardLink | Разрешить запись в преобразования, являющиеся жесткими ссылками. |
| WriteMapToSymLink | Разрешить запись в преобразования, являющиеся символическими ссылками. |
| WriteStatsToHardLink | Разрешить файлу статуса быть жесткой ссылкой. |
| WriteStatsToSymLink | Разрешить файлу статуса быть символической ссылкой. |
При обработке очереди, sendmail будет пытаться держать несколько последних соединений открытыми, во избежание потерь при запуске и остановке. Это применяется только к IPC соединениям.
При попытке открыть соединение, первым проверяется кэш. Если найдено открытое соединение, оно проверяется на предмет активности посылкой команды RSET. Если произойдет ошибка, то соединение будет закрыто и заново открыто.
Кэшем соединений управляют два параметра. Опция ConnectionCacheSize (k) определяет количество позволенных одновременно открытых соединений. Если оно равно нулю, соединения будут закрываться, как только это станет возможным. По умолчанию оно равно одному. Его можно установить такого размера, как вам потребуется; оно будет ограничивать количество системных ресурсов, используемых sendmail при обработке очереди. Никогда не устанавливайте это значение больше 4.
Опция ConnectionCacheTimeout (K) определяет максимальное время бездеятельности любого кэшированного соединения. Когда время простоя превысит это значение, соединение будет закрыто. Это число должно быть небольшим (до 10 минут), чтобы вы не занимали системные ресурсы других машин. Значение по умолчанию пять минут.
Управление просмотром адресов хостов назначается вхождением сервиса hosts в вашем файле сервисного переключателя. Если ваша система имеет встроенную поддержку сервисного переключателя (например, Ultrix, Solaris, или DEC OSF/1) то вполне вероятно, что ваша система уже нормально сконфигурирована. В ином случае, sendmail проконсультируется с файлом /etc/service.switch, который должен быть создан. Sendmail использует только два вхождения: hosts и aliases, хотя системные программы могут использовать иные сервисы (особенно сервис passwd для просмотра имени пользователя с помощью getpwname).
Однако, некоторые системы (типа SunOS) будут производить просмотр DNS независимо от установленных значений сервисного переключателя. В частности, системная подпрограмма gethostbyname(3) используется для просмотра имен хостов, а многие версии поставщиков пытаются использовать комбинации DNS, NIS, и просмотр файла /etc/hosts без консультации с сервисным переключателем. Sendmail не пытается обойти эту проблему, и просмотр DNS будет сделан в любом случае. Если же у вас вообще не сконфигурирован сервер имен, например, у вас чисто UUCP узел, sendmail будет получать сообщения "connection refused" при попытке соединения с сервером имен. Если вхождение hosts переключателя имеет перечисленным в любом месте списка сервис "dns", sendmail будет считать это временной неудачей и поставит сообщение в очередь для последующей обработки; другими словами, он игнорирует данные сервера имен.
Такая же технология используется при решении о просмотре MX. Если вы хотите иметь поддержку MX, вы должны иметь "dns" перечисленным как сервис во вхождении hosts переключателя.
Опция ResolverOptions (I) позволяет вам изменять опции сервера имен. Командная строка принимает последовательность флагов, как описано в resolver(3) (с удаленным первым "RES_"). Каждый из них может быть предварен опциональным "+" или "-". Например, строка
включает опцию AAONLY (принимать только авторитативные сообщения) и выключает опцию DNSRCH (поиск по доменному пути). По умолчанию большинство флагов библиотеки разрешителя отключены, включены только DNSRCH, DEFNAMES, и RECURSE. Вы также можете включить "HasWildcardMX", чтобы указать, что существует масочная запись MX, соответствующая вашему домену; это отключает сопоставление MX при канонификации имен, что может привести к неверной канонификации.
Версия конфигурации уровня 1 выключает DNSRCH и DEFNAMES для просмотров, делаемых при доставке, но оставляет их включенными во всех остальных случаях. Версия 8 sendmail игнорирует их при канонификационных просмотрах (при использовании $[ ... $]), и всегда делает поиск. Если вы не хотите автоматического расширения имен, не вызывайте $[ ... $].
Правила поиска для $[ ... $] - это что-то непохожее, чем необычное. Если просматриваемое имя имеет хотя бы одну точку, оно всегда будет опробовано без изменений. Если это не удастся, будет опробован уменьшенный путь поиска, и в конце концов будет опробовано неизмененное имя (но только для имен без точек, потому что имена с точками уже были опробованы). Это позволяет именам типа "utc.CS" совпадать с узлами в Чехословакии, а не с узлами в вашем местном отделении Computer Science. Они также предпочитают записи типов A и CNAME записям типа MX- поэтому, если находится запись MX, о ней делается заметка, но просмотр продолжается. Таким образом, если вы имеете масочную запись MX, соответствующую вашему домену, то это не будет распознано, как будто все имена совпадают с ней.
Для полного выключения доступа к серверу имен в, системах без поддержки сервисного переключателя (типа SunOS), вы должны будете перекомпилировать sendmail с -DNAMED_BIND=0 и удалив -lresolv из списка искомых при линковании библиотек.
Некоторые узлы монтируют домашние каталоги пользователей с локальных дисков их рабочих станций, потому, что локальный доступ быстрее. Однако при этом замедляется просмотр файлов .forward. В некоторых случаях, почта может быть доставлена неправильно, из-за отключения файлового сервера. Быстродействие может быть особенно медленным, если вы используете автоматическое монтирование.
Опция ForwardPath (J) позволяет вам назначить путь к файлам перенаправления. Например, строка файла конфигурации
Сначала будет искать файл с именем, совпадающим с именем пользователя в /var/forward; если он не найден, или к нему нет доступа, в домашнем каталоге пользователя будет искаться файл ".forward.machinename". Только узел настоящих извращенцев может также искать по отправителю, используя $r, $s, или $f.
Если вы создаете каталог типа /var/forward, он должен иметь пермиссии 1777 (то есть, должен быть выставлен sticky bit). Пользователи должны создавать файлы с пермиссиями 644. Заметьте, что для разрешения файлов перенаправления в каталоге, открытом всем на запись, вы должны использовать флаги ForwardFileInUnsafeDirPath и ForwardFileInUnsafeDirPathSafe с опцией DontBlameSendmail.
В системах, имеющих один из системных вызовов семейства statfs(2) (включая statvfs и ustat), вы можете указать минимальное количество свободных блоков в файловой системе очереди, используя опцию MinFreeBlocks (b). Если в файловой системе, содержащей очередь, доступно меньше, чем указанное количество блоков, сервер SMTP будет отказываться от почты кодом ошибки 452. Такой отказ приглашает клиентов SMTP попытаться установить соединение позднее.
Не устанавливайте значение этой опции слишком высоким; это может повлечь отказ от почты в тех случаях, когда она может быть спокойно обработана.
Во избежание переполнения вашей системы большим сообщением, может быть выставлена опция MaxMessageSize, указывающая абсолютное ограничение размера любого сообщения. Это будет сообщено в диалоге ESMTP и проверено при передаче сообщения.
Опция PrivacyOptions (p) позволяет вам установить конкретные "конфиденциальные" флаги. На самом деле, многие из них не дадут вам экстра конфиденциальности, а только лишь настоят на том, чтобы клиентские сервера SMTP использовали команду HELO до использования конкретных команд, или добавлением дополнительных заголовков, для распознания попыток подкачки.
Опция принимает последовательности имен флагов; крайняя конфиденциальность - включение всех этих флагов. Например:
Настоит на том, чтобы команда HELO или EHLO была использована до принятия команды MAIL и отключает команду EXPN.
Флаги подробно описаны в разделе 5.6.
Обычно, sendmail удаляет (конвертного) отправителя из любого списка расширений. Например, если "matt" посылает письмо в список, содержащий "matt" как одного из своих членов, то он, скорее всего, не захочет получить копию своего же сообщения. Если в командной строке есть флаг -m (мне тоже), или в файле конфигурации выставлена опция MeToo (m), это свойство не используется. Некоторые узлы любят запускать демон SMTP с -m.
1. В некоторых системах по умолчанию нуль, чтобы окончательно отключить протокол. [назад]
2. Эта проверка включает просмотр каждого адреса сервером имен; что добавляет сетевые задержки, но в некоторых случаях может быть приемлемо. [назад]
5. Полное Описание Файла Конфигурации
Этот раздел детально описывает файл конфигурации.
Есть одна вещь, которую вам нужно уяснить сразу: синтаксис файла конфигурации разработан так, чтобы его можно было достаточно легко анализировать, так как синтаксический анализ производится при каждом запуске sendmail, а не для того, чтобы людям было легко его читать или писать. В списке "будущих разработок" имеется компилятор файла конфигурации.
Файл конфигурации организован как последовательность строк, каждая из которых начинается с одного символа, определяющего семантику всей остальной строки. Строки, начинающиеся с пробела или символа табуляции, являются строками-продолжениями (хотя во многих местах семантика не особенно хорошо определена). Пустые строки и строки, начинающиеся с символа "#" являются комментариями.
Ядром синтаксического анализа адресов являются правила перезаписи. Они являются упорядоченной системой обработки. Sendmail просматривает набор правил перезаписи, ища совпадения в левосторонней части (LHS) правила. Если правило подходит, адрес замещается правосторонней частью (RHS) правила.
Имеется несколько наборов правил перезаписи. Некоторые из наборов используются внутренне, и должны иметь специфическую семантику. Другие наборы не имеют специальной семантики, и могут быть использованы определениями почтовых программ или другими наборами перезаписи.
Синтаксис этих двух команд такой:
Устанавливает текущий набор правил в n. Если вы начинаете набор не в первый раз, это добавляет к старому определению.
Поля должны быть разделены как минимум одним символом табуляции; поля могут содержать пробелы. lhs - это шаблон, применяемый на входе. Если он подходит, вывод переписывается на rhs. Комментарии игнорируются.
Макрорасширения в виде $x выполняются при чтении файла конфигурации. Расширения вида $&x выполняются во время работы, используя какой-либо менее общий алгоритм. Это предназначено только для ссылочных внутренне определенных макросов, типа $h, изменяющихся во время работы.
Левосторонняя часть правил перезаписи содержит шаблон. Обычные слова просто напрямую сравниваются. Метасинтаксис вводится использованием знака доллара. Метасимволы это:
$* |
Совпадение нуля или более лексем |
$+ |
Совпадение одного или более лексем |
$- |
Совпадение ровно одной лексемы |
$=x |
Совпадение любой фразы класса x |
$~x |
Совпадение любого слова не входящего в класс x |
При любом из этих совпадений, они назначаются символу $n для замены в правосторонней части, где n - индекс в LHS. Например, если LHS:
применена к входу:
Правило совпадет, и значения переданные в RHS будут такими:
$2 eric
Дополнительно, LHS может включать $@ для совпадения нулевыми лексемами. Это не граница $n в RHS, и обычно используется только в одиночестве, чтобы соответствовать нулевому входу.
Когда левосторонняя часть правила перезаписи совпадает, входная информация удаляется и замещается правосторонней частью. Лексемы копируются прямо из RHS, если они не начинаются со знака доллара. Метасимволы таковы:
$n |
Заместить неопределенную лексему n из LHS |
$[name$] |
Канонизировать имя |
$(map key $@arguments $:default $) |
Обобщенная ключевая функция преобразования |
$>n |
"Вызов" набора правил n |
$#mailer |
Решение в mailer |
$@host |
Определить host |
$:user |
Определить user |
Синтаксис $n замещает соответствующее значение из $+, $-, $*, $=, или $~ совпадения в LHS. Это может быть использовано везде.
Имя хоста, заключенное между $[ и $] просматривается в базе(ах) данных хостов и заменяется на каноническое имя 1. Например, "$[ftp$]" может стать "ftp.CS.Berkeley.EDU", а "$[[128.32.130.2]$]" может стать "vangogh.CS.Berkeley.EDU.". Sendmail распознает его числовой IP адрес без вызова сервера имен и замещает его своим каноническим именем.
Синтаксис $( ... $) - более общая форма просмотра; он использует названное преобразование вместо неявного. Если ничего не найдено, вставляется указанное умолчание; если умолчание не определено, и ничего не найдено, значение остается без изменений. Аргументы передаются в преобразование для возможного использования.
Синтаксис $>n заставляет остаток строки замещать обычным образом, а затем передать как аргумент в набор правил n. Конечное значение набора правил n затем подставляется в это правило.
Синтаксис $> распространяется на все после имени набора правил и до конца замещаемой строки, а затем передается как первичный вход в набор правил. Позволяются рекурсивные вызовы. Например,
расширяет $1, передает его в набор правил 3, а затем передает результат набора правил 3 в набор правил 0.
Синтаксис $# должен быть использован только в наборе правил 0, или подпрограмме набора правил 0. Он приводит к немедленному завершению выполнения набора правил, и сигнализирует sendmail, что адрес полностью разрешен. Полный синтаксис таков:
Он определяет тройку {mailer, host, user}, необходимую для почтовой программы. Если почтовая программа локальна, то часть host может быть опущена2. Мailer должен быть одним словом, а host и user могут состоять из нескольких частей. Если mailer является встроенным IPC mailer'ом, host может быть списком хостов, разделенных запятыми, который просматривается в поисках первого работающего адреса (точно как записи типа MX). Позднее user переписывается специфическим для данной почтовой программы набором правил перезаписи, и назначается макросу $u. В особом случае, если определенный mailer имеет ОПРЕДЕЛЕНЫЙ флаг F=@ и первый символ значения $: является "@", "@" обрезается, и выставляется флаг в описании адреса, заставляющий sendmail не применят обработку по набору правил 5.
Обычно, подходящее правило применяется снова, поэтому правило идет по кругу до появления ошибки. RHS может быть предварена $@ или $: для изменения такого поведения. Префикс A $@ заставляет набор правил возвращаться с остатком RHS в качестве значения. Префикс $: заставляет немедленно закончить работу правила, но продолжить работу набора правил; это может быть использовано во избежание продолжения применения правила. Префикс перед продолжением обрезается.
Префиксы $@ и $: могут предшествовать описанию $>; например:
Совпадает со всем, передает это в набор правил семь, и продолжается; $: необходимо во избежание бесконечной петли.
Замещение происходит в описанном порядке, то есть замещаются параметры из LHS, канонизируются имена хостов, вызываются "подпрограммы", и в конце обрабатываются $#, $@, и $:.
Существует пять наборов правил перезаписи, имеющих специфическую семантику. Взаимоотношения четырех из них изображены на Рис.1.
+---+
-->| 0 |-->resolved address
/ +---+
/ +---+ +---+
/ --->| 1 |-->| S |--
+---+ / +---+ / +---+ +---+ \ +---+
addr-->| 3 |-->| D | ----->| 4 |-->msg
+---+ +---+ \ +---+ +---+ / +---+
--->| 2 |-->| R |--
+---+ +---+
Рис.1. Семантика набора перезаписи
D - Добавка домена отправителя
S - Перезапись отправителя в зависимости от почтовой программы
R - Перезапись получателя в зависимомти от почтовой программы
Набор правил 3 должен превратить адрес в "каноническую форму". Эта форма должна иметь основной синтаксис:
Набор правил 3 применяется sendmail'ом до любых изменений в любом адресе.
Если не определено ни одного знака "@", то hostdomain-spec может быть добавлен (квадратик "D" на Рис.1.) из адреса отправителя (если в определениях почтовых программ для соответствующей отсылающей программы выставлен флаг C).
Набор правил 0 применяется после набора правил 3 к адресу, определяющему получателей. Он должен быть разделен на тройку {mailer, host, user}. Mailer должен быть определен в определениях почтовых программ в файле конфигурации. Host определяется макросом $h для использования в расширенном argv указанной почтовой программы.
Правила 1 и 2 применяются ко всем адресам отправителей и получателей соответственно. Они применяются до любого указания в определении почтовой программы. Их никогда не нужно проверять.
Набор правил 4 применяется ко всем адресам в сообщении. Он обычно используется для перевода из внутренней формы во внешнюю.
В добавок, набор правил 5 применяется ко всем локальным адресам (в частности, к тем, которые разрешаются в почтовой программе с выставленным флагом "F=5") не имеющим псевдонимов. Это последняя ловушка для локальных имен.
Несколько дополнительных наборов правил считаются "ловушками", и могут быть определены для некоторых особенностей. Все они являются именованными наборами правил. Все формы "check_*" выдают статус принять/отказать; переход в конец, или нормальный выход означает принять, а определение $#error - отказать. Многие из них могут иметь результатом специальную почтовую программу $#discard; она принимает сообщение, как будто все прошло успешно, но затем выбрасывает его без доставки.
Набор правил check relay вызывается после приема соединения. Он проверяет
где $| - метасимвол, разделяющий две части. Это правило может отказать в соединении из различных мест.
Набор правил check mail проверяет параметр имени пользователя из команды SMTP MAIL. Может принять или отвергнуть адрес.
Набор правил check rcpt проверяет параметр имени пользователя из команды SMTP RCPT. Может принять или отвергнуть адрес.
Набор правил check compat проверяет
где $| - метасимвол, разделяющий адреса. Он может принять или отвергнуть передачу почты между этими двумя адресами, что очень похоже на функцию checkcompat().
Если набор правил 0 определяет почтовую программу IPC (то есть, почтовая программа имеет "[IPC]" перечисленное в качестве Path в строке конфигурации M), происходит некоторая специальная обработка. Имя хоста, переданное после "$@" имеет найденное расширение MX; при этом имя хоста просматривается в DNS в поисках альтернативных узлов для доставки.
Имя хоста также может быть представлено как четыре числа, разделенные точками в квадратных скобках; например:
Это заставит сделать прямое преобразование числового значения в IP адрес хоста.
Имя хоста, прошедшее после "$@" также может быть списком хостов, разделенных запятыми. Для каждого из них находится MX, а результаты складываются в один длинный список MX. Цель всего этого - создать "фальшивые" записи MX, которых нет в DNS для частных внутренних сетей.
Последний специальный случай - имя хоста может быть передано как текстовая строка в квадратных скобках:
Эта форма избегает MX преобразования. Заметь!: Это предназначено только для ситуаций, когда у вас имеется сетевой firewall, или иной хост, производящий специальную обработку всей вашей почты, так что ваша запись MX указывает на шлюзовую машину; затем эта машина производит прямую доставку на машины в вашем локальном домене. Использование этой особенности напрямую нарушает секцию 5.3.5 RFC 1123: это должно использоваться только в случае, если у вас для этого имеется серьезная причина.
Имена Макросов состоят из одного символа или из слова в фигурных скобках {}. Имена из одного символа могут быть выбраны из всей таблицы ASCII, пользовательские макросы должны быть выбраны только из набора символов верхнего регистра. Буквы нижнего регистра и специальные символы имеют веутреннее использование. Длинные имена, начинающиеся с буквы нижнего регистра или знака пунктуации, зарезервированы для использования sendmail'ом, поэтому длинные пользовательские имена макросов должны начинаться с буквы верхнего регистра.
Синтаксис определения макросов таков:
Где x - имя макроса (которое может быть одним символом или словом в скобках), а val - значение, которое должен иметь этот макрос. При этом не должно быть пробелов, не принадлежащих содержимому значения макроса.
Макросы интерполируются использованием конструкции $x, где x - имя макроса для интерполяции. Эта интерполяция производится при чтении файла конфигурации, кроме строк M. Специальная конструкция $&x может быть использована в строках R для получения косвенной интерполяции.
Условные зависимости могут быть определены использованием синтаксиса:
Это интерполирует text1, если назначен макрос $x, и text2 в обратном случае. Оператор "иначе" ($|) может быть опущен.
Имена макросов из маленьких букв зарезервированы для специальной семантики, используемой при проходе информации в или из sendmail, а специальные символы зарезервированы для условий и т.п. Имена из заглавных букв (т.е., от $A до $Z) специально зарезервированы для авторов файла конфигурации.
Следующие макросы определяются и/или внутренне используются sendmail'ом для интерполирования в argv для почтовых программ или других контекстов. Те, которые отмечены знаком | пропускают информацию в sendmail3, отмеченные знаком | пропускают информацию и в и из sendmail, не отмеченные макросы пропускают из sendmail, но внутренне больше никак не используются. Вот эти макросы:
$a |
Исходящая дата в формате RFC 822. Выделяется из строки Date:. |
$b |
Текущая дата в формате RFC 822. |
$c |
Счетчик пересылок. Это счетчик числа строк Received: плюс значение флага командной строки -h. |
$d |
Текущая дата в формате UNIX (ctime). |
$e| |
(Устарел; вместо него используйте опцию SmtpGreetingMessage.) Сообщение на входе SMTP. Печатается при запуске SMTP. Первое слово должно быть макросом $j, как определено RFC821. По умолчанию "$j Sendmail $v ready at $b". Обычно переопределяется, чтобы указать номер версии конфигурации, например, "$j Sendmail $v/$Z ready at $b" |
$f |
Конвертный адрес отправителя (from). |
$g |
Адрес
отправителя по отношению к
получателю. Например, если $f - "foo", $g будет "host!foo", "foo@host.domain", или что-нибудь другое, соответствующее принимающей почтовой программе. |
$h |
Хост получателя. Устанавливается в наборе правил 0 из поля $# анализируемого адреса. |
$i |
Идентификационный номер в очереди, например, "HAA12345". |
$j| |
"Официальное" доменное имя для этого узла. Оно полностью уточнено, если может быть найдена полная квалификация. Оно должно быть переопределено, чтобы быть полностью уточненным доменным именем, если ваша система не сконфигурирована таким образом, что может найти его автоматически. |
$k |
Имя узла UUCP (из системного вызова uname). |
$l| |
(Устарел; вместо него используйте опцию UnixFromLine.) Формат строки UNIX from. До тех пор, пока вы не измените формат почтового ящика UNIX, вы не должны изменять умолчание, которое равно "From $g $d". |
$m |
Доменная часть
значения возвращенного gethostname. При нормальных обстоятельствах, $j эквивалентен $w.$m. |
$n| |
Имя демона (для сообщений об ошибках). По умолчанию "MAILER-DAEMON". |
$o| |
(Устарел: вместо него используйте опцию OperatorChars.) Набор "операторов" в адресах. Список знаков, которые могут быть рассмотрены как обозначения, и которые будут разделять значения во время анализа. Например, если "@" было в макросе $o, то ввод "a@b" будет просканирован как три обозначения: "a," "@," и "b." По умолчанию ".:@[]", минимально необходимые для анализа по RFC 822; более богатый набор операторов - ".:%@!/[]", добавляющий поддержку для UUCP, %-hack, и адресов X.400. |
$p |
Идентификационный номер процесса sendmail. |
$q| |
Формат адреса
отправителя по умолчанию.
Макрос $q указывает, как
должен выглядеть по умолчанию
адрес отправителя в сообщении.
По умолчанию "<$g>".
Обычно переопределяется на
"$?x$x <$g>$|$g$." Или "$g$?x
($x)$.", соответствующим двум
следующим форматам: Eric Allman <eric@CS.Berkeley.EDU> eric@CS.Berkeley.EDU (Eric Allman) Sendmail надлежащим образом квотирует имена, имеющие специальные знаки, если используется первая форма. |
$r |
Протокол, использовавшийся для получения сообщения. Выставляется из флага командной строки -p или кодом сервера SMTP. |
$s |
Имя хоста отправителя. Выставляется из флага командной строки -p или кодом сервера SMTP. |
$t |
Числовое представление текущего времени. |
$u |
Пользователь-получатель. |
$v |
Номер версии бинарного файла sendmail. |
$w| |
Hostname этого узла. Корневое имя для этого хоста (смотри ниже всякие нерулезности). |
$x |
Полное имя отправителя. |
$z |
Домашний каталог получателя. |
$_ |
Подтвержденный адрес отправителя. |
${bodytype} |
Тип тела сообщения (7BIT или 8BITMIME), определенный из конверта. |
${client_addr} |
IP адрес клиента SMTP. Определяется только в сервере SMTP. |
${client_name} |
Имя хоста клиента SMTP |
${client_port} |
Номер порта клиента SMTP. Определяется только в сервере SMTP. |
${envid} |
Идентификационный номер конверта, переданный в sendmail как часть конверта. |
${opMode} |
Текущий режим работы (из флага -b). |
Существует три типа дат, которые могут быть использованы. Макросы $a и $b в формате RFC 822; $a - время, выделяемое из строки "Date:" сообщения (если она там есть), а $b - текущая дата и время (используемые для "штемпеля"). Если во входящем сообщении не найдено ни одной строки "Date:", $a также выставляется на текущее время. Макрос $d эквивалентен макросу $b в формате UNIX (ctime).
Макросы $w, $j, и $m выставляются для опознания этого хоста. Sendmail, если это вообще возможно, пытается найти полностью определенное имя хоста; он делает это вызовом gethostname(2) для получения текущего hostname, и затем, передавая его в gethostbyname(3), который, по идее, должен вернуть каноническую версию этого имени хоста4. Если все успешно проходит, $j выставляется в полностью определенное имя и $m выставляется в доменную часть имени (все, что находится после первой точки). Макрос $w выставляется в первое слово (все, что до первой точки) если вы имеете файл конфигурации уровня 5 и выше; иначе, он будет иметь то же значение, что и $j. Если канонификация проваливается, предписывается, чтобы файл конфигурации выставлял $j в полностью определенное доменное имя5.
Макрос $f является изначально определенным идентификатором отправителя; при посылке на специфический хост макрос $g выставляется в адрес отправителя относительно получателя. Например, если я посылаю на "bollard@matisse.CS.Berkeley.EDU" с машины "vangogh.CS.Berkeley.EDU", макрос $f будет "eric", а макрос $g будет macro will be "eric@vangogh.CS.Berkeley.EDU".
Макрос $x выставляется в полное имя отправителя. Оно может быть определено несколькими способами. Оно может быть передано как флаг в sendmail. Оно может быть определено в переменной окружения NAME. В третьих, значение строки "Full-Name:" в заголовке, если она существует. И в четвертых, поле комментария в строке "From:". Если же все это ни к чему не приведет, и если сообщение исходит с этого хоста, полное имя смотрится в файле /etc/passwd.
При отправке, макросы $h, $u, и $z выставляются в host, user, и домашний каталог (если локально) получателя. Первые два берутся из частей $@ и $: правил перезаписи, соответственно.
Макросы $p и $t используются для создания уникальных строк (например, для поля "Message-Id:"). Макрос $i выставляется в идентификатор очереди на этом хосте; При вставке в строку отметки времени, это может быть полезно для отслеживания сообщений. Макрос $v выставляется равным номеру версии sendmail; обычно он помещается в отметку о времени и очень полезен при отладке.
Поле $c получает значение "счетчика пересылок", то есть, то количество раз, которое это сообщение обрабатывалось. Это может быть определено флагом командной строки -h или подсчетом отметок времени в сообщении.
Поля $r и $s соответствуют протоколу, использовавшемуся для соединения с sendmail и имени хоста отправителя. Они оба могут быть назначены, используя флаг командной строки -p, или по раздельности, используя флаги -M или -oM.
Макрос $_ устанавливается в подтвержденное имя хоста отправителя. Если отправитель имеет работающий сервер IDENT, соответствующий RFC 1413, а получатель имеет включенный протокол IDENT, он будет включать имя пользователя на том хосте.
Макросы ${client_name}, ${client_addr}, и ${client_port} выставляются в имя, адрес, и номер порта клиента SMTP вызывающего как сервер sendmail. Они могут быть использованы в наборах правил check * (конечно же, используя косвенную форму определения $&!).
Можно определить классы или фразы для соответствия левосторонней части правил перезаписи, где "фраза" - это последовательность символов, не содержащая символов пробела. Например, для предотвращения отправки сообщений самому себе, может быть создан класс всех локальных имен для данного узла. Это может быть определено как в файле конфигурации, так и читаться из другого файла. Классы имеют имена, состоящие из одной буквы или слова в {скобках}. Имена классов, начинающиеся с букв нижнего регистра и специальных символов, зарезервированы для использования системой. Классы, определенные в файлах конфигурации могут быть заданы заглавными буквами для коротких имен, или начинаться с заглавной буквы для длинных имен.
Синтаксис:
Fcfile
Первая форма определяет класс c соответствующим любому из названных слов. Ее можно разбивать на несколько строк; на пример, две формы:
и
CHucbmonet
эквивалентны. Форма "F" читает элементы класса c из названного file.
Можно получить доступ из правил к элементам классов, используя $= или $~, (сопоставить вхождения не входящие в класс) совпадающие только с отдельным словом; вхождения из нескольких слов в классе, в этом контексте, игнорируются.
Некоторые классы имеют для sendmail внутреннее значение:
$=e |
Содержит Content-Transfer-Encodings которые могут быть преобразованы 8->7 bit. Предопределено для содержания "7bit", "8bit", и "binary". |
$=k |
То же самое, что и $k, то есть, имя узла UUCP. |
$=m |
Устанавливается в набор доменов, знающих об этом хосте, изначально просто $m. |
$=n |
Может быть установлено в набор типов MIME, которые никогда не перекодируются из восьми бит в семь. По умолчанию "multipart/signed". Типы сообщений "message/*" и "multipart/*" никогда не перекодируются напрямую. Сообщения "multipart" взегда обрабатываются рекурсивно. Обработка сообщений "message/*" контролируется классом $=s. |
$=q |
Набор Content-Types, которые не могут быть перекодированы как base64 (если они должны быть перекодированы, они будут перекодированы как quoted-printable). Он может иметь первичные типы types (например, "text") или полные типы (типа "text/plain"). Класс инициализируется содержащим только "text/plain". |
$=s |
Содержит набор подтипов сообщений, с которыми можно обращаться рекурсивно. По умолчанию содержит только "rfc822". Другие типы "message/*" не могут быть перекодированы 8->7 bit. Если сообщение содержит восьмибитные данные, посланные на семибитный хост, и сообщение не может быть перекодировано в семь бит, оно будет обрезано до 7 бит. |
$=t |
Установлен в набор доверенных пользователей строкой конфигурации T. Если вы хотите считывать список доверенных пользователей из файла, используйте Ft/file/name. |
$=w |
Выставлен в набор всех имен, о которых знает хост. Может быть использован для совпадений с локальными именами хостов. |
Sendmail может быть скомпилирован с разрешением использовать scanf(3) в строке F. Это позволит вам производить простейший анализ текстовых файлов. Например, чтобы прочитать все имена пользователей из системного файла /etc/passwd в класс, используйте
Это будет читать каждую строку до первого двоеточия.
В этой строке определяются почтовые программы и их интерфейсы. Формат такой:
Где name - имя почтовой программы (используется только внутренне), а пары "field=name" определяют атрибуты почтовой программы. Поля такие:
| Path | Путь к почтовой программе |
| Flags | Специальные флаги для этой почтовой программы |
| Sender | Набор(ы) правил перезаписи для адресов отправителя |
| Recipient | Набор(ы) правил перезаписи для адреса получателя |
| Argv | Вектор аргументов, передаваемый в почтовую программу |
| Eol | Строка end-of-line для этой почтовой программы |
| Maxsize | Максимальный размер сообщения для этой почтовой программы |
| Linelimit | Максимальная длина линии в теле сообщения |
| Directory | Рабочий каталог для почтовой программы |
| Userid | Идентификаторы пользователя и группы для запуска |
| Nice | Инкремент nice(2) для почтовой программы |
| Charset | Набор символов по умолчанию для 8-битных символов |
| Type | Информация о типе MTS (используется для сообщений об ошибках) |
В имени поля проверяется только первый символ.
Нижеописанные флаги могут быть установлены в описании почтовой программы. Любые другие флаги могут свободно использоваться для условных заголовков в сообщениях для определенных почтовых программ. Флаги, отмеченные |,не интерпретируются бинарником sendmail; они обычно используются для корреляции с флагами в строке H. Флаги, отмеченные знаком |, применяются в почтовой программе для адреса отправителя, хотя обычно это делает принимающая почтовая программа.
a |
Запустить протокол Extended SMTP (ESMTP) (определенный в RFC 1651, 1652, и 1653). Этот флаг по умолчанию включен, если приветственное сообщение SMTP содержит слово "ESMTP". |
A |
Просмотреть пользовательскую часть адреса в базе данных псевдонимов. Обычно выставляется только для локальных почтовых программ. |
b |
Проставить пустую строку в конце сообщения. Это предназначено для работы с некоторыми глупыми версиями /bin/mail, требующими пустую строку, но сами ее не проставляющие. |
c |
Не включать в адрес комментарии. Это должно использоваться, только если вы должны работать с удаленной почтовой программой, не понимающей комментариев. Обрезает адрес из вида "Phrase <address>" или "address (Comment)" до просто "address". |
C |
Если почта получена
от почтовой программы с этим
флагом, любые адреса в
заголовке, не имеющие знака
("@") после перезаписи
набором правил три будут иметь
окончание "@domain" из адреса
отправителя, взятого с
конверта. Это позволяет почту с
заголовками типа:
From: usera@hosta> Автоматически переписывать как: From: usera@hosta Однако это не всегда работает надежно. |
d |
Не включать угловые скобки вокруг адресов с синтаксисом путевого адреса. Полезно для почтовых программ, передающих адреса в оболочку, которая может интерпретировать угловые скобки как перенаправление ввода/вывода. |
D |
Эта почтовая программа хочет в заголовке строку "Date:". |
e |
Эта почтовая программа слишком медленна, поэтому попробуй избежать нормального соединения; любое необходимое соединение произойдет во время обработки очереди. |
E |
Избегать строки, начинающиеся с "From" в сообщении с знаком ">". |
f |
Почтовая программа хочет флаг -f from, но только если это операция пересылки в сети (то есть, почтовая программа выдаст ошибку, если выполняющий пользователь не имеет специальных прав). |
F| |
Эта почтовая программа хочет строку заголовка "From:". |
g |
Обычно, sendmail посылает внутренне созданную почту (например, сообщения об ошибках) используя нулевой обратный адрес, как это требуется RFC 1123. Однако, некоторые почтовые программы не принимают нулевой обратный адрес. Если это необходимо, вы можете установить флаг g, чтобы sendmail не следовал стандартам; сообщения об ошибках будут посланы от MAILER-DAEMON (на самом деле, значение макроса $n). |
h |
Символы верхнего регистра в именах хостов для этой почтовой программы должны быть сохранены. |
i |
Произвести перезапись пользовательской базы данных на конвертный адрес отправителя. |
I |
Эта почтовая программа будет говорить на SMTP с другим sendmail - поэтому он может использовать некоторые специальные особенности протокола. Эта опция не требуется (т.е.. если эта опция опущена, передача все равно будет работать нормально, хотя не настолько эффективно, как могла бы). |
j |
Произвести перезапись пользовательской базы данных на получателей и отправителей. |
k |
Обычно, когда sendmail соединяется с хостом посредством SMTP, он проверяет, не соединился ли он случайно сам с собой, что может случиться, если sendmail имеет неправильную конфигурацию, или если сетевой интерфейс закольцован. Этот флаг выключает проверку петли. Он должен использоваться только в очень необычных случаях. |
K |
В настоящее время не работает. Зарезервирован для разбиения на куски. |
l |
Эта почтовая программа локальна (т.е., будет осуществлена последняя доставка). |
L |
Ограничивает
длину строк, как определено в
RFC821. Эта обесцененная опция должна быть заменена почтовым объявлением L=. По историческим причинам, флаг L также выставляет флаг 7. |
m |
Эта почтовая программа может разослать нескольким пользователям на одном хосте в одну транзакцию. Когда в argv части определения почтовой программы встречается макрос $u, это поле будет повторено необходимое количество раз для всех подходящих пользователей. |
M| |
Эта почтовая программа хочет строку заголовка "Message Id:". |
n |
Не вставлять в начале сообщения "From" в стиле UNIX. |
o |
Всегда работать как хозяин почтового ящика получателя. Обычно sendmail работает как отправитель для локально генерируемой почты или как "демон" (на самом деле, пользователь определяется в опции u) при получении сетевой почты. Большинству локальных почтовых программ требуется обычное поведение, которое не позволит установить конвертный адрес отправителя, пока почтовая программа работает как демон. Этот флаг игнорируется, если выставлен флаг S. |
p |
Использовать обратный путь в стиле route-addr в команде SMTP "MAIL FROM:" вместо просто обратного адреса; хотя это и требуется в секции 3.1 RFC821, многие хосты не обрабатывают нормально обратные пути. Обратные пути осуждаются в RFC 1123. |
P| |
Эта почтовая программа хочет строку "Return-Path:". |
q |
Когда адрес, разрешаемый в этой почтовой программе, проверен (команда SMTP VRFY), генерировать ответы 250 вместо ответов 252. Это будет означать, что адрес локальный. |
r |
То же, что и f, но посылает флаг -r. |
R |
Открыть соединение SMTP на "безопасном" порту. "Безопасные" порты не являются таковыми, за исключением UNIX машин, поэтому не ясно, даст ли это что-нибудь. |
s |
Обрезать символы квотирования (" и \) у адреса перед вызовом почтовой программы. |
S |
Не
переустанавливать userid перед
вызовом почтовой программы. Это может быть использовано в безопасной среде, где sendmail запущен от root. Это может быть использовано для избежания поддельных адресов. Если также определено поле U=, это флаг заставит id пользователя всегда быть установленным на этого пользователя и группу (вместо того, чтобы оставить его как у root). |
u |
Символы верхнего регистра в именах пользователей для этой почтовой программы должны быть сохранены. |
U |
Эта почтовая программа хочет строки "From" в стиле UUCP с уродливым "remote from <host>" в конце. |
w |
Пользователь должен иметь действительный бюджет на этой машине, т.е., getpwnam должен быть успешным. Если это не так, почта не будет доставлена. Это требуется для работы ".forward". |
x |
Эта почтовая программа хочет строку заголовка "Full-Name:". |
X |
Эта программа хочет использовать алгоритм скрытых точек, как определено в RFC821; смысл такой: любая строка, начинающаяся с точки, будет иметь предваряющую ее точку (для того, чтобы ее обрезали на другом конце). Это гарантирует, что строки в сообщении, содержащие точку не прекратят сообщение преждевременно. |
z |
Запустить Протокол Локальной Доставки Почты (Local Mail Transfer Protocol, LMTP) между sendmail и локальной почтовой программой. Это вариант SMTP определенный в RFC 2033, специально разработанный для зоставки в локальный почтовый ящик. |
0 |
Не просматривать записи MX для хостов, посылающих посредством SMTP. |
3 |
Расширить список символов, преобразованных в =XX запись при преобразовании в Quoted-Printable для того, чтобы не потерять те, которые не преобразуются в чистом виде между ASCII и EBCDIC. Полезно, если в вашем узле имеется мэйнфрэймы IBM. |
5 |
Если для этого адреса не найдено псевдонимов, пропустить адрес через набор правил 5 для другого возможного разрешения. Это предназначено для перенаправления почты в другое альтернативное место доставки. |
7 |
Обрезать весь вывод до семи бит. Стоит по умолчанию, если установлен флаг L. Заметьте, что очистка этой опции не достаточна, чтобы через sendmail полностью проходили восьмибитные данные. Если опция 7 выставлена, а она в основном всегда выставлена, то восьмибитные данные на входе будут обрезаться. Нужно отметить, что эта опция затрагивает только сообщения, которые не имеют примененного MIME преобразования 8->7 бит. |
8 |
Если выставлена, то эта почтовая программа принимает для отсылки восьмибитные данные; обычная попытка MIME преобразования 8->7 бит будет пропущена. |
9 |
Если выставлена, производить ограниченные MIME преобразования 7->8 бит. Эти преобразования ограничены данными типа text/plain. |
: |
Проверить адреса, не начинаются ли они с ":include:"; если это так, обратить их к почтовой программе "*include*". |
| |
Проверить адреса, не начинаются ли они с "|"; "prog". |
/ |
Проверить адреса, не начинаются ли они с "/"; если это так, обратить их к почтовой программе "*file*". |
@ |
Просмотреть адреса в пользовательской базе данных. |
Конфигурационные файлы до уровня 6 предполагают опции "A", "w", "5", ":", "|", "/", и "@" в почтовой программе называющейся "local".
Почтовая программа со специальным именем "error" может быть использована для генерации сообщений об ошибках пользователя. Поле хоста (опционально) содержит возвращаемый статус выхода, а поле пользователя - распечатываемое сообщение. Статус выхода может быть числом или одним из значений USAGE, NOUSER, NOHOST, UNAVAILABLE, SOFTWARE, TEMPFAIL, PROTOCOL, или CONFIG, возвращающим соответствующий код выхода EX_, или усовершенствованный код ошибки, описанный в RFC 1893, Enhanced Mail System Status Codes. Например, вхождение:
в RHS правила вызовет генерацию указанной ошибки, и, если LHS совпадает, будет возвращен статус выхода "Host unknown". Эта почтовая программа работоспособна только в наборах правил 0, 5, или одном из наборов правил check_*.
Почтовая программа со специальным именем "discard" заставляет выкидывать любую почту, посланную к ней, но в то же время считать, что она была успешно доставлена.
Почтовая программа, называющаяся "local" должна быть определена в каждом файле конфигурации. Она используется для доставки локальной почты, и обслуживается особо несколькими образами. В добавок, три другие почтовые программы, называющиеся "prog", "*file*", и "*include*" могут быть определены для настройки доставки сообщений в программы, файлы и списки :include: соответственно. Их умолчания:
M*file*, P=/dev/null, F=lsDFMPEu, A=FILE
M*include*, P=/dev/null, F=su, A=INCLUDE
Наборы перезаписи Sender и Recipient могут быть как просто идентификатором набора правил, так и двумя идентификаторами, разделенными слешем; в этом случае, первый набор перезаписи применяется к конвертным адресам, а второй применяется к заголовкам.
Directory - это на самом деле перечисление путей для просмотра с разделителем ":". Например, определение "D=$z:/" сначала опробует выполнение в домашнем каталоге получателя; если он недоступен, то попробует выполнение в корневом каталоге файловой системы. Это предназначено для использования только в почтовой программе "prog", из-за того, что некоторые оболочки (типа csh) отказываются работать, если они не могут прочитать домашний каталог. Вследствие того, что каталог очереди обычно не доступен для чтения непривилегированным пользователям, сценарии csh, как принимающие программы не смогут работать.
Userid определяет идентификатор пользователя и группы по умолчанию для работы, заменяя собой опцию DefaultUser. Если флаг S почтовой программы также определен, то этот пользователь и группа используется для работы при всех обстоятельствах. Это может быть задано как user:group для выставки идентификаторов пользователя и группы одновременно; это могут быть целые числа или символические имена, просматриваемые в файлах passwd и group соответственно. Если определено только символическое имя пользователя, в качестве идентификатора группы используется идентификатор, прописанный для этого пользователя в файле passwd.
Поле Charset используется при преобразовании сообщения в MIME; этот набор символов используется в заголовке Content-Type:. Если он не установлен, используется опция DefaultCharset, если же и она не назначена, используется значение "unknown-8bit". Внимание: это поле применяется к почтовой программе отправителя, а не получателя. Например, конвертный адрес отправителя принадлежит локальной сети, а получателя - внешней, набор символов будет установлен из поля Charset= для локальной сетевой почтовой программы, а не для внешней.
Поле Type= устанавливает тип информации, используемой в сообщениях об ошибках MIME, как определено в RFC 1894. На самом деле это три значения, разделенные слешами: MTAtype (то есть, описание того, как называются хосты), тип адреса (описание адресов электронной почты), и тип диагностики (описание кодов диагностических ошибок). Каждое из них должно быть зарегистрированным значением, или начинаться с "X-". По умолчанию "dns/rfc822/smtp".
Формат строк заголовка, вставляемых sendmail в сообщение, определяется строкой H. Синтаксис этой строки:
Строки-продолжения в этом определении отражаются прямо в выходящее сообщение. Макрос htemplate раскрывается до подстановки в сообщение. Если определена mflags (окруженная знаками вопроса), как минимум один из указанных флагов должен иметь место в определении почтовой программы для этого заголовка для автоматического вывода. Если один из этих заголовков имеется на входе, он отражается на выход не зависимо от этих флагов.
Некоторые заголовки имеют специальную семантику, описываемую позднее.
Вторичный синтаксис позволяет производить проверку заголовков в том виде, как они были считаны. Для включения проверки, используйте:
HHeader: $>Ruleset
Указанный набор правил (Ruleset) вызывается для указанного заголовка Header, и может возвращать $#error для отказа от сообщения, или $#discard для сброса сообщения (как и в остальных наборах правил check_*). Заголовок рассматривается как структурированное поле, то есть, комментарии (в кавычках) перед обработкой удаляются.
Например, следующие строки в конфигурации:
R< $+ @ $+ >$@ OK R$* $#error $: Illegal Message-Id header
Приведут к отказу от любого сообщения, имеющего заголовок в любой из следующих форм:
Message-Id: любой текст
Message-Id: <легальный текст@домен> дополнения
Существует большое количество глобальных опций, которые могут быть назначены из файла конфигурации. Опции представляются целыми словами; некоторые, для обратной совместимости, можно также представлять в виде отдельных букв. Синтаксис таков:
Это назначает опции опция указанное значение. Заметьте, что между буквой "O" и именем опции должен быть пробел. Раньше это было так:
где опция o - один символ. В зависимости от опции, значение может быть строкой, целым числом, булевым (с допустимыми значениями "t", "T", "f", или "F"; по умолчанию TRUE), или интервалом времени.
Поддерживаемые опции (со старыми, однобуквенными именами в квадратных скобках):
AliasFile=spec, spec, ...
AliasWait=timeout
AllowBogusHELO
AutoRebuildAliases
BlankSub=c
CheckAliases
CheckpointInterval=N
ClassFactor=fact
ColonOkInAddr
ConnectionCacheSize=N
ConnectionCacheTimeout=timeout
ConnectionRateThrottle=N
DaemonPortOptions=options
| Port | Имя/номер рабочего порта (по умолчанию "smtp") |
| Addr | Адресная маска (по умолчанию INADDR_ANY) |
| Family | Семейство адресов (по умолчанию INET) |
| Listen | Размер очереди прослушивания (по умолчанию 10) |
| SndBufSize | Размер буфера TCP на отправку |
| RcvBufSize | Размер буфера TCP на прием |
DefaultCharSet=charset
DefaultUser=user:group
DeliveryMode=x
| i | Доставлять интерактивно (синхронно) |
| b | Доставлять в фоне (асинхронно) |
| q | Просто класть сообщение в очередь (доставка во время обработки очереди) |
| d | Отложить доставку и все преобразования (доставка во время обработки очереди) |
DialDelay=sleeptime
DontBlameSendmail=option,option,...
Safe
AssumeSafeChown
ClassFileInUnsafeDirPath
ErrorHeaderInUnsafeDirPath
FileDeliveryToHardLink
FileDeliveryToSymLink
ForwardFileInUnsafeDirPath
ForwardFileInUnsafeDirPathSafe
ForwardFileIngroupWritableDirPath
GroupWritableAliasFile
GroupWritableDirPathSafe
GroupWritableForwardFileSafe
GroupWritableIncludeFileSafe
HelpFileinUnsafeDirPath
IncludeFileInUnsafeDirPath
IncludeFileInUnsafeDirPathSafe
IncludeFileIngroupWritableDirPath
LinkedAliasFileInWritableDir
LinkedClassFileInWritableDir
LinkedForwardFileInWritableDir
LinkedIncludeFileInWritableDir
LinkedMapInWritableDir
LinkedServiceSwitchFileInWritableDir
MapInUnsafeDirPath
RunProgramInUnsafeDirPath
RunWritableProgram
WorldWritableAliasFile
WriteMapToHardLink
WriteMapToSymLink
WriteStatsToHardLink
WriteStatsToSymLink
Safe - это умолчание. Выше имеется более подробное описание этих флагов. Использование этой опции не рекомендуется.
DontExpandCnames
DontInitGroups
DontProbeInterfaces
DontPruneRoutes
sendmail обрежет "@known1,@known2" для того, чтобы сделать маршрут как можно более прямым. Однако, если выставлена опция R, это будет отключено, и почта будет послана по первому адресу в маршруте, даже если остальные адреса известны. Это может быть полезно, если вы заперты за файерволом.
DoubleBounceAddress=error-address
EightBitMode= действие
| s | Отвергнуть необъявленные 8-битные данные ("strict") |
| m | Преобразовать необъявленные 8-битные данные в MIME ("mime") |
| p | Пропустить необъявленные 8-битные данные ("pass") |
ErrorHeader=file-or-message
ErrorMode=x
| p | Печатать сообщения об ошибке (по умолчанию) |
| q | Без сообщений, просто выдавать статус выхода |
| m | Отправлять назад ошибки почтой |
| w | Печатать ошибки (отправлять почтой, если пользователь не находится в системе) |
| e | Отправлять назад ошибки почтой и всегда выдывать нулевой статус выхода |
FallbackMXhost=fallbackhost
ForkEachJob
ForwardPath=path
HelpFile=file
HoldExpensive
HostsFile=path
HostStatusDirectory=path
IgnoreDots
LogLevel=n
Mxзначение
MatchGECOS
MaxDaemonChildren=N
MaxHopCount=N
MaxHostStatAge=age
MaxMessageSize=N
MaxQueueRunSize=N
MaxRecipientsPerMessage=N
MeToo
MinFreeBlocks=N
MinQueueAge=age
MustQuoteChars=s
NoRecipientAction
OldStyleHeaders
OperatorChars=charlist
PostmasterCopy=postmaster
PrivacyOptions=opt,opt,...
| public | Позволить открытый доступ |
| needmailhelo | Требовать команду HELO или EHLO до MAIL |
| needexpnhelo | Требовать команду HELO или EHLO до EXPN |
| noexpn | Полностью запретить EXPN |
| needvrfyhelo | Требовать команду HELO или EHLO до VRFY |
| novrfy | Полностью запретить VRFY |
| noetrn | Полностью запретить ETRN |
| noverb | Полностью запретить VERB |
| restrictmailq | Ограничить команду mailq |
| restrictqrun | Ограничить флаг командной строки -q |
| noreceipts | Не возвращать успешные DSN |
| goaway | Запретить все основные запросы статуса SMTP |
| authwarnings | Вкладывать в сообщение заголовок X-Authentication-Warning: |
QueueDirectory=dir
QueueFactor=коэффициент
QueueLA=LA
QueueSortOrder=алгоритм
QueueTimeout=timeout
ResolverOptions=options
RunAsUser=user
RecipientFactor=коэффициент
RefuseLA=LA
RetryFactor=коэффициент
SafeFileEnvironment=каталог
SaveFromLine
SendMIMEErrors
ServiceSwitchFile=filename
| aliases | Files |
| hosts | dns nis files |
SevenBitInput
SingleLineFromHeader
SingleThreadDelivery
SmtpGreetingMessage=сообщение
StatusFile=file
SuperSafe
TempFileMode=mode
Timeout.type=timeout
| initial | Ожидание начального приветствия [5m, 5m] |
| helo | Ответ на команду HELO или EHLO [5m, none] |
| Ответ на команду MAIL [10m, 5m] | |
| rcpt | Ответ на команду RCPT [1h, 5m] |
| datainit | Ответ на команду DATA [5m, 2m] |
| datablock | Чтение блока данных [1h, 3m] |
| datafinal | Ответ на завершающую "." в данных [1h, 10m] |
| rset | Ответ на команду RSET [5m, none] |
| quit | Ответ на команду QUIT [2m, none] |
| misc | Ответ на команды NOOP и VERB [2m, none] |
| ident | Таймаут протокола IDENT [30s, none] |
| fileopen| | Таймаут открытия файлов .forward и :include: [60s, none] |
| command| | Чтение команды [1h, 5m] |
| queuereturn| | Время до возврата сообщения [5d, 5d] |
| queuewarn| | Время до посылки предупреждения [none, none] |
| hoststatus| | Время "устаревания" статуса хоста [30m, none] |
TimeZoneSpec=tzinfo
TryNullMXList
UnixFromLine=fromline
UnsafeGroupWrites
UseErrorsTo
UserDatabaseSpec=udbspec
UserSubmission
Verbose
Все опции могут быть указаны в командной строке, используя флаг -O или -o, но большинство может заставить sendmail освободиться от своих suid'ных полномочий. Опции, которые этого не причиняют: MinFreeBlocks [b], DeliveryMode [d], ErrorMode [e], IgnoreDots [i], LogLevel [L], MeToo [m], OldStyleHeaders [o], PrivacyOptions [p], Timeouts [r], SuperSafe [s], Verbose [v], CheckpointInterval [C], и SevenBitInput [7]. Также, M (определить макрос) при определении макросов r или s считается "безопасным".
Значения для поля "Precedence:" могут быть определены использованием контрольной строки P. Синтаксис этого поля:
Когда имя найдено в поле "Precedence:" класс сообщения выставляется в число. Более высокие числа означают более высокое старшинство. Числа менее нуля имеют специальное назначение - если происходит ошибка во время обработки сообщения, его тело не будет возвращено; это предназначается для "большой" почты, типа проходящей через списки рассылки. По умолчанию старшинство равно нулю. Например, наш список старшинств состоит из:
Pspecial-delivery=100
Plist=-30
Pbulk=-60
Pjunk=-100
Использование людьми, пишущие обработчики списков рассылки "Precedence: list" очень приветствуется. Старые версии sendmail (которые отвергали все возвраты ошибок из-за отрицательного старшинства) не распознают это имя, давая ему нулевое старшинство по умолчанию. Это позволяет владельцам списков рассылки видеть возвраты ошибок и в старых, и в новых версиях sendmail.
Для обеспечения совместимости со старыми файлами конфигурации, была добавлена строка V, определяющая некоторую очень основную семантику конфигурационного файла. Она не предназначена для поддержки длинных обозначений; вместо этого, она описывает особенности совместимости, которые, возможно, будут убраны в будущих выпусках.
Заметь!: эти уровни версий не имеют ничего общего с номерами версий в файлах. Например, при написании файлов конфигурации версии 8 (в особенности, 8.7) использовались конфигурации уровня 6.
"Старые" файлы конфигурации определяются как уровень версии один. Фаулы уровня версии два делают следующие изменения:
| (1) | Канонификация имени хоста ($[ ... $]) добавляет точку, если имя распознано; это дает файлу конфигурации способ определить, совпало ли что-нибудь. (На самом деле, это просто инициализирует преобразование хоста с флагом "-a." - вы можете переустановить это на что угодно явным объявлением преобразования.) |
| (2) | Расширение имени хоста по умолчанию постоянно при всех обработках; конфигурации версий уровня один в некоторых местах обработки выключали доменное расширение (то есть, добавляя имя локального домена). Конфигурации версий уровня два по идее включают последнюю точку для указания того, что это уже каноническое имя. |
| (3) | Локальные имена, не являющиеся псевдонимами проходят через новое выделяющее правило пять; оно может быть использовано для добавления локального ретранслятора. Такое поведение может быть предотвращено посредством разрешения локального имени с начальным "@". То есть, допустим, то, что разрешается на локальную почтовую программу и имя пользователя "vikki" пройдет через набор правил пять, но имя пользователя "@vikki" потеряет "@", не пройдет через набор правил пять, или же будет обработано как в предыдущем примере. Здесь расчет на то, что это может быть использовано для реализации такого поведения, когда почта, посланная к "vikki" будет обработана центральным концентратором, а почта, посланная к "vikki@localhost" будет доставлена напрямую. |
Файлы версии уровня три позволяют # начинать комментарии во всех строках. Исключения составляют экранированные обратным слешем знаки # и синтаксис $#.
Конфигурации версии уровня четыре, по историческим причинам, полностью эквивалентны уровню три.
Файлы конфигурации версии уровня четыре изменяют определение по умолчанию, что $w является просто первым компонентом имени хоста.
Файлы конфигурации версии уровня шесть переделывают многие опции локальной обработки (типа псевдонимизации и соответствия началу адреса для символов "|") во флаги почтовых программ; это обеспечивает детализированный контроль над специальными локальными обработками. Файлы конфигурации версии уровня шесть также могут включать длинные имена опций. Опция ColonOkInAddr (разрешающая двоеточия в местной части адресов) для конфигурационных файлов более низкого уровня по умолчанию on; Файл конфигурации требует некоторый дополнительный интеллект для правильной обработки структуры группы RFC 822.
Конфигурационные файлы седьмого уровня версии использовали новые имена опций для замены старых макросов ($e стало Smtp GreeetingMessage, $l стало UnixFromLine, и $o стало OperatorChars). Также, до седьмой версии, предполагался флаг F=q (использовать возвращаемое значение 250 вместо 252 для команды SMTP VRFY).
Строка V может опционально иметь /vendor для указания того, что это файл конфигурации использует специфические для частного поставщика изменения8. Вы можете использовать "/Berkeley" для подчеркивания, что этот файл конфигурации использует Berkeley разновидность sendmail.
Специальные преобразования могут быть определены использованием строки:
Где mapname - имя, под которым это преобразование используется в правилах перезаписи; mapclass - имя типа преобразования (эти имена вкомпилированы в sendmail); arguments интерпретируются в зависимости от класса; обычно, используется один аргумент, указывающий на файл, содержащий преобразование.
На преобразования ссылаются, используя синтаксис:
где и аргументы и умолчание могут быть опущены. $@ аргументы могут встречаться много раз. Указанный ключ и аргументы передаются в соответствующую преобразующую функцию. Если она возвращает значение, то оно замещает ввод. Если она не возвращает значение и имеется определенное умолчание, the умолчание заменяет ввод. Иначе ввод не изменяется.
Аргументы передаются в преобразование для произвольного использования. Большинство классов преобразований могут интерполировать эти аргументы в их значения используя для указания соответствующего аргумента синтаксис "%n" (где n - цифра).
Аргумент "%0" обозначает ключ базы данных. Например, правило
Просматривает имя UUCP в (определенном пользователем) преобразовании UUCP; если не найдено, превращает его в форму ".UUCP". База данных должна содержать записи типа:
research %1@%0.ATT.COM
Отметьте, что операторы умолчания никогда не делают этого преобразования.
Встроенное преобразование с именем и классом "host" - это просмотр канонизации имени хоста. Таким образом, синтаксис:
эквивалентен:
Существует множество определенных классов.
| dbm | Просмотр базы данных, используя библиотеку ndbm(3). Sendmail должен быть скомпилирован с определенной NDBM. |
| btree | Просмотр базы данных с использованием интерфейса btree к библиотеке Berkeley db(3). Sendmail должен быть скомпилирован с определенной NEWDB. |
| hash | Просмотр базы данных с использованием хэш-интерфейса к библиотеке Berkeley db(3). Sendmail должен быть скомпилирован с определенной NEWDB. |
| nis | Просмотры NIS. Sendmail должен быть скомпилирован с определенной опцией NIS. |
| nisplus | Просмотры NIS+. Sendmail должен быть скомпилирован с определенной опцией NISPLUS. Аргумент - имя таблицы, используемой для просмотров, а флаги -k и -v могут быть использованы для установки столбцов ключа и значения соответственно. |
| hesiod | Просмотры Hesiod. Sendmail должен быть скомпилирован с определенной опцией HESIOD. |
| ldapx | Просмотры каталогов LDAP X500. Sendmail должен быть скомпилирован с определенной опцией LDAPMAP. Преобразование поддерживает большинство стандартных аргументов и большинство аргументов командной строки программы ldapsearch. |
| netinfo | Просмотры NeXT NetInfo. Sendmail должен быть скомпилирован с определенной опцией NETINFO. |
| text | Просмотры текстовых файлов. Формат текстового файла определяется флагами -k (число ключевых полей), -v (число поля значений), и -z (разделитель полей). |
| stab | Просмотры внутренней таблицы символов. Используется внутри для псевдонимизирования. |
| implicit | По-настоящему должно бы называться "alias" - используется для просмотра файлов псевдонимов по умолчанию, и используется по умолчанию, если не определен класс для файлов псевдонимов. |
| user | Просматривает пользователей, используя getpwnam(3). Для указания имени возвращаемого поля может быть использован флаг -v (хотя обычно используется только для проверки существования пользователя). |
| host | Канонифицирует доменные имена хостов. Получив имя хоста, вызывает сервер имен для поиска канонического имени для этого хоста. |
| bestmx | Возвращает лучшую запись MX для заданного в качестве ключа имени хоста. Всегда предпочитается текущая машина- то есть, текущая машина является одним из хостов, перечисленных в качестве записи MX с самым низким значением предпочтения, следовательно, имеется гарантия его возврата. Это может использоваться для определения, является ли эта машина целью записи MX, и почта может быть принята на этом основании. Если задан флаг -z, то возвращаются все имена MX, разделенные заданным разделителем. |
| sequence | Аргументы в
строке "K" - список
преобразований;
результирующее преобразование
просматривает
аргументы-преобразования, пока
не найдет совпадение для
указанного ключа. Например,
если определение ключа: Kmap1 ... Kmap2 ... Kseqmap sequence map1 map2 тогда просмотр "seqmap" сначала производится в map1. Если найдено, то происходит немедленный возврат. Иначе, тот же ключ используется для map2. |
| switch | Прямо как
преобразование "sequence", за
исключением того, что порядок
преобразований определяется
сервисным переключателем.
Аргумент - имя сервиса для
просмотра; значения из
сервисного переключателя
добавляются к имени
преобразования для создания
новых имен преобразований.
Например, рассмотрим
определение ключа: Kali switch aliases вместе с вхождением сервисного переключателя: aliases nis files Это вызовет запрос по преобразованию "ali" для поиска преобразований с именами "ali.nis" и "ali.files" в этом порядке. |
| dequote | Обрезает у
имени двойные кавычки ("). Не
обрезает обратные слеши, и не
будет обрезать кавычки, если
результирующая строка будет
содержать не возможный для
просмотра синтаксис (то есть,
основные ошибки типа
незакрытых угловых скобок;
более сложные ошибки типа
неизвестных хостов не
проверяются). Предназначается
для приема почты из систем типа
DECnet, квотирующих странный
синтаксис типа "49ers::ubell" Обычное использование - что-то типа: Kdequote dequote ... R$- $: $(dequote $1 $) R$- $+ $: $>3 $1 $2 Для предотвращения неожиданных результатов необходима осторожность; например, "|someprogram < input > output" потеряет свои кавычки, но результат, скорее всего, будет отличаться от ожидаемого. К счастью, такие случаи достаточно редки. |
| Regex | Определение
преобразования в строке K
содержит регулярное выражение.
Любой ключевой ввод
сравнивается с этим
выражением, используя
программы регулярных
выражений стандарта POSIX regcomp(),
regerr(), и regexec(). Если вам нужно
узнать больше информации о
сравнении регулярных
выражений, смотрите
документацию на эти программы.
Если не определен флаг -m не
производится никакой
перезаписи ключа. Без него,
если ключ отвергнут или
использован -s, то он
замещается подходящими
подстроками,разделенными $|
или строкой, определенной
флагом -d. Флаги, имеющиеся в
преобразовании: -n не Флаг -sflag выбыирает подстроки в результате просмотра. Например, -s1,3,4 |
| program | Аргументы в строке K являются путями к программам и любые начальные параметры будут пропущены. При вызове преобразования, к начальным параметрам добавляется ключ, а программа запускается с от пользователя и группы по умолчанию. Первая строка стандартного вывода возвращается как значение просмотра. Это все имеет множество потенциальных проблем безопасности, и жутко тормозит, поэтому использоваться должно только тогда, когда действительно необходимо. |
Большинство из них принимают в качестве аргументов одни и те же опциональные флаги и имя файла (или имя преобразования для NIS; имя файла является корнем пути к базе данных, так что ".db" или какое-либо другое расширение будет добавлено для получения настоящего имени базы данных). Известные флаги:
| -o | Указывает, что это преобразование опционально - то есть, если оно не может быть открыто, не выдается ни какой ошибки, а sendmail будет считать, что преобразование было, но было пустым. |
| -N, -O | Если ни -N, ни -O не указаны, sendmail использует адаптивный алгоритм для определения смотреть или нет нулевые байты в конце ключей. Сначала пробуются оба; если находится ключ с нулевым байтом, он никогда снова не будет опробован без нулевого байта и наоборот. Если указан -N, то никогда не пробуется без нулевого байта, а если указан -O, то никогда не пробуется с нулевым байтом. Указание одного из них может увеличить скоромть совпадений, но никогда не является необходимым. Если указаны оба -N и -O, sendmail никогда не будет пробовать никакие совпадения - то есть, все будет считаться неудачным. |
| -ax | Добавить строку x к успешным совпадениям. Например, преобразование по умолчанию host добавляет точку при успешном совпадении. |
| -Tx | Добавить строку x при временной неудаче. |
| -f | Не преобразовывать из верхнего в нижний регистр до просмотра ключа. |
| -m | Только прверка совпадения (без замены значения). Если вы беспокоитесь о существовании ключа, а не о значении (например, при поиске преобразования NIS "hosts.byname"), этот флаг удержит преобразование от замены значения. Однако, аргумент -a все еще добавляется при совпадении, и умолчание все еще берется при несовпадении. |
| -kkeycol | Имя ключевого столбца (для NIS+) или номер (для текстовых просмотров). Для преобразований LDAP это фильтрует строку, проходящую на printf с %s, где вставляется строка для "преобразования". |
| -vvalcol | Имя столбца значения (для NIS+) или номер (для текстовых просмотров). Для преобразований LDAP это имя возвращаемого атрибута. |
| -zdelim | Разделитель столбцов (для текстовых просмотров). Может быть одним знаком или одной из специальных строк "\n" или "\t" для указания новой строки или табуляции соответственно. Если полностью опущен, разделителем столбцов считается любая последовательность пробелов. |
| -t | Обычно, когда преобразование пытается просмотреть имя хоста и сервер ошибочен (то есть, sendmail не может найти ни одного сервера имен; это не то же самое, что вхождение не было найдено в преобразовании), обработанное сообщение ставится в очередь для дальнейшей обработки. Флаг -t отключает такое поведение, позволяя считать, что если происходит временная ошибка (сервер отключен), то это была постоянная ошибка (вхождение не найдено). В частности, это полезно для просмотров DNS, когда чей-то еще неправильно сконфигурированный сервер имен может вызвать проблемы на вашей машине. Однако здесь необходима осторожность, чтобы не откинуть почту, которая могла бы быть разрешена корректно, если бы вы попытались снова. Общая стратегия - перенаправлять такую почту на другой, возможно, имеющий лучшее соединение, почтовый сервер. |
| -sspacesub | Только для преобразования dequote, символ, используемый для замены символов пробела после успешного деквотирования. |
| -q | Не удалять кавычки перед просмотром. |
| -A | При
перестройке файла псевдонимов,
флаг -A заставляет
соединяться дублированные
вхождения в текстовой версии.
Например, два вхождения: list:
user1, user2 при присутствии флага -A будет считаться за одно вхождение list: user1, user2, user3 |
Преобразование dbm добавляет строки ".pag" и ".dir" к заданному имени файла; преобразования hash и btree добавляют ".db". Например, описание преобразования
Kuucp dbm -o -N /usr/lib/uucpmap
Описывает опциональное преобразование класса "dbm" по имени "uucp"; оно всегда имеет нулевые байты в конце каждой строки, и данные находящиеся в /usr/lib/uucpmap.{dir,pag}.
Для постороения преобразований, ориентированных на три базы данных, может быть использована программа makemap(8). Она принимает следующие флаги:
-f |
Не переделывать верхний регистр в нижний при преобразовании. |
-N |
Включать нулевые байты в ключах. |
-o |
Добавить к существующему (старому) файлу. |
-r |
Позволить замещение существующих ключей; обычно, при ошибке, заново вставляет существующий ключ. |
-v |
Печатать происходящее. |
Демон sendmail не должен перестартовываться для чтения новых преобразований до тех пор, пока вы не замените их на месте; используется блокировка файлов, так что преобразования не будут считаны, пока они не обновлены9.
Новые классы могут быть добавлены в подпрограмму setupmaps в файле conf.c.
Если вы имеете версию sendmail с вкомпилированой поддержкой пользовательской базы данных, обработка адресов отправителя и получателя изменена.
Местонахождение это базы данных контролируется опцией UserDatabaseSpec.
База данных является сортированной (основанной на BTree) структурой. Пользовательские записи сохраняются с ключом:
Сортированный формат базы данных гарантирует, что пользовательские записи сгруппированы вместе. Мета-информация всегда сохраняется в ведущем столбце.
Имена полей определяют и синтаксис, и семантику значения. Определенные поля включают:
| maildrop | Адрес доставки для этого пользователя. Эта запись может иметь несколько значений. В частности, списки рассылки будут иметь одну запись maildrop на каждого пользователя в списке. |
| mailname | Выходящее
почтовое имя для этого
пользователя. Для каждого
выходящего имени должна быть
соответствующая запись maildrop
для этого имени, чтобы
разрешить обратную почту. См.
также :default:mailname. |
| mailsender | Каждое сообщение, посланное на этот адрес, будет иметь указанного конвертного отправителя. Предназначено для списков рассылки, и обычно будет именем соответствующего адреса -request. Очень похоже на owner-list синтаксис в файле псевдонимов. |
| fullname | Полное имя пользователя. |
| office-address | Офисный адрес пользователя. |
| office-phone | Офисный телефон пользователя. |
| office-fax | Офисный факс пользователя. |
| home-address | Домашний адрес пользователя. |
| home-phone | Домашний телефон пользователя. |
| home-fax | Домашний факс пользователя. |
| project | (Краткое) описание проекта, которым занимается указанное лицо. В Университете это часто просто имя научного руководителя. |
| plan | Указатель на файл, откуда может быть взята информация о плане. |
Ко времени написания этого документа, только несколько из этих полей на самом деле использовались в sendmail: maildrop и mailname. Запланирована программа finger, использующая остальные поля.
Когда правила перезаписи передают адрес в локальную почтовую программу, имя пользователя пропускается через файл псевдонимов. Если не найдено ни одного псевдонима (или псевдоним указывает обратно на этот адрес), имя (с добавленным ":maildrop") используется как ключ в пользовательской базе данных. Если не найдено ни одного совпадения (или если maildrop указывает на тот же адрес), пробуется пересылка.
Если первая лексема имени пользователя возвращаемая набором правил - знак "@", просмотр пользовательской базы данных пропускается. Смысл этого в том, чтобы пользовательская база данных представляла собой набор умолчаний для группы (в нашем случае, Computer Science Division); почта, посылаемая на определенную машину должна игнорировать эти умолчания.
При отправке почты, имя отправителя просматривается в базе данных. Если этот пользователь имеет запись "mailname", значение этой записи используется как его выходящее имя. Например, я могу иметь запись:
Это приведет к тому, что посланная мной почта будет исходить от Eric.Allman.
Если для пользователя найдена запись "maildrop", но не существует ни одной соответствующей записи "mailname", производится проверка записи ":default:mailname". Если она существует, то это имя считается именем хоста, подставляемого вместо локального хоста. Например, в нашем случае, мы можем установить его в "CS.Berkeley.EDU". в результате, все, кто известен в базе данных будет отправлять почту со штампом "user@CS.Berkeley.EDU", а те, кто в ней не перечислен будут использовать локальное имя хоста.
Пользовательская база данных строится из текстового файла, используя утилиту makemap (в поставке в подкаталоге). Текстовый файл представляет собой последовательность строк, соответствующих записям userdb; каждая строка имеет ключ и значение, разделенные пробелом. Ключ всегда имеет формат, описанный выше - например:
Этот файл обычно устанавливается в системном каталоге; например, он может называться /etc/userdb. Для того, чтобы сделать из преобразования базу данных, запустите программу:
Затем создайте файл конфигурации использующий это. Например, используя V8 M4 конфигурацию, включите в ваш файл .mc строку:
1. На самом деле, это полностью эквивалентно $(host hostname$). В частности, может быть использовано умолчание $:. [назад]
2. Вы можете захотеть использовать это для специальных "пользовательских" расширений. Например, в адресе "jgm+foo@CMU.EDU"; часть "+foo" - это не часть имени пользователя, и передается в локальную почтовую программу для местного использования. [назад]
3. С версии 8.6, все эти макросы имеют разумные умолчания. Предыдущие версии требовали, чтобы они были определены. [назад]
4. Например, в некоторых системах gethostname может возвратить "foo", которое будет преобразовано в "foo.bar.com" посредством gethostbyname. [назад]
5. Старые версии sendmail не предопределяли $j вообще, так что, вплоть до 8.6, файлы конфигурации должны были определять $j. [назад]
6. Старая опция g была комбинирована в опцию DefaultUser. [назад]
7. При запуске в качестве демона, переходит к этому пользователюпосле принятия соединения, но до прочтения любой команды SMTP. [назад]
8. И конечно, поставщики поощряются при включении самих себя в список распознаваемых поставщиков изменением подпрограммы setvendor в conf.c. Для регистрации вашей разновидности пошлите письмо sendmail@Sendmail.ORG. [назад]
9. То есть, не создавайте новые преобразования и не кладите их командой mv(1) на место. Так как преобразования уже открыты, новые преобразования никогда не будут увидены. [назад]
10. Известно, что эти инструкции не полны. Планируется, что будущая версия пользовательской базы данных будет включать вещи типа сервиса finger - и хорошую документацию. [назад]
При перекомпилировании sendmail можно сделать некоторые изменения конфигурации. Этот раздел описывает, какие изменения могут быть сделаны, и что для этого нужно сделать. Во многих случаях это не должно быть необходимым, пока вы не начнете переносить sendmail в новую среду.
6.1. Параметры в BuildTools/OS/$oscf
Эти параметры предназначены для описания среды компиляции, а не правил узла, и обычно должны быть определены в конфигурационном файле для данной операционной системы. Вообще-то этот раздел нужно полностью переписать.
| NDBM | Если установлен, то будет использоваться новая версия библиотеки DBM, разрешающая разнообразные базы данных. Если не установлено ни NDBM, ни NEWDB, используется наименее эффективный метод просмотра псевдонимов. |
| NEWDB | Если он указан, использовать новый пакет баз данных от Berkeley (с 4.4BSD). Этот пакет существенно быстрее, чем DBM или NDBM. Если указаны и NEWDB и NDBM, sendmail будет читать файлы DBM, но будет создавать и использовать файлы NEWDB. |
| NIS | Включить поддержку NIS. Если указанно вместе с NEWDB и NDBM, sendmail будет создавать и DBM и NEWDB файлы только в том случае, если файл псевдонимов включает подстроку "/yp/" в имени. Это предназначено для совместимости с программой mkalias от Sun Microsystems, используемой на мастерах YP. |
| NISPLUS | Вкомпилировать поддержку NIS+. |
| NETINFO | Вкомпилировать поддержку NetInfo (рабочие станции NeXT). |
| LDAPMAP | Вкомпилировать
поддержку запросов LDAP X500. Требует libldap и liblber от Umich LDAP 3.2 или 3.3 release. |
| HESIOD | Вкомпилировать поддержку Hesiod. |
| _PATH_SENDMAILCF | Путь к файлу sendmail.cf. |
| _PATH_SENDMAILPID | Путь к файлу sendmail.pid. |
Есть также несколько флагов компиляции для указания среды, например "_AIX3" и "_SCO_unix_". Смотри файл src/READ_ME, содержащий самое свежее описание собрание этих флагов.
6.2. Параметры в src/conf.h
Параметры и опции компиляции определяются в conf.h. Большинство из них обычно не трогают; все общие параметры находятся в sendmail.cf. Однако, размеры конкретных простейших векторов и т.д., включены в этот файл. Числа, стоящие после параметров означают их значения по умолчанию.
Этот документ не лучший источник информации о флагах компиляции в conf.h - лучше смотреть src/READ_ME или сам src/conf.h.
| MAXLINE [2048] | Максимальная длина строки любой входной строки. Если строки в сообщении превышают эту длину, они все равно будут корректно обработаны; однако, строки заголовков, строки файла конфигурации, строки файла псевдонимов и т.д., должны находиться в пределах этого ограничения. |
| MAXNAME [256] | Максимальная длина любого имени, например имени хоста или пользователя. |
| MAXPV [40] | Максимальное количество параметров для любой почтовой программы. Ограничивает количество получателей, передаваемых за одну транзакцию, и может быть равно любому произвольному числу больше 10, так что sendmail при необходимости будет разбивать доставку на более мелкие пакеты. Большие числа могут уменьшить загрузку вашей системы. |
| MAXATOM [100] | Максимальное количество атомов (лексем) в одном адресе. Например, адрес "eric@CS.Berkeley.EDU" содержит семь атомов. |
| MAXMAILERS [25] | Максимальное количество почтовых программ, определяемых в файле конфигурации. |
| MAXRWSETS [200] | Максимальное количество определяемых наборов правил перезаписи. Первая половина из них зарезервирована для числовой нумерации (например, "S92"), в то время как вторая половина зарезервирована для своей нумерации (например, "Sfoo"). Таким образом, при указании значения 200 попытка использовать "S99" будет успешной, а "S100" - нет. |
| MAXPRIORITIES [25] | Максимальное количество определяемых значений для поля "Precedence:" (используя строку P в sendmail.cf). |
| MAXUSERENVIRON [100] | Максимальное количество переменных окружения пользователя, передаваемых в подчиненные почтовые программы. |
| MAXMXHOSTS [100] | Максимальное количество принимаемых записей MX для любого одиночного хоста. |
| MAXALIASDB [12] | Максимальное количество открываемых баз данных псевдонимов. Заметьте, что также может быть ограничение на количество открытых файлов. |
| MAXMAPSTACK [12] | Максимальное количество преобразований, "кучкуемых" в преобразовании класса sequence. |
| MAXMIMEARGS [20] | Максимальное количество аргументов в заголовке MIME Content-Type:; дополнительные аргументы будут игнорированы. |
| MAXMIMENESTING [20] | Максимальная глубина вложения сообщений MIME (то есть, вложенных документов Message или Multipart; это не ограничивает количество компонент в отдельном документе Multipart). |
Существует множество других опций компиляции. Они определяют включать или нет в компиляцию определенные части кода. Отмеченные знаком | имеют значения 0/1.
| NETINET| | Если установлена, вкомпилируется поддержка сетевого протокола Internet. Предыдущие версии sendmail устанавливали ее опцией DAEMON; это старое использование теперь неправильно. По умолчанию включена; выключите ее, если ваша система не поддерживает протоколы Internet. |
| NETISO| | Если установлена, вкомпилируется поддержка сетевого протокола ISO (она может быть соответственно определена как #define в Makefile вместо conf.h). |
| LOG | Если установлена, то используется программа syslog. Она делает информационные записи в протокол при каждой обработке сообщения, и делает запись в лог более высокого приоритета при внутренних ошибках системы. ОЧЕНЬ РЕКОМЕНДУЕТСЯ - если вам не нужно протоколирование, выключите его в файле конфигурации. |
| MATCHGECOS| | Вкомпилировать код для "нечеткого совпадения " в поле GECOSв /etc/passwd. Также требует, чтобы опция MatchGECOS была включена. |
| NAMED_BIND| | Вкомпилировать код для использования сервера Berkeley Internet Name Domain (BIND) для определения TCP/IP имен хостов. |
| NOTUNIX | Если вы используете почтовый формат, отличный от UNIX, вы можете выставить этот флаг, чтобы отключить специальную обработку строк "From" в стиле UNIX. |
| QUEUE| | Этот флаг должен быть выставлен для включения кода очереди. Если он не установлен, почтовые программы должны принимать почту немедленно, или она будет возвращена отправителю. |
| SMTP| | Если установлен, то будет вкомпилирован код для обработки пользовательского и серверного SMTP. Необходим только в случае, если ваша машина имеет почтовые программы, говорящие на SMTP (то есть большинство машин). |
| USERDB| | Включить экспериментальный пакет Berkeley user Information database. Это добавит новый уровень расширения локальных имен между псевдонимизированием и перенаправлением. Использует пакет NEWDB. Может быть изменено в будущих выпусках. |
Следующие опции обычно включаются в описаниях операционных систем в conf.h.
| IDENTPROTO| | Вкомпилировать протокол IDENT определенный в RFC 1413. По умолчанию включена для всех систем, кроме Ultrix, которая, видимо, имеет такую интересную "особенность", что при получении сообщения "host unreachable", она закрывает все открытые соединения к тому хосту. Из-за того, что некоторые файервольные шлюзы посылают этот код ошибки при соединении с неавторизованным портом (типа 113, используемого IDENT), Ultrix не может получать email с таких хостов. |
| SYSTEM5 | Устанавливает все параметры компиляции, подходящие для System V. |
| HASFLOCK| | Использовать для блокировки Berkeley-style flock вместо SystemV lockf. Вследствие очень необычной семантики блокировок между разветвлениями в lockf, эта опция, по возможности, всегда должна быть использована. |
| HASINITGROUPS | Выставьте эту опцию, если ваша система имеет вызов initgroups()(если вы имеете поддержку множественных групп). Используется по умолчанию, если не определена SYSTEM5, или если у вас HPUX. |
| HASUNAME | Установите ее, если у ваша система имеет системный вызов uname(2) (или соответствующую библиотечную подпрограмму). Используется по умолчанию, если определена SYSTEM5. |
| HASGETDTABLESIZE | Установите ее, если вы имеете системный вызов getdtablesize(2). |
| HASWAITPID | Установите ее, если вы имеете системный вызов haswaitpid(2). |
| SFS_TYPE | Механизм, который может быть использован для получения информации об объеме файловой системы. Значение может быть одним из SFS_USTAT (использует системный вызов ustat(2)), SFS_4ARGS (использует системный вызов statfs(2) с четырьмя аргументами), SFS_VFS (использует системный вызов statfs(2) с двумя аргументами, включая <sys/vfs.h>), SFS_MOUNT (использует системный вызов statfs(2) с двумя аргументами, включая <sys/mount.h>), SFS_STATFS (использует системный вызов statfs(2) с двумя аргументами, включая <sys/statfs.h>), SFS_STATVFS (использует системный вызов statfs(2) с двумя аргументами, включая <sys/statvfs.h>), или SFS_NONE (никаким образом нельзя получить эту информацию). |
| LA_TYPE | Тип средней загрузки. Подробности описаны ниже. |
Существует несколько встроенных способов подсчета средней загрузки. Sendmail пытается автоматически сконфигурировать их на основе несовершенных догадок; вы можете выбрать один из них используя опцию cc -DLA_TYPE=type, где type - это:
| LA_INT | Ядро хранит среднюю загрузку в ядре как целые числа типа long. Настоящие значения масштабируются коэффициентом FSCALE (по умолчанию 256). |
| LA_SHORT | Ядро хранит среднюю загрузку в ядре как целые числа типа short. Настоящие значения масштабируются коэффициентом FSCALE (по умолчанию 256). |
| LA_FLOAT | Ядро хранит среднюю загрузку в ядре как массив чисел с плавающей точкой двойной точности. |
| LA_MACH | Использовать средние загрузки в стиле MACH. |
| LA_SUBR | Вызывать программу getloadavg для получения средних загрузок в виде массива чисел типа double. |
| LA_ZERO | Всегда в качестве средней загрузки возвращать ноль. Это крайний случай. |
Если определен тип LA_INT, LA_SHORT, или LA_FLOAT, вам также может понадобиться определить _PATH_UNIX (путь к вашим системным бинарникам) и LA_AVENRUN (имя переменной, содержащей среднюю загрузку в ядре; обычно "_avenrun" или "avenrun").
6.3. Конфигурация в src/conf.c
В conf.c могут быть сделаны следующие изменения.
Не все семантики заголовков определяются в файле конфигурации. Строки заголовков, которые могут быть включены только определенными почтовыми программами (так же как и другие более скрытые семантики) могут быть определены в таблице HdrInfo в conf.c. Эта таблица содержит имя заголовка (которое должно быть в символах нижнего регистра) и набор управляющих флагов заголовка (описанных ниже). Флаги таковы:
| H_ACHECK | Обычно, когда сделана проверка совместимости строки заголовка с почтовой программой, sendmail не удаляет существующую строку. Если этот флаг выставлен, sendmail будет удалять существующие строки заголовка. То есть, если этот бит выставлен, и почтовая программа не имеет установленные биты флагов, пересекающиеся с требуемыми почтовой программой флагами в определении заголовка в sendmail.cf, строка заголовка всегда уничтожается. |
| H_EOH | Если установлено это поле заголовка, обращаться с ним, как с пустой строкой, т.е. оно сигнализирует о конце заголовка и начале текста сообщения |
| H_FORCE | Добавить это вхождение в заголовок, даже если в сообщении такое уже было. Если вхождение заголовка не имеет этот бит выставленным, sendmail не добавит в заголовок еще одну строку, если строка с таким именем уже имеется в заголовке. Это обычно может быть использовано для того, чтобы каждый, кто обрабатывал это сообщение, оставлял в нем отметку. |
| H_TRACE | Если этот флаг установлен, то это поле временной метки (трассировки). Если количество полей трассировки в сообщении превышает предустановленное значение, сообщение возвращается по подозрению в псевдонимной петле. |
| H_RCPT | Если выставлен, то это поле содержит адреса получателей. Это поле используется флагом -t, когда он собирает получателей из сообщения, чтобы определить, кому посылать. |
| H_FROM | Этот флаг указывает, что это поле определяет отправителя. Порядок этих полей в таблице HdrInfo определяет предпочтение sendmail, по какому полю отправлять сообщения об ошибке. |
| H_ERRORSTO | Адреса в этом заголовке должны получить сообщения об ошибке. |
| H_CTE | Этот заголовок является заголовком Content-Transfer-Encoding. |
| H_CTYPE | Этот заголовок является заголовком Content-Type. |
| H_STRIPVAL | Обрезать значение из заголовка (для Bcc:). |
Давайте взглянем на пример спецификации HdrInfo:
struct hdrinfo HdrInfo[] =
{
/* originator fields, most to least significant */
"resent-sender", H_FROM,
"resent-from", H_FROM,
"sender", H_FROM,
"from", H_FROM,
"full-name", H_ACHECK,
"errors-to", H_FROM|H_ERRORSTO,
/* destination fields */
"to", H_RCPT,
"resent-to", H_RCPT,
"cc", H_RCPT,
"bcc", H_RCPT|H_STRIPVAL,
/* message identification and control */
"message", H_EOH,
"text", H_EOH,
/* trace fields */
"received", H_TRACE|H_FORCE,
/* miscellaneous fields */
"content-transfer-encoding", H_CTE,
"content-type", H_CTYPE,
NULL, 0,
};
Эта структура показывает, что поля "To:", "ResentTo:", и "Cc:" - все они определяют адреса получателей. Любое поле "Full-Name:" будет удалено, пока требуемый флаг почтовой программы (указанный в файле конфигурации) не будет определен. Поля "Message:" и "Text:" будут заканчивать заголовок; они используются различными несогласными протестантами в сетевом мире. Поле "Received:" всегда будет добавлено, и может быть использовано для трассировки сообщений.
Здесь имеется большое количество важных точек. Во-первых, поля заголовка не добавляются автоматически просто потому, что они имеются в структуре HdrInfo; для того, чтобы они добавлялись в сообщение, они должны быть определены в файле конфигурации. Ко всем полям, упомянутым в файле конфигурации, но не упомянутым в структуре HdrInfo применяется обработка по умолчанию; то есть, они добавляются, если их еще нет в сообщении. Во-вторых, структура HdrInfo всего лишь определяет банальную обработку; конкретные заголовки обрабатываются отдельно, специальным кодом, вне зависимости от статуса, определенного в HdrInfo. Например, поля "Sender:" и "From:" всегда просматриваются в почте ARPANET для определения отправителя1; это используется для выполнения функции "вернуть отправителю". Поля "From:" и "Full-Name:" используются для определения полного имени отправителя, если это возможно; оно сохраняется в макросе $x и используется во многих случаях.
Если существует необходимость ограничить прохождение почты через ретранслятор (relay), может быть изменена подпрограмма checkcompat. Эта подпрограмма вызывается для каждого адреса получателя. Она возвращает статус выхода, показывающий статус сообщения. Статус EX_OK принимает адрес, EX_TEMPFAIL ставит сообщение в очередь для более поздней попытки, а другие значения (обычно EX_UNAVAILABLE) отвергают сообщение. При отвержении сообщения checkcompat выдается сообщение об ошибке (используя usrerr). Например, checkcompat может быть такой:
int
checkcompat(to, e)
register ADDRESS *to;
register ENVELOPE *e;
{
register STAB *s;
s = stab("private", ST_MAILER, ST_FIND);
if (s != NULL && e->e_from.q_mailer != LocalMailer &&
to->q_mailer == s->s_mailer)
{
usrerr("No private net mail allowed through this machine");
return (EX_UNAVAILABLE);
}
if (MsgSize > 50000 && bitnset(M_LOCALMAILER, to->q_mailer))
{
usrerr("Message too large for non-local delivery");
e->e_flags |= EF_NORETURN;
return (EX_UNAVAILABLE);
}
return (EX_OK);
}
Такая конструкция будет отвергать сообщения размером более 50000 байт, если они не локальны. Для подавления возврата тела сообщения при ошибке, в e->e flags может быть выставлен флаг EF NORETURN. Конкретное использование этой подпрограммы очень зависит от реализации, и должно быть ограниченным.
Новые ключевые преобразования могут быть добавлены созданием функции инициализации класса и функции просмотра. Они потом добавляются в подпрограмму setupmaps.
Функция инициализации вызывается так:
xxx map init(MAP *map, char *args)
где map является внутренней структурой данных; args - это указатель на кусок строки файла конфигурации с последующим именем класса преобразования; флаги и имена файлов могут быть взяты из этой строки. Функция инициализации должна возвращать TRUE, если она успешно открыла преобразование, и FALSE в другом случае.
Функция просмотра вызывается так:
xxx map lookup(MAP *map, char buf[], char **av, int *statp)
где map внутренне определяет преобразование; buf имеетв входной ключ; Он может быть (и даже очень часто так оно и есть) использован разрушающе; av - список аргументов, передаваемых внутрь из переписываемой строки. Функция просмотра должна возвращать указатель на новое значение. Если просмотр преобразования не успешен, *statp должен быть выставлен на код статуса выхода; в частности, если была произведена попытка восстановления кодом более высокого уровня, он должен быть выставлен в EX_TEMPFAIL,.
6.3.4. Функция Организации Очереди
Для определения того, должно ли быть сообщение поставлено в очередь, или обработано немедленно, используется подпрограмма shouldqueue. Обычно она сравнивает приоритет сообщения с текущей средней загрузкой. Определение по умолчанию таково:
bool
shouldqueue(pri, ctime)
long pri;
time_t ctime;
{
if (CurrentLA < QueueLA)
return (FALSE);
return (pri > (QueueFactor / (CurrentLA - QueueLA + 1)));
}
Если текущая средняя загрузка (глобальная переменная CurrentLA, определяемая до вызова функции) меньше, чем нижний порог средней загрузки (опция x, переменная QueueLA), shouldqueue немедленно возвращает FALSE (то есть, оно не должно быть поставлено в очередь). Если текущая средняя загрузка превышает верхний порог средней загрузки (опция X, переменная RefuseLA), shouldqueue немедленно возвращает TRUE. В других случаях, она подсчитывает функцию основанную на приоритете сообщения, коэффициенте очереди (опция q, глобальная переменная QueueFactor), и текущей и пороговой средней загрузке.
Реализация, которая берет в рассмотрение настоящий возраст сообщения, может также использовать параметр ctime, который является временем первого представления сообщения в sendmail. Заметьте, что параметр pri уже учтен в количестве попыток отсылки сообщения (хотя, со временем это приводит к понижению приоритета сообщения); в ожидании того, что ctime будет использован как "оператор выхода" для гарантии того, что сообщение, в конце концов, обработано.
6.3.6. Отвержение Входящих Соединений SMTP
Если входящее соединение SMTP должно быть отвергнуто, функция refuseconnections возвращает TRUE. Текущая реализация основана исключительно на текущей средней загрузке и опции средней загрузки отказа (опция X, глобальная переменная RefuseLA):
bool
refuseconnections()
{
return (CurrentLA >= RefuseLA);
}
Более умная реализация должна смотреть на большее количество системных ресурсов.
6.3.6. Подсчет Средней Загрузки
Подпрограмма getla возвращает значение текущей средней загрузки (Округленное до целого). Пакет поставки включает несколько возможных реализаций. Если вы портируете в новую среду, вам может понадобиться добавить некотрые новые вещи2.
6.4. Конфигурация в src/daemon.c
Файл src/daemon.c содержит большое количество подпрограмм, зависящих от локальной сетевой среды. Поставляемая версия подразумевает, что вы имеете сокеты в стиле BSD.
В предыдущих выпусках, если вы хотели обобщить просмотры $[ ... $], мы рекомендовали вам изменить подпрограмму maphostname. Теперь, вместо этого, мы рекомендуем вам создавать новое ключевое преобразование.
1. На самом деле, в SMTP такого больше нет; эта информация содержится на конверте. Старые протоколы ARPANET не полностью отличали заголовок от конверта. [назад]
2. Если вы это сделаете, пожалуйста, присылайте изменения по адресу sendmail@Sendmail.ORG. [назад]
Все нижеописанное суммирует изменения, произошедшие в sendmail с последней общедоступной версии (5.67). Полный список изменений содержится в файле RELEASE_NOTES в корневом каталоге поставки sendmail.
Вместо немедленного закрытия соединений SMTP, эти соединений кэшируются для возможного нового использования. Появление записей MX делает кэширование эффективным для списков рассылки; вдобавок, в обработке очереди может быть реальное увеличение производительности.
Если два хоста с разными именами в одном сообщении случайно имеют один и тот же набор MX хостов, то сообщение к ним будет послано за одну транзакцию. Версия 8 обнаруживает это и пытается группировать сообщения.
Было сделано большое количество изменений, для того, чтобы сделать sendmail "условно соответствующим" (то есть, sendmail удовлетворяет всем предложениям "ДОЛЖНО" и большинству, но не всем, предложениям "ХОТЕЛОСЬ БЫ" в RFC 1123).
Основные районы изменений (числа являются номерами секций RFC 1123):
|
5.2.7 |
Быстрый ответ на команду RCPT. |
|
5.2.8 |
Числовые IP адреса протоколируются в строках Received:. |
|
5.2.17 |
Литерал собственного домена обрабатывается правильно. |
|
5.3.2 |
Улучшен контроль над индивидуальными таймаутами. |
|
5.3.3 |
Сообщения об ошибке посылаются как "From:<>". |
|
5.3.3 |
Сообщения об ошибке никогда не посылаются к "<>". |
|
5.3.3 |
Отсекается Route-addrs. |
Области, в которых sendmail не "безусловно совместим":
|
5.2.6 |
Sendmail вносит изменения в заголовок. |
|
5.2.10 |
Sendmail не всегда использует точный текст сообщения SMTP, как описано в RFC 821. |
|
5.3.1.1 |
Sendmail не гарантирует одного единственного соединения на каждый хост во время обработки очереди. |
|
5.3.1.1 |
Sendmail не всегда обеспечивает адекватного ограничения параллельности. |
Версия 8 включает поддержку и приема, и передачи Extended SMTP, как определено в RFC 1651 (основы) и RFC 1653 (РАЗМЕР); и ограниченную поддержку RFC 1652 (ТЕЛО).
Предыдущие версии sendmail используют бит 0200 для квотирования. Эта версия избегает такого использования. Хотя, для совместимости с RFC 822, вы можете установить опцию "7" для получения обрезки до семи бит.
Индивидуальные почтовые программы все еще производить выдачу семибитных сообщений, используя флаг почтовой программы "7".
Пользовательская база данных - это все еще экспериментальная попытка обеспечения поддержки единообразных имен для крупных узлов. Мы устанавливаем ее в Berkeley; будущие версии могут иметь значительные изменения.
Поддержка BIND, в частности для записей MX, имела некоторое количество раздражающих "особенностей", убранных в этом выпуске. В частности, она более жестко привязывает, сервер имен к sendmail, так что правила просмотра сервера имен внесены прямо в sendmail.
Обобщенные ключевые файлы - это идея, взятая прямо из IDA sendmail (абсолютно отличной реализации). Они могут быть полезны на больших узлах. Версия 8 также понимает YP.
Классы теперь могут быть многословными. Например,
CShofmann.CS.Berkeley.EDU
Позволяет вам искать совпадения всей строки "hofmann.CS.Berkeley.EDU" используя одну единственную конструкцию "$=S".
Была адаптирована конструкция $&x от IDA.
Поддерживается определенный в RFC 1413 протокол IDENT.
Устранены несколько небольших багов, типа связанных с экранирующими обратными чертами в комментариях.
Так как строка From: передается отдельно от конвертного отправителя, они оба были сделаны видимыми; макрос $g устанавливается в конвертного отправителя во время обработки вектора аргументов почтовой программы, и в заголовочного отправителя во время обработки заголовков.
Так же имеется возможность определить раздельную обработку конверта и заголовка по почтовой программе. Аргументы SenderRWSet и RecipientRWset для почтовых программ могут быть указаны как конвертный/заголовочный для того, чтобы задать различные правила перезаписи для конвертных и заголовочных адресов.
Когда псевдоним имеет ассоциированное имя списка владельцев, этот псевдоним используется для изменения конвертного адреса отправителя. В результате, при возникновении ошибок, они будут возвращаться к этому владельцу.
Было убрано ограничение на фиксированный размер заголовка.
Был добавлен флаг -B для передачи информации о типе тела.
Был добавлен флаг -p для передачи информации о протоколе.
Для отладки был добавлен флаг -X для разрешения протоколирования всех входящих и выходящих из sendmail протоколов.
Флаг -O означает установку опций в длинном виде.
Флаг -q может ограничить проход очереди определенными получателями, отправителями, или идентификаторами очереди используя -qRподстрока, -qSподстрока, или -qIподстрока соответственно.
Была добавлена строка K для декларирования преобразований баз данных.
Была добавлена строка V для декларирования уровня версии конфигурации.
Строка M имеет поле "D=", позволяющее вам переходить во временный каталог, пока работает эта почтовая программа. Она также имеет поле "U=", разрешающее вам назначить идентификаторы пользователя и группы, используемые для запуска почтовой программы.
Было добавлено несколько новых опций, большинство для поддержки новых свойств, остальные для настройки, которую ранее можно было сделать только перекомпилированием. Подробно они описаны в Разделе 5.6. Вкратце,
|
b |
Утверждает минимальное количество дисковых блоков. |
|
C |
Выставляет интервал контрольных точек. |
|
E |
Сообщение об ошибке по умолчанию. |
|
G |
Включает совпадения GECOS. |
|
h |
Максимальное количество пересылок. |
|
j |
Посылать ошибки в скрытом формате MIME. |
|
J |
Путь к файлу пересылки. |
|
k |
Размер кэша соединений. |
|
K |
Время жизни кэша соединений. |
|
l |
Включить заголовок Errors-To:. Эти заголовки нарушают RFC 1123; эта опция включена для обратной совместимости со старыми версиями sendmail. |
|
O |
Устанавливает входные опции демона SMTP, типа альтернативного порта SMTP. |
|
p |
Опции конфиденциальности. |
|
R |
Не обрезать route-addrs. |
|
U |
Спецификация пользовательской базы данных. |
|
V |
Аварийный хост "MX". |
|
w |
Метод обработки "лучший MX". |
|
7 |
Не полностью восьмибитная работа. |
|
8 |
Восьмибитный режим обработки. |
Опции r (таймаут чтения), I (использовать BIND), и T (таймаут очереди) были расширены для пропуска большей информации.
Было добавлено несколько новых флагов почтовых программ.
|
a |
Попытаться при создании соединения использовать. Если эта опция не выставлена, sendmail все равно будет смотреть в приветственном сообщении другой стороны подсказку, известно ли там о ESMTP; этот флаг говорит, что нужно пробовать ESMTP, даже если в такой подсказки нет. Если команда EHLO (extended hello) не проходит, sendmail откатывается к старому SMTP. |
|
A |
Пробовать пользовательскую часть адресов для этой почтовой программы как псевдонимы. |
|
b |
Обеспечить пустую строку в конце всех сообщений. |
|
c |
Обрезать все комментарии от адресов; это должно использоваться в крайнем случае, при работе с капризными почтовыми программами. |
|
g |
Никогда не использовать нулевого отправителя в качестве конвертного отправителя, даже при работе по SMTP. Это также нарушает RFC 1123, но может быть необходимым, когда вы должны иметь дело с некоторыми несносными старыми хостами. |
|
k |
Выключить проверку закольцовывания в протоколе HELO; если вы ее установите, то могут возникнуть петли почтовой программы. |
|
o |
Всегда запускать почтовую программу в качестве получателя сообщения. |
|
w |
Этот пользователь должен иметь вхождение в файле паролей. |
|
5 |
Если нет локальных псевдонимов, попробовать набор правил 5. |
|
7 |
Обрезать весь вывод до 7 бит. |
|
: |
Проверить на наличие файлов :include:. |
|
| |
Проверить на наличие адресов |program. |
|
/ |
Проверить на наличие адресов /file. |
|
@ |
Проверить этого пользователя в пользовательской базе данных. |
Все опции могут быть определены длинными именами, а некоторые новые опции могут быть определены только длинными именами.
Предопределены следующие макросы:
|
$k |
Имя узла UUCP, номинально из вызова uname(2). |
|
$m |
Доменная часть полного имени нашего хоста. |
|
$_ |
Адрес отправителя по RFC 1413. |
Версия 8 разрешает $@, в левосторонней части строки "R", соответствовать нулевым лексемам. Предназначено для совпадения с нулевым вводом.
Версия 8 имеет до 100 наборов правил вместо 30. Рекомендуется резервировать наборы правил 0-9 для специального использования в будущих выпусках sendmail'ов.
Общее количество используемых записей MX может быть увеличено до 20.
Количество сообщений в очереди, обрабатываемых за один раз было увеличено с 600 до 1000.
В версии 8 параметры по умолчанию настройки очереди изменились так, чтобы сделать количество получателей более важным, чем размер сообщения (для небольших сообщений). Это вполне разумно, если вы имеете достаточно быстрые соединения.
Ранее, синтаксис "Полное Имя <адрес email >" мог выдавать некорректный протокольный вывод, если "Полное Имя" имело специальные символы типа точки. Эта версия проставляет кавычки вокруг таких имен.
В часть $@ почтовой программы $#error было встроено несколько имен.
Предыдущие версии sendmail считали VRFY и EXPN одним и тем же. В этой версии, VRFY не расширяет псевдонимы и не следует файлам .forward. EXPN все еще делает все это.
В качестве оптимизации, если у вас по умолчанию режим приема с постановкой в очередь, или приема в фоне, команда RCPT не будет трогать псевдонимы или файлы .forward. Они будут затронуты при обработке очереди.
Когда адрес разрешается к почтовой программе, имеющей "[IPC]" в качестве "Path", часть $@ (имя хоста) может быть списком хостов, разделенных двоеточиями вместо одного имени хоста. Это попросит sendmail просмотреть список на первое точно имеющееся вхождение, даже если это запись MX. Это предназначено для маршрутизации внутреннего трафика через внутренние сети без выдачи записи MX в сеть. Для индивидуальных целей расширение MX все еще производится.
Реализация была соединена с преобразованиями. Помимо всего прочего, теперь поддерживаются псевдонимы, основанные на NIS.
Было сделано большое количество внутренних изменений, направленных на улучшение переносимости.
Было произведено несколько настроек для увеличения коэффициента параноидальности.
Sendmail пишет файл /etc/sendmail.pid с текущим идентификатором процесса демона SMTP.
Два человека, использующие одну и ту же программу в их файлах .forward считаются различными, так что устранение дубликата не удалит одного из них.
Программа mailstats печатает имена почтовых программ и получает местонахождение файла sendmail.st из /etc/sendmail.cf.
Было исправлено множество небольших багов, типа обработки обратных слешей в кавычках.
Был добавлен крючок (набор правил 5) для того, чтобы было возможно перезаписать локальные адреса после псевдонимизирования.
8. ACKNOWLEDGEMENTS
I've worked on sendmail for many years, and many employers have been remarkably patient about letting me work on a large project that was not part of my official job. This includes time on the INGRES Project at the University of California at Berkeley, at Britton Lee, and again on the Mammoth and Titan Projects at Berkeley.
Much of the second wave of improvements should be credited to Bryan Costales of ICSI. As he passed me drafts of his book on sendmail I was inspired to start working on things again. Bryan was also available to bounce ideas off of.
Many, many people contributed chunks of code and ideas to sendmail. It has proven to be a group network effort. Version 8 in particular was a group project. The following people made notable contributions:
John Beck, Hewlett-Packard
Keith Bostic, CSRG, University of California, Berkeley Andrew Cheng, Sun Microsystems
Michael J. Corrigan, University of California, San Diego Bryan Costales, International Computer Science Institute Par (Pell) Emanuelsson
Craig Everhart, Transarc Corporation
Tom Ivar Helbekkmo, Norwegian School of Economics
Allan E. Johannesen, WPI
Jonathan Kamens, OpenVision Technologies, Inc.
Takahiro Kanbe, Fuji Xerox Information Systems Co., Ltd. Brian Kantor, University of California, San Diego
Murray S. Kucherawy, HookUp Communication Corp.
Bruce Lilly, Sony U.S.
Karl London
Motonori Nakamura, Ritsumeikan University & Kyoto University John Gardiner Myers, Carnegie Mellon University
Neil Rickert, Northern Illinois University
Eric Schnoebelen, Convex Computer Corp.
Eric Wassenaar, National Institute for Nuclear and High Energy Physics, Amsterdam Christophe Wolfhugel, Pasteur Institute & Herve Schauer Consultants (Paris)
I apologize for anyone I have omitted, misspelled, misattributed, or otherwise missed. At this point, I suspect
that at least a hundred people have contributed code, and many more have contributed ideas, comments, and encouragement. I've tried to list them in the RELEASE_NOTES in the distribution directory. I appreciate their contribution as well.
Special thanks are reserved for Michael Corrigan and Christophe Wolfhugel, who besides being wonderful guinea pigs and contributors have also consented to be added to the "sendmail@Sendmail.ORG" list and, by answering the bulk of the questions sent to that list, have freed me up to do other work.