| |
После обработки сообщения обычно протоколируются две строки. Первая
отмечает получение сообщения; на каждое сообщение будет ровно одна такая
строка. Некоторые поля могут быть пропущены, если они не содержат интересной
информации. Поля такие:
from | Конвертный адрес отправителя |
size | Размер сообщения в байтах |
class | Класс (т.е. числовой приоритет) сообщения |
pri | Начальный приоритет сообщения (используется для сортировки очереди) |
nrcpts | Количество почтовых получателей для этого сообщения (после обработки псевдонимов и перенаправлений) |
msgid | Идентификационный номер сообщения (из заголовка) |
proto | Протокол, использовавшийся при получении этого сообщения (например, ESMTP или UUCP) |
daemon | Имя демона из установок DaemonPortOptions |
relay | Машина, от которой было получено сообщение |
На каждую попытку доставки сообщения записываетя еще одна строка (так
что каждое сообщение таких строк может быть несколько, например, если оно
отложено, или если имеется несколько получателей). Поля в этой строке таковы:
to | Список получателей для этой почтовой программы, разделенный запятыми. |
ctladdr | "Контрольный пользователь", то есть, имя пользователя, чьи параметры мы используем при доставке. |
delay | Общее время задержки между получением и доставкой сообщения. |
xdelay | Время, понадобившееся для попытки доставки (обычно показывает скорость соединения). |
mailer | Имя почтовой программы, использовавшейся для доставки к данному получателю. |
relay | Имя хоста, принявшего сообщение для данного получателя (или отказавшего в доставке). |
dsn | Усовершенствованный код ошибки (RFC 2034), если доступен |
stat | Статус доставки. |
Не все эти поля присутствуют для всех сообщений; например, для локальных сообщений отсутствует поле relay.
Полное описание уровней протоколирования дано в разделе 4.6.
При нормальных условиях почтовая очередь будет обрабатываться прозрачно. Однако вы можете обнаружить, что иногда необходимо вмешаться руками. Например, если основной хост долгое время отключен, очередь может засориться. Хотя sendmail должен нормально восстановить все при загрузке хоста, тем временем вы можете найти его производительность неприемлемо низкой.
Не производится ни одной попытки удостовериться в том, что только один обработчик очереди существует в любое время, поэтому нет никакой гарантии, что работа не будет производиться вечно (однако, sendmail имеет некоторую эвристику, чтобы попытаться прекратить работу, занимающую абсурдно большое количество времени; технологически, это нарушает требования RFC 821, но одобряется в RFC 1123). Согласно алгоритму блокировки, одна работа не может заморозить всю очередь. Однако, недружественный принимающий хост, или программа приема, которая никогда ничего не возвращает, может собрать большое количество процессов в вашей системе. К несчастью, нет никакого общего решения для разрешения подобных проблем.
В некоторых случаях, вы можете заметить, что основной хост второй день как упал, и у вас накопилась невероятно большая очередь. В результате sendmail большую часть времени будет проводить, сортируя эту очередь. Эта ситуация может быть исправлена, если вы уберете очередь в какое-то временное место и создадите новую очередь. Старую очередь можно будет обработать позже, когда хост-нарушитель опять начнет работать.
Чтобы это сделать, вполне возможно перенести весь каталог очереди:
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue
Чтобы обработать старую очередь, запустите следующую команду:
Когда в очереди наконец-то не останется ни одного сообщения, вы сможете удалить этот каталог:
Дополнительно, включение опции SingleThreadDelivery даст дополнительный эффект доставки почты к месту назначения одной цепочкой. Это может очень помочь, если на удаленной машине работает сервер SMTP, который легко нагружается, или может работать только с одним соединением за раз. Она применяется ко всем хостам, поэтому её установка по причине того, что на вашем узле для доставки почты используется одна машина, на которой работает дополнительное программное обеспечение, увеличивающее загрузку машины, может привести к замедлению доставки почты на другие хосты. Если эта опция выставлена, то вам, возможно, захочется выставить опцию MinQueueAge, чтобы ваша очередь обрабатывалась достаточно часто; в результате работы, пропущенные по причине того, что другой процесс sendmail разговаривал с тем же хостом, вскоре будут опробованы снова, а не отложены на долгое время.
Информация о хостах сохраняется на диске в подкаталоге .hoststat3каталога mqueue. Удаление этого каталога с его подкаталогами равносильно команде purgestat и вполне безопасно. Однако, purgestat всего лишь удаляет устаревшие (Timeout.hoststatus) файлы. Информация из этих каталогов может быть просмотрена командой hoststat, которая покажет имя хоста, последний доступ и статус этого доступа. Звездочка в самой левой колонке означает, что процесс sendmail в настоящее время имеет блокировку на доставку почты на этот хост.
В целях оптимизации таймаутов, информация, сохраняемая на диске, обслуживается таким же образом, что и информация, хранимая в памяти. По умолчанию, информация об ошибках хостов действительна в течение 30 минут. Это значение может быть изменено опцией Timeout.hoststatus.
С дисковой информацией о соединениях в отношении таймаутов обращаются так же, как и с той, что находится в памяти. По умолчанию, информация о неудачах с хостами считается действительной в течение 30 минут. Это значение может быть изменено опцией Timeout.hoststatus.
Информация о соединении, сохраненная на диске, может быть очищена в любой момент командой purgestat, или запуском sendmail с ключом -bH. Информацию о соединении можно просмотреть командой hoststat, или запуском sendmail с ключом -bh.
Если операционная система не поддерживает сервисный переключатель (например, SunOS 4.x, HP-UX, BSD), то sendmail будет использовать свою фиктивную реализацию. Опция ServiceSwitchFile указывает на имя файла, содержащего определения сервисов. Каждая строка содержит имя сервиса и возможные реализации этого сервиса. Например, файл:
Сервисные переключатели не полностью интегрированы. Например, несмотря на то, что в вышеописанном примере имя хоста необходимо смотреть в NIS, в SunOS этого не произойдет, из-за того, что системная реализация gethostbyname(3) не понимает этого. Если имеется достаточно причин, sendmail может использовать свои реализации gethostbyname(3), gethostbyaddr(3), getpwent(3), и других системных подпрограмм, которые будут необходимы для безглючной работы.
База данных псевдонимов существует в двух видах. Один - текстовая форма, содержащаяся в файле /etc/mail/aliases. Псевдонимы имеют следующий вид
Вторая форма обрабатывается библиотекой ndbm(3)5 или библиотекой Berkley DB. Эта форма находится в файлах /etc/mail/aliases.db (если используется NEWDB) или /etc/mail/aliases.dir и /etc/mail/aliases.pag (если используется NDBM). Это именно та форма, которую использует sendmail при определении псевдонимов. Эта технология используется для увеличения производительности.
Управление порядком поиска выставляется непосредственно сервисным переключателем. По существу, вхождение
Вы также можете использовать файлы псевдонимов на основе NIS. Например, определение:
O AliasFile=nis:[email protected]
Дополнительные флаги могут быть добавлены после двоеточия, точно как строка K; например:
Если вы определили несколько баз данных псевдонимов, флаг -bi перестроит все типы баз данных, которые он понимает (например, он может перестраивать базы данных NDBM, но не может базы данных NIS).
Sendmail имеет три метода, чтобы попытаться избавиться от этих проблем. Первый - он игнорирует прерывания во время перестройки базы данных; это позволяет избежать случая, когда кто-нибудь прекращает процесс, оставляя частично перестроенную базу данных. Второй - он блокирует исходный файл базы данных во время перестройки - но это может не работать поверх NFS или если файл защищен на запись. Третий - в конце перестройки он добавляет псевдоним в виде
owner-unix-wizards: unix-wizards-request
unix-wizards-request: eric@ucbarpa
Владельцы списков также изменяют почтовый адрес отправителя. Используется содержимое псевдонима владельца, если оно указывает на одного пользователя, иначе будет использоваться само имя псевдонима. По этой причине, и в соответствии с соглашениями Internet, адрес "owner-" обычно указывает на адрес "-request"; это позволяет сообщениям следовать типичным соглашениям Internet об использовании "list-request" как обратный адрес.
kirk@calder
На самом деле, файл конфигурации определяет последовательность проверяемых имен файлов. По умолчанию, это пользовательский файл .forward, но может быть определен по-другому, используя опцию ForwardPath. Если вы ее измените, вы должны будете проинформировать ваших основных пользователей об изменении; .forward очень хорошо вошло в коллективное подсознание.
Заголовок Errors-To: был создан в плохие старые времена, когда UUCP не понимал различий между содержимым и заголовком; Это было встроено для того, чтобы указать, что должно быть теперь пропущено как адрес отправителя сообщения. Это будет убрано, но пока еще используется, если выставлена опция UseErrorsTo.
Заголовок Errors-To: официально уже убран, и в последующих выпусках будет отсутствовать.
Заголовок Apparently-To: нестандартен и опротестован.
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. Обычно она должна быть определена. [назад]
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |