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

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

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

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

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

Не все эти поля присутствуют для всех сообщений; например, для локальных сообщений отсутствует поле 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 большую часть времени будет проводить, сортируя эту очередь. Эта ситуация может быть исправлена, если вы уберете очередь в какое-то временное место и создадите новую очередь. Старую очередь можно будет обработать позже, когда хост-нарушитель опять начнет работать.

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

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

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

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

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

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

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

Информация о хостах сохраняется на диске в подкаталоге .hoststat³ каталога 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, но я им точно не нужен)⁴.Псевдонимы могут быть продолжены началом любых строк-продолжений с пробелом или табуляцией. Пустые строки и строки, начинающиеся со знака диез ("#") считаются комментариями.

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

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

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

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

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

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

будет сначала искать файл /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 будет использовать базу данных, он произведет проверку на наличие этого вхождения⁶.

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

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

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

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

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

то любая почта, поступившая для "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 различные средства. [назад]