48. Файлы логов

    Exim пишет три различных лога, называемых - главный лог, лог отклонённых, и лог паники:


• В главном логе записывается приход каждого сообщения, и каждая доставка, по одной строке на каждый случай. Формат - компактен насколько возможно, с целью попытаться уменьшить размер лог-файлов. Двухсимвольная последовательности флага облегчают выбор этих строк. Множество иных событий записывается в главный лог. Некоторые из них - опциональны, управляемые включением или выключением опции селектора логов “log_selector”. Perl`овый скрипт, называемый “eximstats”, производит простой анализ файлов главного лога, предоставляется в дистрибутиве exim`a (смотрите раздел 49.7).

• В лог отклонённых записывается информация из сообщений, которые были отклонены как результат конфигурационных опций (т.е. по причинам политик). Первая строка каждого отклонения - копия строки, которая, также, пишется в главный лог. Затем, если заголовки сообщения были прочитаны во время записи лога, их содержимое пишется в этот лог. Доступны лишь оригинальные строки заголовоков; заголовки добавленные ACL - не логгируются. Вы можете использовать лог отклонённых для проверки, что ваши политики работают корректно; на загруженных хостах это может быть более легким чем сканирование главного лога на отклонённые сообщения. Вы можете подавить запись лога отклонённых путём установки “write_rejectlog” в ложь.

• Когда происходят определённые серьёзные ошибки, exim делает запись в лог паники. Если ошибка достаточно серьёзная, exim прекращает работу. Записи в лог паники, обычно, также пишутся в главный лог, но могут теряться среди массы других записей. В обычных обстоятельствах, лог паники должен быть пустой. Хорошая идея - проверять его регулярно (или скрипт в “cron”, который будет это делать), с целью узнать о проблемах. Когда exim yе может открыть свой лог паники, он пытается, как последнее средство, записать в системный лог (syslog). Он открывается с LOG_PID+LOG_CONS и кодом средства LOG_MAIL. Само сообщение пишется с приоритетом LOG_CRIT.

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


  2001-09-16 16:09:47 SMTP connection from [127.0.0.1] closed by QUIT

     По умолчанию, штампы времени в локальной временной зоне. Есть два способа это изменить:


• Вы можете установить опцию “timezone” в иную временную зону; в частности, вы можете установить:


  timezone = UTC

  для штампов времени в UTC (который - GMT).


• Вы можете установить “log_timezone” в истину, для добавления временной зоны к штампу времени, например:


  2003-04-25 11:17:07 +0100 Start queue run: pid=12762

  48.1 Где пишутся логи

     Логи могут быть записаны в локальные файлы, или в syslog, или и туда и туда. Однако, нужно отметить, что многие реализации syslog используют в качестве транспорта UDP, и ненадёжны, в смысле, что не гарантируется прибытие сообщений на хост логгирования, и при этом порядок сообщений не обязательно поддерживается. Также сообщалось, что на больших файлах логов (десятки мегабайт), возможно, вам необходимо настроить syslog, для предотвращения синхронизации файла при каждой записи - на linux было замечено, что это вызывало 90% загрузку центрального процессора.
Назначение для логов exim`a конфигурируется путём установки LOG_FILE_PATH в “Local/Makefile”, или путём установки “log_file_path” в рабочей конфигурации. Эта, последняя, строка раскрывается, и, таким образом, она может содержать, например, ссылки на имя хоста:


  log_file_path = /var/log/$primary_hostname/exim_%slog

     Вообще, желательна установка строки в “Local/Makefile”, вместо рабочей конфигурации, поскольку в этом случае установка доступна с самого начала выполнения exim`a. Иначе, если будет нужно залоггировать что-то до чтения конфигурационного файла (например, ошибку в конфигурационном файле), он не сможет использовать путь который вы хотите, и может оказаться не в состоянии залоггировать вообще что бы то нибыло.
Значение LOG_FILE_PATH или “log_file_path” - список разделённый двоеточиями, в настоящее время ограниченный максимум двумя элементами. Это - единственная опция, где не может использоваться средство для изменения разделителя списка. Этот список всегда должен быть разделён двоеточиями. Если элемент в списке - “syslog”, тогда используется syslog; иначе, элемент должен быть абсолютным путём, содержащим “%s”как точку, где должны быть вставлены “main”, “reject”, или “panic”, или быть пустым, подразумевая использование дефолтового пути.
Когда exim сталкивается с пустым элементом в списке, он ищет список, заданный путём LOG_FILE_PATH, и использует первый найденный элемент, если он не пустой, или не “syslog”. Это означает, что в “log_file_path” может использоваться пустой элемент, для обозначения “использовать путь заданный при сборке”. Если элемента не существует, лог файлы пишутся в субдиректорию “log”, в директории спула. Это эквивалентно установке:


  log_file_path = $spool_directory/log/%slog

     Если вы не определили что-то при компиляции или в рабочей конфигурации, логи пишутся по указанному пути.
