2. НОРМАЛЬНАЯ РАБОТА

2.1. Системный Протокол

Системный протокол поддерживается программой syslogd(8). Все сообщения от sendmail протоколируются посредством LOG_MAIL¹.

2.1.1. Формат

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

После обработки сообщения обычно протоколируются две строки. Первая отмечает получение сообщения; на каждое сообщение будет ровно одна такая строка. Некоторые поля могут быть пропущены, если они не содержат интересной информации. Поля такие: from Конвертный адрес отправителя size Размер сообщения в байтах class Класс (т.е. числовой приоритет) сообщения pri Начальный приоритет сообщения (используется для сортировки очереди) nrcpts Количество почтовых получателей для этого сообщения (после обработки псевдонимов и перенаправлений) msgid Идентификационный номер сообщения (из заголовка) proto Протокол, использовавшийся при получении этого сообщения (например, ESMTP или UUCP) relay Машина, от которой было получено сообщение

На каждую попытку доставки сообщения записываетя еще одна строка (так что каждое сообщение таких строк может быть несколько, например, если оно отложено, или если имеется несколько получателей). Поля в этой строке таковы: to Список получателей для этой почтовой программы, разделенный запятыми. ctladdr "Контрольный пользователь", то есть, имя пользователя, чьи параметры мы используем при доставке. delay Общее время задержки между получением и доставкой сообщения. xdelay Время, понадобившееся для попытки доставки (обычно показывает скорость соединения). mailer Имя почтовой программы, использовавшейся для доставки к данному получателю. relay Имя хоста, принявшего сообщение для данного получателя (или отказавшего в доставке). stat Статус доставки.

Не все эти поля присутствуют для всех сообщений; например, для локальных сообщений отсутствует поле relay.

2.1.2. Уровни

Если у вас установлен syslogd(8) или его эквивалент, то вы можете производить протоколирование. Имеется большое количество информации, которое можно запротоколировать. Протокол организован как последовательность уровней. На самом нижнем уровне протоколируются только самые странные ситуации. На самом высоком уровне даже самые обычные и неинтересные события записываются для потомства. Согласно соглашению, уровни протоколирования ниже десятого обычно считаются "полезными"; уровни протоколирования выше 64 зарезервированы для целей отладки. Уровни с 11 по 64 зарезервированы для многословной информации, что могут захотеть некоторые узлы.

Полное описание уровней протоколирования дано в разделе 4.6.

2.2. Состояние Сброса

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

2.3. Почтовая Очередь

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

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

2.3.1. Печать Очереди

Содержимое очереди можно распечатать, используя команду mailq (или указав sendmail флаг -bp):

mailq

Результатом ее выполнения будет список идентификаторов сообщений, находящихся в очереди, размеров сообщений, даты поступления сообщения в очередь, и отправитель с получателями.

2.3.2. Ускорение Очереди

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

Не производится ни одной попытки удостовериться в том, что только один обработчик очереди существует в любое время, поэтому нет никакой гарантии, что работа не будет производиться вечно (однако, sendmail имеет некоторую эвристику, чтобы попытаться прекратить работу, занимающую абсурдно большое количество времени; технологически, это нарушает требования RFC 821, но одобряется в RFC 1123). Согласно алгоритму блокировки, одна работа не может заморозить всю очередь. Однако, недружественный принимающий хост, или программа приема, которая никогда ничего не возвращает, может собрать большое количество процессов в вашей системе. К несчастью, нет никакого общего решения для разрешения подобных проблем.

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

Чтобы это сделать, вполне возможно перенести весь каталог очереди:

cd /var/spool
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue

Затем вы должны убить работающий демон (потому что он все еще будет продолжать обрабатывать старый каталог очереди) и создать нового демона.

Чтобы обработать старую очередь, запустите следующую команду:

/usr/sbin/sendmail -oQ/var/spool/omqueue -q

Флаг -oQ определит альтернативный каталог очереди, а флаг -q скажет о том, что нужна всего лишь обработка каждого сообщения в очереди. Если у вас имеется тяга к вуайеризму, вы можете использовать флаг -v, чтобы посмотреть, что будет происходить.

Когда в очереди наконец-то не останется ни одного сообщения, вы сможете удалить этот каталог:

rmdir /var/spool/omqueue

2.4. Дисковая Информация о Соединении

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

Дополнительно, включение опции SingleThreadDelivery даст дополнительный эффект доставки почты к месту назначения одной цепочкой. Это может очень помочь, если на удаленной машине работает сервер SMTP, который легко перегружается, или может работать только с одним соединением за раз. Она применяется ко всем хостам, поэтому установите ее, если на вашем узле для доставки почты используется одна машина, на которой работает дополнительное программное обеспечение, увеличивающее загрузку машины, что может привести к замедлению доставки почты на другие хосты. Установите эту опцию, если вы имеете на вашем узле одну почтовую машину, и на ней еще работают приложения, которые могут увеличить ее загрузку, замедлив обработку почты. Если эта опция выставлена, то вам, возможно, захочется выставить опцию MinQueueAge, чтобы ваша очередь обрабатывалась достаточно часто; в результате работы, пропущенные по причине того, что другой процесс sendmail разговаривал с тем же хостом, вскоре были опробованы снова, а не отложены на долгое время.

Информация о хостах сохраняется на диске в подкаталоге .hoststat³ каталога mqueue. Удаление этого каталога с его подкаталогами равносильно команде purgestat и вполне безопасно. Информация из этих каталогов может быть просмотрена командой hoststat, которая покажет имя хоста, последний доступ и статус этого доступа. Звездочка в самой левой колонке означает, что процесс sendmail в настоящее время имеет блокировку на доставку почты на этот хост.

В целях оптимизации таймаутов, информация, сохраняемая на диске, обслуживается таким же образом, что и информация, хранимая в памяти. По умолчанию, информация об ошибках хостов действительна в течение 30 минут. Это значение может быть изменено опцией Timeout.hoststatus.

Информация о соединении, сохраненная на диске, может быть очищена в любой момент командой purgestat, или запуском sendmail с ключом -bH. Информацию о соединении можно просмотреть командой hoststat, или запуском sendmail с ключом -bh.

2.5. Сервисный Переключатель

Реализация системных сервисов, таких, как определение имени хоста и пользователя управляется сервисным переключателем. Если операционная система хоста поддерживает такой переключатель, то sendmail будет использовать родную версию. Ultrix, Solaris, и DEC OSF/1 - примеры таких операционных систем. И хотя HP-UX 10 имеет поддержку сервисного переключателя, но, так как API не поддерживается библиотеками, sendmail в этот раз не использует родной сервисный переключатель.

Если операционная система не поддерживает сервисный переключатель (например, SunOS, HP-UX, BSD), то sendmail будет использовать свою реализацию. Опция ServiceSwitchFile указывает на имя файла, содержащего определения сервисов. Каждая строка содержит имя сервиса и возможные реализации этого сервиса. Например, файл:

hosts dns files nis
aliases files nis

попросит sendmail просматривать имена хостов сначала в Domain Name System. Если запрошенное имя хоста не найдено, он попробует локальные файлы, если и там не найдет, то попробует NIS. Точно также, при просмтре псевдонимов, сначала он попробует локальные файлы, а затем NIS.

Сервисные переключатели не полностью интегрированы. Например, несмотря на то, что в вышеописанном примере имя хоста необходимо смотреть в NIS, в SunOS этого не произойдет, из-за того, что системная реализация gethostbyname(3) не понимает этого. Если имеется достаточно причин, sendmail может использовать свои реализации gethostbyname(3), gethostbyaddr(3), getpwent(3), и других системных подпрограмм, которые необходимы для его нормальной работы.

2.6. База Данных Псевдонимов

После получения адресов получателей из соединения SMTP или командной строки, они обрабатываются согласно набору правил 0, которые должны определить тройку {mailer, host, user}. Если флаги выбранные mailer'ом включают флаг A (aliasable), часть тройки user рассматривается как ключ (т.е., левосторонняя) в базе данных псевдонимов (aliases). Если имеется совпадение, адрес удаляется из очереди на отсылку, а все адреса с правой стороны псевдонима добавляются вместо найденного псевдонима. Эта операция является рекурсивной, поэтому псевдонимы, найденные в правосторонней части псевдонима обрабатываются таким же образом.

База данных псевдонимов существует в двух видах. Один - текстовая форма, содержащаяся в файле /etc/aliases. Псевдонимы имеют следующий вид

name: name1, name2, ...

Только локальные имена могут быть псевдонимизированы; например,

eric@prep.ai.MIT.EDU: eric@CS.Berkeley.EDU

не возымеет ожидаемого эффекта (если это не на prep.ai.MIT.EDU, но я им точно не нужен)⁴.Псевдонимы могут быть продолжены началом любых строк-продолжений с пробелом или табуляцией. Пустые строки и строки, начинающиеся со знака диез ("#") считаются комментариями.

Вторая форма обрабатывается библиотекой ndbm(3)⁵. Эта форма находится в файлах /etc/aliases.db (если используется NEWDB) или /etc/aliases.dir и /etc/aliases.pag (если используется NDBM). Эта именно та форма, которую использует sendmail при определении псевдонимов. Эта технология используется для увеличения производительности.

Управление порядком поиска выставляется непосредственно сервисным переключателем. По существу, вхождение

OAswitch:aliases

всегда добавляется как первое вхождение псевдонимов; также, первое имя файла псевдонимов без класса (например, без "nis:" вначале) будет использовано как имя файла для вхождения "files" в переключателе псевдонимов. Например, если конфигурация содержит

OA/etc/aliases,

а сервисный переключатель содержит

aliases nis files nisplus

то псевдонимы будут сначала искаться в базе данных NIS, затем в /etc/aliases, а затем в базе данных NIS+.

Вы также можете использовать файлы псевдонимов на основе NIS. Например, определение:

OAliasFile=/etc/aliases
OAliasFile=nis:mail.aliases@my.nis.domain

будет сначала искать файл /etc/aliases, а затем карту с именем "mail.aliases" в "my.nis.domain". Внимание: если вы строите свой собственный файл псевдонимов на основе NIS, обязательно поставьте флаг -l для makedbm(8) для преобразования заглавных букв в ключах в строчные; иначе псевдонимы с заглавными буквами в именах не будут совпадать с входящими адресами.

Дополнительные флаги могут быть добавлены после двоеточия, точно как строка K; например:

OAliasFile=nis:-N mail.aliases@my.nis.domain

будет искать соответствующую карту NIS и всегда иметь ноль байт в ключе. Также

OAliasFile=nis:-f mail.aliases@my.nis.domain

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

2.6.1. Перестроение Базы Данных Псевдонимов

Версия базы данных в виде hash или dbm может быть перестроена выполнением команды

newaliases

Это эквивалентно заданию sendmail флага -bi:

/usr/sbin/sendmail -bi

Если в конфигурации определена опция RebuildAliases (раннее D), sendmail будет перестраивать базу данных псевдонимов автоматически, если она может быть старой. Автоматическая перестройка может быть опасной на сильно загруженных машинах с большими файлами псевдонимов; если перестроение базы займет больше чем таймаут перестройки базы (опция AliasWait, ранее a, нормальное значение которой равно пяти минутам), то вполне возможно, что будут запущены одновременно несколько процессов перестройки.

Если вы определили несколько баз данных псевдонимов, флаг -bi перестроит все типы баз данных, которые он понимает (например, он может перестраивать базы данных NDBM, но не может базы данных NIS).

2.6.2. Потенциальные проблемы

Существует несколько проблем, которые могут случиться с базой данных псевдонимов. Все они происходят из того, что процесс sendmail может начать использовать DBM-версию псевдонимов, когда она будет построена только частично. Это может случиться при двух условиях: один процесс использует базу данных, в то время как второй ее перестраивает, или процесс, занимающийся перестройкой базы данных, умирает (из-за того, что его убили, или система вдруг упала) до полного завершения перестройки.

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

@: @

(что вообще-то нелегально). Перед тем, как sendmail будет использовать базу данных, он произведет проверку на наличие этого вхождения ⁶.

2.6.3. Владельцы Списков

Если при посылке на определенный адрес, скажем ,"x", произойдет ошибка, sendmail будет искать псевдоним вида "owner-x" для получения ошибки. Это обычно полезно для списков рассылки, где подписчик сам не имеет управления поддержкой списка; в этом случае, держатель списка может быть владельцем списка. Например:

unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser, sam@matisse
owner-unix-wizards: unix-wizards-request
unix-wizards-request: eric@ucbarpa

заставит "eric@ucbarpa" получать ошибки, которые произойдут, когда кто-нибудь посылает в unix-wizards и попадает под вхождение "nosuchuser" в списке.

Владельцы списков также изменяют почтовый адрес отправителя. Используется содержимое псевдонима владельца, если оно указывает на одного пользователя, иначе будет использоваться само имя псевдонима. По этой причине, и в соответствии с соглашениями Internet, адрес "owner-" обычно указывает на адрес "-request"; это позволяет сообщениям следовать типичным соглашениям Internet об использовании "listrequest" как обратный адрес.

2.7. База Данных Пользовательской Информации

Если вы имеете версию sendmail с вкомпиллированной базой данных пользовательской информации, и определили одну или несколько баз данных используя опцию U, базы данных будут просмотрены в поисках вхождения user:maildrop. Если такое будет найдено, почта будет послана по указанному адресу.

2.8. Пользовательская пересылка (файлы .forward)

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

mckusick@ernie
kirk@calder

то любая почта, поступившая для "mckusick" будет перенаправлена по указанным адресам.

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

2.9. Специальные Строки Заголовка

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

2.9.1. Errors-To:

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

Заголовок Errors-To: был создан в плохие старые времена, когда UUCP не понимал различий между содержимым и заголовком; Это было встроено для того, чтобы указать, что должно быть теперь пропущено как адрес отправителя сообщения. Это должно уйти, но пока еще используется, если выставлена опция UseErrorsTo.

Заголовок Errors-To: официально уже убран, и в последующих выпусках должен отсутствовать.

2.9.2. Apparently-To:

RFC 822 требует в каждом сообщении иметь по крайней мере одно поле получателя (строку To:, Cc:, или Bcc:). Если сообщение приходит без указания какого-либо получателя в сообщении, sendmail добавит заголовок на основе опции "NoRecipientAction". Одним из возможных действий будет добавка в заголовок строки "Apparently-To:" для каждого получателя, о котором он знает.

Заголовок Apparently-To: не стандартен и удален.

2.9.3. Precedence

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

2.10. Поддержка Протокола IDENT

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. Обычно она должна быть определена.

Назад | Содержание | Вперед