Путь к логам может содержать “%D”, если в имени логов используется штамп даты - смотрите секцию 48.3, ниже.
Вот - некоторые примеры возможных установок:


  LOG_FILE_PATH=syslog syslog only LOG_FILE_PATH=:syslog syslog and default path LOG_FILE_PATH=syslog : /usr/log/exim_%s syslog and specified path LOG_FILE_PATH=/usr/log/exim_%s specified path only

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

  48.2 Логгинг в локальные файлы, которые периодически ротируются

     Некоторые операционные системы предоставляют централизованные и стандартизованные методы для ротации файлов логов. Для тех, которые этого не делают, предоставляется скрипт утилиты с именем “exicyclog” (смотрите секцию [url=/?id=1249#49.6]49.6[/url). Он переименовывает и сжимает главный лог, и лог отклонённых при каждом его вызове. Может быть настроено максимальное число оставляемых старых логов. Предполагается, что этот скрипт запускается как ежедневное задание “cron”.
Процесс доставки exim`a открывает главный лог когда ему первый раз необходимо в него записать, и оставляет его открытым в случае, если требуется последующая запись - например, если для одного и того же сообщения производится несколько различных доставок. Однако, удалённые SMTP-доставки могут занять много времени, и это означает, что файл может оставаться открытым после его переименования, если “exicyclog”, или что-то подобное используется для переименования файлов логов на регулярной основе (имеется ввиду - постоянно - раз в сутки, например - прим. lissyara). Для гарантии, что переключение лог-файлов будет замечено как можно быстрее, exim вызывает “stat()” для имени главных логов, до повторного использования открытых файлов, и если файл не существует, или изменилась его инода, старый файл закрывается, и exim пробует открыть пустой главный лог. Таким образом, старый лог может оставться открытым довольно долго, но никакие процессы exim`a в него не пишут, как только он был переименован.

  48.3 Штамп даты на файлах логов

     Вместо ротации файлов главного лога и лога отклонённых путём их периодического переименовывания, некоторые любят исполльзовать файлы, чьи имена содержат штамп времени, например, “mainlog-20031225”. Штамп времни имеет форму “yyyymmdd”. Exim обладает поддержкой для этого способа работы. Он включается путём установки опции “log_file_path” в путь, который содержит “%D” в точке где требуется штамп даты. Например:


  log_file_path = /var/spool/exim/log/%slog-%D log_file_path = /var/log/exim-%s-%D.log log_file_path = /var/spool/exim/log/%D-%slog

     Как и прежде, “%s” заменяется на “main” или “reject”; вот - примеры имён генерируемых этим примером:


  /var/spool/exim/log/mainlog-20021225 /var/log/exim-reject-20021225.log /var/spool/exim/log/20021225-mainlog

     Когда задана эта форма логов, exim автоматически переключается на новые файлы по ночам. Он не предпринимает никаких попыток для сжатия старых логов; вам придётся написать свой скрипт, который будет это делать. Вы не должны запускать “exicyclog” с этой формой логгинга.
Местоположение лога паники, также определяется путём “log_file_path”, но на него не ставиться штамп даты, поскольку ротация лога паники не имеет смысла. При генерации имени лога паники, “%D” удаляется из строки. Дополнительно, если он идёт немедленно после слэша, следующий не алфавитно-цифровой символ - удаляется; иначе, удаляется предшествующий не алфавитно-цифровой символ. Таким образом, предыдущие три примера, привели бы к таким логам паники:


  /var/spool/exim/log/paniclog /var/log/exim-panic.log /var/spool/exim/log/paniclog

  48.4 Логгинг в syslog

     Использование syslog не изменяет того, как exim логгирует, или формат его сообщений, исключая одно отношение. Если “syslog_timestamp” установлена в ложь, штамп времени в строках лога exim`a пропускается, когда строка посылается в syslog. Кроме того? те же самые строки пишутся в syslog как в файлы логов. Средство (“facility”) syslog установлено в LOG_MAIL, и по умолчанию, программа именуется “exim”, но вы можете изменить это путём опций “syslog_facility” и “syslog_processname”, соответственно. Если exim скомпилен с SYSLOG_LOG_PID установленным в “Local/Makefile” (это, значение по умолчанию, в “src/EDITME”), тогда, на системах, которые разрешают это (все, исключая ULTRIX), флаг LOG_PID - установлен так, чтобы вызов “syslog()” добавлял pid, также как и время и имя хоста, в каждую строку. Три потока логов распределяются по приоритетам syslog следующим образом:


• “mainlog” - маппится на LOG_INFO

• “rejectlog” - маппится на LOG_NOTICE

• “paniclog” - маппится на LOG_ALERT
Многие строки пишутся в оба - “mainlog” и “rejectlog”, а некоторые пишутся и в “mainlog” и в “paniclog”, таким образом, они будут дублироваться, если syslod их направит в одно место. Вы можете подавить дубликацию путём установки “syslog_duplication” в ложь.
Иногда, строки логов exim`a бывают очень длинными, и некоторые записи “rejectlog”содержат несколько строк, когда включаются заголовки. Для борьбы с этими обоими случаями, записываемые в syslog вхождения разделяются в отдельные вызовы “syslog()”по внутренним новым строкам, и, также, после максимум, 870 знаков. (Это учитывает максимальную длинну строки syslog - 1024, когда добавлены дополнения, типа штампа времени.) Если вы запускаете замену syslog, которая может обработать строки длинней чем 1024 символа, разрешённые RFC3164, вы должны установить


  SYSLOG_LONG_LINES=yes

  в “Local/Makefile” до сборки exim`a. Это предотвращает разбитие exim`ом длинных строк, но всё ещё разбирает внутренние новые строки во вхождениях лога “reject”.
Для облегчения повторной сборки разбитых строк, каждый компонент разбитого вхождения начинается со строки формы “[<n>/<m>]” или “[<n>\<m>]”, где “<n>” - компонент числа, и “<m>” - полное число компонентов вхождения. Разделитель “/”используется когда строка разбита из-за того, что она слишком длинная; если же она разбита из-за внутренней новой строки, используется разделитель “\”. Например, предположим что ограничение длинны 50 вместо 870, следующий пример был бы результатом типичного отклонения сообщения в “mainlog” (LOG_INFO), дополненительно, каждая строка предваряется временем, именем хоста, и pid, добавляемых syslog:


  [1/5] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected from [2/5] [127.0.0.1] (ph10): syntax error in 'From' header [3/5] when scanning for sender: missing or malformed lo [4/5] cal part in "<>" (envelope sender is <ph10@cam.exa [5/5] mple>)

     Та же самая ошибка могла бы привести к следующим строкам записанным в “rejectlog”(LOG_NOTICE):


  [1/18] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected fro [2/18] m [127.0.0.1] (ph10): syntax error in 'From' head [3/18] er when scanning for sender: missing or malformed [4/18] local part in "<>" (envelope sender is <ph10@cam [5\18] .example>) [6\18] Recipients: ph10@some.domain.cam.example [7\18] P Received: from [127.0.0.1] (ident=ph10) [8\18] by xxxxx.cam.example with smtp (Exim 4.00) [9\18] id 16RdAL-0006pc-00 [10/18] for ph10@cam.example; Mon, 16 Sep 2002 16: [11\18] 09:43 +0100 [12\18] F From: <> [13\18] Subject: this is a test header [18\18] X-something: this is another header [15/18] I Message-Id: <E16RdAL-0006pc-00@xxxxx.cam.examp [16\18] le> [17\18] B Bcc: [18/18] Date: Mon, 16 Sep 2002 16:09:43 +0100

     Строки логов, которые не слишком длинные, или не содержат символа новой строки, пишутся в syslog без модификации.
Если используется только syslog, монитор exim`a не может показывать логи, если syslog не направляет “mainlog” в файл на локальном хосте, и переемнная окружения EXIMON_LOG_FILE_PATH не указывает монитору, где он находится.

  48.5 Флаги строк логов

     На каждое пришедшее сообщение, в логи записывается одна строка, и для каждой успешной, неуспешной, и задержанной доставки. Эти строки могут быть выбраны по отличительным двухсимвольным флагам, которые идут сразу за штампом времени. Флаги таковы:


  Флаг Значение <= прибытие сообщения => нормальная доставка сообщения -> дополнительный адрес в той же доставке *> доставка подавлена путём -N ** доставка неудачна; отправляется рикошет == доставка задержана; временная проблема

  48.6 Логирование приёма сообщений

     Формат однострочного вхождения в главном логе, который пишется для каждого полученного сообщения, показан в простом примере, ниже, который разбит на несколько строк, чтобы уместиться на странице:


  2002-10-31 08:57:53 16ZCW1-0005MB-00 <= kryten@dwarf.fict.example H=mailer.fict.example [192.168.123.123] U=exim P=smtp S=5678 id=<incoming message id>

     Адрес, немедленно сопровождаемый “<=” - адрес отправителя конверта. Рикошет отображается с адресом отправителя “<>”, и, если он сгенерирован локально, он сопровождается элементом в форме:


  R=<message id>

  являющимся ссфлкой на сообщение, которое вызвало отсылку рикошета.
Для сообщений с других хостов, поля “H” и “U” идентифицируют удалённый хост и запись идентификатора RFC1413 пользователя, пославшего сообщение, если оно было принято. Число данное в кадратных скобках - IP адрес, отсылавшего хоста. Если тут единственное, не заключённое в скобки, имя хоста в поле “H”, как выше, значит оно было проверено на соответствие IP адресу (смотрите опцию “host_lookup”). Если имя в круглых скобках, то это имя, указанное удалённым хостом в SMTP команде HELO или EHLO, и оно не было проверено. Если проверка приводит к имени отличающемуся от данного в HELO или EHLO, проверенное имя показано первым, сопровождаемое именем HELO или EHLO в круглых скобках.
Неверно сконфигурированные хосты (и те, кто подделывает почту) иногда помещают IP адрес, с квадратными скобками, или без, в команду HELO или EHLO, приводя к записям в логах, типа этих примеров:


  H=(10.21.32.43) [192.168.8.34] H=([10.21.32.43]) [192.168.8.34]

     Это может запутывать. Можно положиться лишь на последний адрес в квадратных скобках.
Для локально сгенерённых сообщений (т.е. не переданных через TCP/IP), поле “H” - пропущено, и поле “U” содержит логин вызвавшего exim.
Для всех сообщений, поле “P” определяет протокол, используемый для получения сообщения. Это значение сохраняется в “$received_protocol”. В случае входящего SMTP сообщения, значение указывает, использовались ли расширения SMTP (ESMTP), шифрование, или аутентификация. Если сессия SMTP была шифрованная, есть дополнительное поле “X”, в котором записан тип использовавшегося шифрования.
Протокол устанавливается в “esmptsa” или “esmtpa” для сообщений переданных от хостов которые аутентифицировались, используя команду SMTP AUTH. Первое значение используется когда SMTP соединение шифрованное (“secure”). В этом случае, есть дополнительный пункт “A=”, сопровождаемый именем использовавшегося аутентификатора. Если аутентифицированная идентификация была установлена аутентифкационной опцией “server_set_id”, она также логируется, отделяемая двоеточием от имени аутентификатора.
Поле “id” записывает существующий идентификатор сообщения, если он есть. Размер принятого сообщения даётся в поле “S”. Когда сообщение доставляется, заголовки могут быть удалены или добавлены, таким образом, размер доставленных копий сообщений может не соответствовать этому значению (и в действительности могут отличаться друг от друга).
Опция “log_selector” может использоваться для запроса логгинга дополнительных данных, при получении сообщения. Смотрите раздел 48.15.

  48.7 Логгинг доставок

     Формат однострочного вхождения в главном логе, который пишется для каждой доставки показан в одном из примеров ниже, для локальной и удалённой доставки соответсвенно. Каждый пример был разбит на две строки, чтобы вписаться в страницу:


  2002-10-31 08:59:13 16ZCW1-0005MB-00 => marv <marv@hitch.fict.example> R=localuser T=local_delivery 2002-10-31 09:00:10 16ZCW1-0005MB-00 => monk@holistic.fict.example R=dnslookup T=remote_smtp H=holistic.fict.example [192.168.234.234]

     Для обычных локальных доставок, оригинальный адрес даётся в угловых скобках после финального адреса доставки, который может быть трубой или файлом. Если между оргтнальным и финальным адресом существует промежуточный, последний даётся в круглых скобках после заключительного адреса. Поля “R” и “T” записывают роутер и транспорт которые использовались при обработке адреса.
Если после успешной локальной доставки запускается теневой транспорт, к концу строки о успешной доставке добавляется элемент, в форме:


  ST=<shadow transport name>

     Если теневой транспорт был неуспешен, сообщение о ошибке помещается в конце, в круглых скобках.
Когда в одной доставке включён более чем один адрес (например, две команды SMTP RCPT в одной транзакции), второй и последующие адреса помечаются флагами с “->”вместо “=>”. Когда два и более сообщения отправляются по одному SMTP соединению, для второго и последующих сообщений в строках логов за IP адресом вставляется звёздочка.
Генерация сообщения с ответом, путём файла фильтра, логгируется как “доставка” на адрес, которому предшествует “>”.
Опция “log_selector” может использоваться для запроса логгинга дополнительных данных, при получении сообщения. Смотрите раздел 48.15.

  48.8 Доставки от которых отказались

     Когда от сообщения отказались, как разультат команды “seen finish” появившейся в файле фильтра, который не генерит никаких доставок, в логи записывается вхождение такой формы:


  2002-12-10 00:50:49 16auJc-0001UB-00 => discarded <low.club@bridge.example> R=userforward

  для указаний, почему не залоггированы никакие доставки. Когда от сообщения отказываются по причине что альяс привёл к “:blackhole:” (чёрная дыра - /dev/null - прим. lissyara), строка логов будет такой:


  1999-03-02 09:44:33 10HmaX-0005vi-00 => :blackhole: <hole@nowhere.example> R=blackhole_router

  48.9 Отсроченные доставки

     Когда сообщение задержано, логгируется строка следующей формы:


  2002-12-19 16:20:23 16aiQz-0002Q5-00 == marvin@endrest.example R=dnslookup T=smtp defer (146): Connection refused

     В случае удалённых доставок, ошибка - то, что давалось для последнего пробовавшегося IP адреса. Детали индивидуальной SMTP ошибки также пишутся в лог, таким образом, вышеупомянутой строке предшествовало  бы что-то вроде этого:


  2002-12-19 16:20:23 16aiQz-0002Q5-00 Failed to connect to mail1.endrest.example [192.168.239.239]: Connection refused

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

  48.10 Ошибки доставки

     Если доставка неуспешна по причине невозможности сроутить адрес, логгируется строка такой формы:


  1995-12-19 16:20:23 0tRiQz-0002Q5-00 ** jim@trek99.example <jim@trek99.example>: unknown mail domain

     Если доставка неудачна в транспортное время, показываются роутер и транспорт, и включается ответ удалённого хоста, как в этом примере:


  2002-07-11 07:14:17 17SXDU-000189-00 ** ace400@pb.example R=dnslookup T=remote_smtp: SMTP error from remote mailer after pipelined RCPT TO:<ace400@pb.example>: host pbmail3.py.example [192.168.63.111]: 553 5.3.0 <ace400@pb.example>...Addressee unknown

     Слово “pipelined” указывает, что было использовано расширение SMTP PIPELINING. Смотрите “hosts_avoid_esmtp” в транспорте “smtp” для способа отключения PIPELINING. Строки логов для всех форм неудачной доставки помечаются флагом “**”.

  48.11 Поддельные доставки

     Если доставка, фактически, не имела места, поскольку для её подавления использовалась опция “-N”, в лог пишется обычная строка доставки, исключая, что “=>”заменяется на “*>”.

  48.12 Завершение

     Строка в форме


  2002-10-31 09:00:11 16ZCW1-0005MB-00 Completed

  пишется в главный лог когда сообщение должно быть удалено из спула, в конце его обработки.

  48.13 Краткое изложение полей в строках логов

     Краткое изложение идентификаторов полей, которые используются в строках логов, показано в следующей таблице:


  Идентификатор Значение A имя аутентификатора (и опциональный id) С подтверждение SMTP после доставки CV статус проверки сертификата DN характерное имя от сертификата узла DT в строке => — время затраченное на доставку F адрес отправителя (в строках доставки) H имя хоста и IP адрес I используемый локальный интерфейс id идентификатор сообщения для входящего сообщения P в строке <= — используемый протокол P в => и ** строках — обратный путь QT в строках => — время нахождения в очереди на данный момент QT в строках “Completed” - время нахождения в очереди R в строках <= — ссылка для локального рикошета R в ** и == строках — имя роутера S размер сообщения ST имя теневого транспорта T в строках <= — тема сообщения T в ** и == строках — имя транспорта U локальный пользователь или идентификатор RFC1413 X способ шифрования TLS

  48.14 Другие записи логов

     Различные иные типы записей время от времени пишутся в логи. Большинство из них - очевидны. Чаще всего:


• “retry time not reached” - предварительно, адрес подвергся временной ошибке при роутинге, или локальной доставке, и время его повтора ещё не наступило. Это сообщение не пишется в индивидуальный файл лога, если это не происходит во время первой попытки доставки.

• “retry time not reached for any host” - предварительно, адрес подвергся временной ошибке в процессе удалённой доставки, и ни для одного из хостов, к которым был сроучен адрес, не наступило время повтора.

• “spool file locked” - Попытка доставки сообщения не может произойти, поскольку некоторые иной процесс exim`a уже работают над ним. Это довольно обычно, если процесс обработки очереди запускается через короткие интервалы. Сервисный скрипт “exiwhat” может быть использован чтобы узнать, чем занимаются процессы exim`a.

• “error ignored” - есть несколько обстоятельств, которые могут привести к этому сообщению:
1. Exim не может доставить рикошет, чей возрас больше чем “ignore_bounce_errors_after”. От рикошета отказываются.
2. Файл фильтра установил доставку используя опцию “noerror”, и доставка неудачна. От доставки отказываются.
3. Доставка настроенная путём роутера сконфигурированного с


  errors_to = <>

  неудачна. От доставки отказываются.

  48.15 Сокращение или увеличение того, что логгируется

     Путём установки глобальной опции “log_selector”, вы можете отключить некоторое дефолтовое логгирование exim`a, или вы можете запросить дополнительный логгинг. Значение “log_selector” составлено из имён, с предшествующем символом плюса или минуса. Например:


  log_selector = +arguments -retry_defer

     Список опциональных элементов лога, указаны в следующей таблице, с дефолтовым значением отмеченным звёздочкой:


  элемент значение *acl_warn_skipped пропущенное в ACL утверждение “warn” address_rewrite перезапись адреса all_parents все родители в => строке arguments аргументы командной строки *connection_reject отклонения соединений *delay_delivery задержка немедленной доставки deliver_time время затраченнное на выполнение доставки delivery_size добавляет S=nnn в строки => *dnslist_defer задержки поисков в списках DNS (RBL) *etrn команды ETRN *host_lookup_failed в названии опции всё сказано ident_timeout таймаут соединения ident incoming_interface входящий интерфейс в строке <= incoming_port входящий порт в строке <= *lost_incoming_connection что сказано в названии опции (включая таймауты) outgoing_port добавляет удалённый порт к строке => *queue_run начало и завершение обработки очереди queue_time время в очереди для одного получателя queue_time_overall время в очереди для всего сообщения received_recipients получатели в cтроках <= received_recipients отправители в строках <= *rejected_header содержимое заголовка в логе отклонённых *retry_defer “retry time not reached” return_path_on_delivery помещает путь возврата в строки => и *\ sender_on_delivery добавляет отправителя к строкам => *sender_verify_fail ошибка проверки отправителя *size_reject отклонение по причине слишком большого размера *skip_delivery пропуск доставки в обработчике очереди smtp_confirmation подтверждение SMTP в строках => smtp_connection подключения SMTP smtp_incomplete_transaction незавершенная транзакция SMTP smtp_protocol_error ошибки протокола SMTP smtp_syntax_error ошибки синтаксиса SMTP subject содержимое Subject: в строках <= tls_certificate_verified статус проверки сертификата *tls_cipher метод шифрования TLS в строках <= и => tls_peerdn TLS узел DN в строках <= и => unknown_in_list неудача поиска DNS при сравнении списка — — all все вышеупомянутые

     Дополнительные детали для каждого из этих элементов таковы:


• “acl_warn_skipped”: Когда пропускается “warn” утверждение ACL, поскольку одно из его условий не может быть оценено, о этом эффекте записывается строка лога, если этот селектор установлен.

• “address_rewrite”: Это применяется к обоим перезаписям, - глобальной и транспортной, но не к перезаписи в фильтрах, работающих от непривелигированного пользователя (поскольку такой пользователь не имеет доступа к логам).

• “all_parents”: Обычно, лишь оригинальный и финальный адреса логгируются в строках доставки; с этим селектором, промежуточные предки даются между ними, в круглых скобках.

• “arguments”: Это вызывает запись exim`ом аргументов, с которыми он был вызван, в главный лог, предшествуемые текущей рабочей директорией. Это - отладочная возможность, добавленная для облегчения узнавания того, как некоторые MUA вызывают вызывают “/usr/sbin/sendmail”. Логгинг не происходит, если exim отказался от root`овых привилегий, поскольку он вызывается с опциями “-C” или “-D”. Аргументы которые пусты, или которые содержат пустое пространство - помещаются в кавычки. Непечатаемые символы показываются в последовательностях начинающихся с обратной косой черты. Это средство не может логгировать нераспознанные аргументы, поскольку аргументы проверяются до чтения конфигурационного файла. Единственный способ логгировать такие случаи - вставка скрипта, типа “util/logargs.sh”, между вызывающим и exim`ом.

• “connection_reject”: Запись в лог производится каждый раз когда отклоняется входящее SMTP подключение, по любой причине.

• “delay_delivery”: Запись в лог производится каждый раз когда процесс доставки не запускается для входящего сообщения, поскольку загрузка слишком высока, или слишком много сообщений передано в одном соединении. Логгирования не происходит, если процесс доставки не начат по причине что установлена опция “queue_only” или используется “-odq”.

• “deliver_time”: Для каждой доставки, количество реального времени затраченного на реальную доставку логгируется как DT=<time>, например, DT=1s.

• “delivery_size”: Для каждой доставки, размер сообщения добавляется к строке “=>”, с тегом “S=”.

• “dnslist_defer”: Запись в логи делается если попытка поиска хоста в чёрных списках DNS возвращает временную ошибку.

• “etrn”: Каждая полученная легальная команда ETRN логгируется, до запуска ACL, фактически определяющей, принята она или нет. Неверная команда ERTN, или переданная во время обработки сообщения - не логгируется этим селектором (смотрите “smtp_syntax_error” и “smtp_protocol_error”).

• “host_lookup_failed”: Когда поиск IP-адресов хоста не в состоянии найти какой-либо адрес, или когда поиск по IP адресу не возвращает имени, в логи записывается строка. Этот логгинг не применяется к прямым поискам DNS при роутинге почтовых адресов, но он применяется к поискам “по имени”.

• “ident_timeout”: Строка в лог записывается каждый раз когда попытка подключиться к клиентскому порту ident привела к таймауту.

• “incoming_interface”: Интерфейс на котором получено сообщение добавляется к строке “<=” как IP-адрес в квадратных скобках, помеченный путём “I=” и сопровождаемый двоеточием и номером порта. Локальный интерфейс и порт также добавляется к прочим стркам логов SMTP, например, “SMTP connection from”, и строкам о отклонениях.

• “incoming_port”: Удалённый номер порта, с которого было получено сообщение, добавляется к записям логов и строкам заголовков “Received:”, сопровождаемый IP-адресом в квадратных скобках, и отделённый от него двоеточием. Это осуществляется путём изменения значения помещённого в переменные “$sender_fullhost” и “$sender_rcvhost”. Запись удалённого номера порта стала более важной в связи с использованием NAT (смотрите RFC2505).

• “lost_incoming_connection”: Строка лога записывается когда входящее SMTP соединение неожиданно обрывается.

• “outgoing_port”: Номер удалённого порта, добавляемый к строкам доставки (которые содержат тэг “=>”), сопровождаемый IP-адресом. Эта опция не включена в дефолтовые настройки, поскольку в большинстве обычных конфигураций удалённый порт всегда 25 (порт SMTP).

• “queue_run”: Логгирование запуска и завершения обработки очереди.

• “queue_time”: Количество времени, которое сообщение находилось в очереди на локальном хосте логгируется как “QT=<time>” в строках доставки (=>), например, QT=3m45s. Часы запускаются когда exim начинает приём сообщения, таким образом оно включает время приёма как и время доставки для текущего адреса. Это означает, что оно может быть больше чем разница между временем прибытия и временем доставки в логе, поскольку строка лога о прибытии не пишется, пока сообщение не будет успешно получено.

• “queue_time_overall”: Количество времени которое сообщение было в очереди на локальном хосте логгируется как “QT=<time>” в строках “Completed”, например, QT=3m45s. Часы запускаются когда exim начинает приём сообщения, таким образом оно включает время приёма как и полное время доставки.

• “received_recipients”: Получатели сообщения перечислены в главном логе, как только получено сообщение. Список появляется в конце строки лога, которая записывается когда сообщение приянто, предшествуемый словом “for”. Адреса пеерчислены после того как они были квалифицированы, но до того как имела место перезапись адресов. Получатели от которых отказались из-за ACL для MAIL или RCPT не фигурируют в этом списке.

• “received_sender”: Не перезаписанный оригинальный отправитель сообщения добавляется в конце строки лога, которая записывается по прибытии сообщения, после слова “from” (до получателей, если, также, установлена “received_recipients”).

• “rejected_header”: Если во время записи о отклонении, в лог отклонённых, был получен заголовок сообщения, полный заголовок добавляется в лог. Логгинг заголовков может быть индивидуально отключен для сообщений которые были отклонены функцией “local_scan()” (смотрите раздел 41.2).

• “retry_defer”: Строка лога записывается, если доставка задержана по причине что не достигнуто время повтора. Однако, сообщение “retry time not reached” всегда пропускается от индивидуальных логов сообщений, после первой попытки доставки.

• “return_path_on_delivery”: Путь возврата, который передаётся с сообщением, включается в строки доставки и рикошета, используя тэг “P=”. Он пропускается, если не было фактической доставки, например, при неудаче роутинга, или при доставке в “/dev/null”, или в “:blackhole:”.

• “sender_on_delivery”: Адрес отправителя сообщения, добавляемый к каждой строке доствки и рикошета, помеченный “F=” (для “from”). Это - оригинальный отправитель, который передан с сообщением; он - не обязательно то же самое, что и исходящий путь возврата.

• “sender_verify_failure”: Если этот селектор не установлен, не пишется отдельная строка о ошибке проверки отправителя. Строка лога для отклонения SMTP команд содержит лишь “sender verify failed”, таким образом, некоторые детали теряются.

• “size_reject”: Каждый раз, когда сообщение отклоняется потому, что слишком велико, пишется строка лога.

• “skip_delivery”: Строка лога пишется каждый раз, когда сообщение пропущено в течение работы очереди, поскольку оно заморожено, или поскольку его уже доставляет иной процесс. Сообщение которое пишется - “spool file is locked”.

• “smtp_confirmation”: Ответ на финальную “.” в диалоге SMTP для исходящего сообщения добавляется в строку лога доставки, в форме “C=<text>”. Большинство MTA (включая exim), в этом ответе, возвращают идентификационную строку.

• “smtp_connection”: Строка лога пишется каждый раз, когда SMTP соединение установлено или закрыто, исключая соединения от хостов которые совпадают с “hosts_connection_nolog”. (В противоположность, “lost_incoming_connection” - применется лишь когда закрытие неожиданное.) Она применяется к соединениям от локальных процессов, которые используют “-bs”, точно так же как и к подключениям по TCP/IP. Если соединение разорвано в середине сообщения, строка лога пишется всегда, вне зависимости от установки этого селектора, если же он не установлен, то в начале и в конце соединнеия ничё не пишется.
Для TCP/IP соединений к даемону exim`a, число текущих соединений включается в сообщение лога для каждого нового соединения, но записывается, что счётчик сброшен, если даемон перезапущен. Также, поскольку соединения закрываются (и закрытие логгируется) в подпроцессах, счётчик может не включать соединения, которые были закрыты, но чьё завершение ещё не заметил даемон. Таким образом, когда возможно совпадение открытия и закрытия соединений в логе, значение логгируемого счётчика может быть не совсем точным.

• “smtp_incomplete_transaction”: Когда почтовая транзакция прервана по причине RSET, QUIT, потери соединения, или как-то иначе, инцидент логгируется, и отправитель сообщения плюс любые принятые получатели включаются в строку лога. Это может предостваить очевидные доказательства атак по словарю.

• “smtp_protocol_error”: Строка лога пишется для каждой встреченной ошибки протокола SMTP. Exim не обладает прекрасным обранужением всех ошибок протокола, из-за задержек передачи и конвейерных обработок. Если клиент оповещался о PIPELINING, сервер exim предполагает что клиент будет его использовать, и поэтому не подсчитывает “ожидаемые” ошибки (например, RCPT переданную после отклонённого MAIL) как ошибки протокола.

• “smtp_syntax_error”:  Строка лога пишется для каждой встреченной ошибки синтаксиса SMTP. Нераспознанная команда рассматривается как ошибка синтаксиса. Для внешних соединений, даётся идентификатор хоста; для внутренних соединений использующих “-bs”, даётся идентификатор отправителя (обычно - вызывающий пользователь).

• “subject”: Тема сообщения  добавляется в строку лога прибытия, с предшествующим “T=” (“T” - “topic”, т.к. “S” уже используется для “size”). Любые “слова” MIME в теме - декодируются. Опция “print_topbitchars” задаёт, должны ли символы с кодом более 127 регистрироваться неизменными, или они должны быть превращены в последовательности с обратным слэшом.

• “tls_certificate_verified”: Дополнительный пункт добавляется к строке “<=” и “=>”, когда используется TLS. Элемент “CV=yes” - если сертификат узла был проверен, и “CV=no” - если нет.

• “tls_cipher”: Когда сообщение посылается или принимается через шифрованное соединение, используемый метод шифрования добавляется к строке лога, с предшествующим “X=”.

• “tls_peerdn”: Когда сообщение посылается или принимается через шифрованное соединение, и сетификат предоставляется удалёным хостом, DN узла добавляется к строке лога, с предшествующим “DN=”.

• “unknown_in_list”: "nf установка вызывает запись в лог когда результат сравнения списка неудачен по причине неудачи поиска в DNS.

  48.16 Лог сообщения

     В дополнение к главному файлу логов, exim пишет лог-файл для каждого сообщения, которое он обрабатывает. Имена этих персональных логов для сообщений - идентификаторы сообщений, и они хранятся в субдиректории “msglog” директории спула. Каждый лог сообщения содержит копии строк логов, которые касаются сообщения. Это облегчает выяснение статуса индивидуального сообщения без необходимости поиска по главному логу. Лог сообщения удаляется после завершения обработки сообщения, если не задана “preserve_message_logs”, но она должна использоваться с большой осторожностью, поскольку логи могут очень быстро заполнить ваш диск.
На сильно загруженных системах, может быть желательным отключить использование персональных логов сообщений, для уменьшения дискового ввода-вывода. Это может быть сделано путём установки опции “message_logs” в ложь.