Exim 26 Транспорт appendfile
Содержание
- 1 Транспорт appendfile
- 1.1 Опции “file” и “directory”
- 1.2 Частные опции для “appendfile”
- 1.3 Операционные детали для добавления
- 1.4 Операционные детали для доставки в новый файл
- 1.5 Доставка “maildir”
- 1.6 Использование тэгов для записи размера сообщений
- 1.7 Использование файла “maildirsize”
- 1.8 Доставка “mailstore”
- 1.9 Неспециальная доставка в новый файл
Транспорт appendfile
Транспорт “appendfile” доставляет сообщения путём добавления его к существующему файлу, или путём создания нового файла в заданной директории. Отдельные файлы, к которым добавляются сообщения, могут быть в традиционном формате UNIX mailbox, или, опционально, в формате MBX, поддерживаемом Pine MUA и даемоном University of Washington IMAP (его подерживают и другие). Когда каждое сообщение доставляется в отдельный файл, может использоваться, опционально, формат “maildir”, для дополнительной защиты от ошибок при доставке. Также поддерживается третья форма доставки в отдельные файлы, известная как “mailstore”. Для всех этих форматов, exim, в случае необходимости, пытается создать необходимое число уровней директорий, при условии что установлена опция “create_directory”.
Код для опциональных форматов, по умолчанию не включен в бинарный файл exim`a. Для включения соответствующего кода, необходимо в “Local/Makefile” установить SUPPORT_MBX, SUPPORT_MAILDIR и/или SUPPORT_MAILSTORE.
Exim распознаёт ошибки системной квоты, и генерируется соответствующее сообщение. Также он поддерживает собственное управление квотами в транспорте, для использования когда системные средства недоступны, или по каким-то причинам не могут использоваться.
Если ошибка происходит при добавлении к файлу (например, превышена квота, или заполнился раздел), exim пытается сбросить длину и время последней модификации назад, к тем что были прежде. Если ошибка происходит при создании нового файла - файл удаляется.
До добавления к файлу, выполняется множество проверок безопасности, и файл блокируется. Детальное описание дано ниже, после списка частных опций.
Обычно, транспорт “appendfile” используется для локальной доставки в пользовательские ящики. Однако, он также может использоваться как псевдо-удалённый транспорт, для раскладывания сообщений в файлы, для удалённой доставки другими средствами, кроме exim`a. В этом случае, часто используется формат “пакетного SMTP” (смотрите опцию “use_bsmtp”).
Опции “file” и “directory”
Опция “file” определяет единичный файл, к которому добавляются сообщения; опция “directory” определяет директорию, в которой создаётся новый файл, содержащий сообщение. Может быть задана лишь одна из этих двух опций, и для нормальной доставки в почтовые ящики, одна из них должна быть установлена.
Однако, “appendfile” также используется для доставки сообщений в файлы или директории, имена которых (или части имён) получаются из яльясов, форвардинга, или операций фильтрации (например, команды “save” в пользовательском фильтре exim`a). Когда выполняется такой транспорт, “$local_part” содержит локальную часть, которая альясится или форвардится, и “$address_file” содержит имя (или часть имени) файла или директории, сгенерённое операцией перенаправления. Есть два случая:
- Если не установлены ни “file” ни “directory”, операция перенаправления должна определить абсолютный путь (тот, который начинается с “/”). Это - большинство общих случаев, когда пользователи с локальными аккаунтами используют фильтрацию для сортировки почты по различным директориям. Смотрите, для примера, транспорт “address_file”, в дефолтовой конфигурации. Если путь завершается слэшем, предполагается, что это - имя директории. Доставка в директорию может быть вызвана путём установки “maildir_format” или “mailstore_format”.
- Если “file” или “directory” установлены для доставки от переназначения (редиректа [redirection] - прим. lissyara), она используется для определения имени файла или директории для доставки. Обычно, содержимое “$address_file” используется каким-то образом в раскрытии строки.
Как пример второго случая, рассмотрите окружение где пользователи не имеют домашних директорий. Им можно разрешить использование команды фильтра exim`a в форме:
save folder23
или команды фильтра Sieve в форме:
require "fileinto"; fileinto "folder23";
В этой ситуации, раскрытие “file” или “directory” в транспорте должно преобразовать относительный путь в соответствующее абсолютное имя файла. В случае фильтров Sieve, должно быть обработано имя “inbox”. Это имя, используемое в качестве результата действия “keep” (“сохранить”), в фильтре. Этот пример показывает один способ обработать это требование:
file = ${if eq{$address_file}{inbox} \ {/var/mail/$local_part} \ {${if eq{${substr_0_1:$address_file}}{/} \ {$address_file} \ {$home/mail/$address_file} \ }} \ }
С этой установкой опции “file”, “inbox” ссылается на стандартное расположение почтового ящика, абсолютные пути используются без изменения, и другие папки находятся в директории “mail”, внутри домашней директории.
Замечание 1: При обработке в фильтре exim`a, относительный путь, типа “folder23” превращается в абсолютный, если роутеру известна домашняя директория. В частности, так обстоят дела, если установлена опция “check_local_user”. Если вы хотите предотвратить это во время маршрутизации, вы должны установить “router_home_directory” в пустое значение. Это вынуждает маршрутизатор передавать транспорту относительный путь.
Замечание 2: Абсолютный путь в “$address_file” не обрабатывается как-то особенно; продолжает использоваться опция “file” или “directory”, если она установлена.
Частные опции для “appendfile”
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
allow_fifo | appendfile | boolean | ложь |
Установка этой опции позволяет доставлять в именованные каналы (трубы, или FIFO) точно также как и в обычные файлы. Если, во время доставки, отсутствует процесс читающий трубу, доставка задерживается.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
allow_symlink | appendfile | boolean | ложь |
По умолчанию, “appendfile” не доставляет, если имя пути к файлу будет символической ссылкой. Установка этой опции смягчает это ограничение, но существуют проблемы безопасности связанные с использованием симлинков. Убедитесь, что вы знаете, что делаете, при установке этой опции. Точные детали того, что затрагивает эта опция, находятся в обсуждении следующим за этим списком опций.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
batch_id | appendfile | string† | незадана |
Смотрите описание пакетной локальной доставки в главе 25. Однако, пакетная доставка автоматически отключается для доставок “appendfile”, происходящих как результат форвардинга, альясинга, или других переназначений прямо в файл.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
batch_max | appendfile | integer | 1 |
Смотрите описание пакетной локальной доставки в главе 25.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
check_group | appendfile | boolean | ложь |
Когда эта опция установлена, проверяется группа владельца файла, заданного опцией “file”, для удостоверения, что это та же самая группа, под которой выполняется процесс доставки. Дефолтовая настройка - ложна, поскольку дефолтовый режим - 0600, что означает, что группа не имеет значения.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
check_owner | appendfile | boolean | истина |
Когда эта опция установлена, проверяется владелец файла, заданного опцией “file”, для удостоверения, что он тот же самый, под которым выполняется процесс доставки.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
check_string | appendfile | string | смотрите ниже |
Поскольку “appendfile” записывает сообщение, начало каждой строки проверяется на совпадение с “check_string”, и если оно происходит, совпавшие начальные символы заменяются на содержимое “escape_string”. Значение “check_string” - литеральная строка, а не регулярное выражение, и регистр содержащихся букв имеет значение.
Если установлена “use_bsmtp”, значение “check_string” и “escape_string” принудительно устанавливаются в “.” и “..”, соответственно, и любые конфигурационные настройки игнорируются. Иначе, - у них значения по умолчанию “From ” и “>From ” когда задана опция “file”, и незаданы, когда установлена любая из опций “directory”, “maildir” или “mailstore”.
Дефолтовые настройки, наряду с “message_prefix” и “message_suffix”, являются подходящими для традиционных “BSD”-майлбоксов, где строка, начинающаяся с “From ” индицирует начало нового сообщения. Все четыре опции нуждаются в изменении, если используется иной формат. Например, для доставки в почтовые ящики в формате MMDF:
check_string = "\1\1\1\1\n" escape_string = "\1\1\1\1 \n" message_prefix = "\1\1\1\1\n" message_suffix = "\1\1\1\1\n"
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
create_directory | appendfile | boolean | истина |
Когда эта опция истинна, exim пытается создать любые недостающие вышестоящие директории, для файла в который собирается производить запись. Режим созданного каталога, задаётся опцией “directory_mode”.
Владелец группы созданной директории сильно зависит от используемой операционной системы (и, возможно, файловой системы). Например, в Solaris, если родительский каталог имеет установленный бит “setgid”, его группа передаётся дочернему каталогу; если нет, используется текущая установленная группа. Однако, в FreeBSD, всегда используется родительская группа.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
create_file | appendfile | string | anywhere |
Эта опция ограничивает местоположение файлов и директорий создаваемых этим транспортом. Это применяется к файлам, заданным опцией “file”, и директориям, заданным опцией “directory”. В случае доставки maildir, это применяется к директориям верхнего уровня, а не к нижележащим директориям maildir.
Опция должна быть установлена в одно из слов “anywhere”, “inhome”, или “belowhome”. Во втором и третьем случае, для транспорта должна быть установлена домашняя директория. Эта опция бесполезна, когда задаётся явное имя файла для обычной доставки в почтовые ящики. Она предназначена для случая, когда имя файла генерируется из пользовательских файлов “.forward”. Обычно, они обрабатываются транспортом “appendfile”, вызванным “address_file”. Также, смотрите опцию “file_must_exist”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
directory | appendfile | string† | незадана |
Эта опция взаимоисключающая с опцией “file”, но одна из опций “file” или “directory” должжна быть задана, исключая случай доставки как результата перенаправления (смотрите раздел 26.1).
Когда задана опция “directory”, строка раскрывается, и сообщение доставляется в новый файл или файлы, или в подкаталог данного каталога, вместо добавления к единственному файлу почтового ящика. Поддерживается несколько различных форматов (смотрите “maildir_format” и “mailstore_format”), и смотрите раздел 26.4, для дальнейших деталей о этой форме доставки.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
directory_file | appendfile | string† | q${base62:$tod_epoch}-$inode |
Когда установлена опция “directory”, но не установлены ни “maildir_format” ни “mailstore_format”, “appendfile” доставляет каждое сообщение в файл, имя которого получается в результате раскрытия строки этой опции. Значение по умолчанию генерит уникальное имя из текущего времени, в форме base 62, и иноды файла. Переменная “$inode” доступна лишь при раскрытии этой опции.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
directory_mode | appendfile | octal integer | 0700 |
Если “appendfile” создаёт какие-либо директории как результат опции “create_directory”, их режим задаётся этой опцией.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
escape_string | appendfile | string | смотрите описание |
Смотрите выше, опцию “check_string”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
file | appendfile | string† | незадана |
Эта опция взаимоисключающая с опцией “directory”, но одна из опций “file” или “directory” должжна быть задана, исключая случай доставки как результата перенаправления (смотрите раздел 26.1). Опция “file” определяет единичный файл, к которому добавляется сообщение. Одна и более из опций “use_fcntl_lock”, “use_flock_lock” или “use_lockfile” должны быть заданы с опцией “file”.
Если вы используете более одного хоста для доставки через NFS в одни и те же почтовые ящики, вы всегда должны файлы блокировки.
Значение строки раскрывается для каждой доставки, и должно привести к абсолютному пути. Самые общие установки этой опции - вариации одного из этих примеров:
file = /var/spool/mail/$local_part file = /home/$local_part/inbox file = $home/inbox
В первом примере, все доставки осуществляются в один и тот же каталог. Если exim сконфигурирован использовать файлы блокировки (смотрите ниже, опцию “use_lockfile”), он должен быть в состоянии создать файл в директории, таким образом, “липкий” (“sticky”) бит должен быть включен для возможности доставки, или, альтернативно, может использоваться опция “group” для выполнения доставки под групповым идентификатором, имеющим доступ к директории.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
file_format | appendfile | string | незадана |
Эта опция просит транспорт проверить формат существующего файла, до добавления к нему. Проверка состоит из соответствия специфической строке в начале файла. Значение опции состоит из чётного числа строк, разделённых двоеточиями. Первая из кадой пары - проверочная строка, и вторая - имя транспорта. Если транспорт, ассоциированный с совпавшей строкой, не является текущим транспортом, управление передаётся другому транспорту. Например, предположим что к стандартному транспорту “local_delivery” добавлено это:
file_format = "From : local_delivery :\ \1\1\1\1\n : local_mmdf_delivery"
Почтовые ящики, начинающиеся с “From”, продолжают обрабатываться этим транспортом, но почтовые ящики, начинающиеся с четырёх двоичных единиц, с символом новой строки, управление передаётся транспорту называемому “local_mmdf_delivery”, который, видимо, сконфигурирован для осуществления доставки в формате MMDF. Если почтовый ящик не существует, или пуст, предполагается совпадение с текущим транспортом. Если начало почтового ящика не совпадает ни с одной строкой, или не задан транспорт чьё имя совпало, доставка задерживается.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
file_must_exist | appendfile | boolean | ложь |
Если эта опция истинна, файл заданный опцией “file” должен существовать, и происходит ошибка, если это не так. Если она не задана, в случае его отсутствия, он создаётся.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lock_fcntl_timeout | appendfile | time | 0s |
По умолчанию, транспорт “appendfile” использует неблокирующие вызовы “fcntl()”, при блокировке открытого файла почтового ящика. Если вызов неудачен, процесс доставки засыпает на “lock_interval”, и пробует снова, до времени “lock_retries”. Неблокирующие вызовы используются так, чтобы файл не оставлялся открытым в ожидании блокировки; причина этого заключается в желании сделать это безопасным насколько возможно, для доставок через NFS, в случае, когда процессы могли бы обращаться к почтовому ящику NFS без использования файла блокировки. Этого не должно быть, но недоразумения, и, следовательно, просчёты конфигурации неизвестны.
На загруженных системах, однако, производительность неблокирующей блокировки не столь хороша, как использование блокирующей блокировки с таймаутом. В этом случае, ожидание делается в системном вызове, и процесс доставки exim`a овладевает блокировкой и может обработать, как только предыдущий держатель блокировки снимет её.
Если “lock_fcntl_timeout” установлена в ненулевое время, блокирование блокируется, с использованием этого таймаута. Всё ещё может быть некоторое повторение: максимальное число повторений
(lock_retries * lock_interval) / lock_fcntl_timeout
округляется к следующему целому числу. Другими словами, полное время в течение которого “appendfile” пробует получить блокировку - примерно тоже самое, если “lock_fcntl_timeout” не установлена слишком большой.
Вы должны рассмотреть установку этой опции, если вы получаете много отсроченных локальных доставок из-за ошибок вида
failed to lock mailbox /some/file (fcntl)
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lock_flock_timeout | appendfile | time | 0s |
Этот таймаут применяется к блокировке файла, когда используется “flock()” (смотрите “use_flock”); таймаут работает в манере, похожей на “lock_fcntl_timeout”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lock_interval | appendfile | time | 3s |
Эта опция определяет время ожидания между попытками блокировки файла. Смотрите ниже, для дополнительных деталей о блокировке.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lock_retries | appendfile | integer | 10 |
Эта опция определяет максимальное число попыток блокировки файла. Значение нуля обрабатывается как единица. Смотрите ниже, для дополнительных деталей о блокировке.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lockfile_mode | appendfile | octal integer | 0600 |
Эта опция определяет режим создаваемого файла блокировки, когда используется файл блокировки (смотрите опции “use_lockfile” и “use_mbx_lock”)
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
lockfile_timeout | appendfile | time | 30m |
Когда используется файл блокировки (смотрите опцию “use_lockfile”), если файл блокировки уже существует, и он старше этого значения, предполагается, что он был случайно оставлен, и exim пытается его удалить.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mailbox_filecount | appendfile | string† | незадана |
Если эта опция установлена, она раскрывается, и результат берётся как текущее число файлов в почтовом ящике. Это должно быть десятичное число, опционально сопровождаемое K или M. Этим предоставляется способ получить информацию из внешнего источника, обслуживающего данные.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mailbox_size | appendfile | string† | незадана |
Если эта опция задана, она раскрывается, и результат берётся как текущий размер почтового ящика. то должно быть десятичное число, опционально сопровождаемое K или M. Этим предоставляется способ получить информацию из внешнего источника, обслуживающего данные. Это, вероятно, будет полезным для доставок “maildir”, где, в вычислительном отношении, дорого вычислить размер почтового ящика.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildir_format | appendfile | boolean | ложь |
Если эта опция задана с опцией “directory”, доставка в новый файл, в формате “maildir” используемом другими почтовыми программами. Когда транспорт активизирован непосредственно от роутера “redirect” (например, транспорт “address_file” в дефолтовой конфигурации), установка “maildir_format” вызывает обработку пути переданного из роутера как каталога, вне зависмости, завершается, или нет, он на “/”. Эта опция доступна лишь если в “Local/Makefile” присутствует SUPPORT_MAILDIR. Для получения дополнительных деталей, смотрите раздел 26.5.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildir_quota_directory_regex | appendfile | string | смотрите ниже |
Эта опция уместна лишь если установлена “maildir_use_size_file”. Она определяет регулярное выражение, для определения директорий, относительно директории квоты (смотрите “quota_directory”), которая должна быть включена в подсчёт квоты. Значение по умолчанию:
maildir_quota_directory_regex = ^(?:cur|new|\..*)$
Этим включаются директории “cur” и “new”, и любые директории “maildir++” (директории, чьи имена начинаются с точки). Если вы хотите исключить из подсчёта директорию “Trash” (как делают некоторые сайты), вы должны изменить эту установку на
maildir_quota_directory_regex = ^(?:cur|new|\.(?!Trash).*)$
Это использует отрицательное предвидение в регулярном выражении, для исключения директории с именем “.Trash”. Когда директория исключена из подсчёта квоты, обработка квоты пропускается для любых сообщений доставляемых в этот каталог.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildir_retries | appendfile | integer | 10 |
Эта опция определяет число повторов при записи файла в формате “maildir”. Смотрите ниже, раздел 26.5.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildir_tag | appendfile | string† | незадана |
Эта опция применяется лишь к доставкам в формате “maildir”, и она описана ниже, в разделе 26.5.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildir_use_size_file | appendfile | boolean | ложь |
Установка этой опции в истину включает поддержку файлов “maildirsize”. Exim создаёт файлы “maildirsize” в “maildir”, если они не существуют, беря квоту из опции “quota” транспорта. Если квота не задана - значение равно нулю. Смотрите “maildir_quota_directory_regex”, выше и раздел 26.5 для получения дополнительных деталей.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
maildirfolder_create_regex | appendfile | string | незадана |
Значение этой опции - регулярное выражение. Если оно не задано, опция не имеет никакого эффекта. Иначе, до доставки “maildir”, выражение сравнивается с именем директории “maildir”, т.е. директории содержащей субдиректории “new” и “tmp”, которые будут использоваться для доставки. Если есть соответствие, exim проверяет существование файла с именем “maildirfolder” в директории, и создаёт его, если он не существует. Для получения дополнительных деталей, смотрите раздел 26.5.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mailstore_format | appendfile | boolean | ложь |
Если эта опция установлена вместе с опцией “directory”, доставка осуществляется в два новых файла, в формате “mailstore”. Эта опция доступна лишь в случае, если при сборке exim`a в “Local/Makefile” была опция SUPPORT_MAILSTORE. Для получения дополнительных деталей, смотрите раздел 26.4.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mailstore_prefix | appendfile | string† | незадана |
Эта опция применяется только к доставкам в формате “mailstore”, и она описана ниже, в разделе 26.4.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mailstore_suffix | appendfile | string† | незадана |
Эта опция применяется только к доставкам в формате “mailstore”, и она описана ниже, в разделе 26.4.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mbx_format | appendfile | boolean | ложь |
Эта опция доступна лишь в случае, если при сборке exim`a в “Local/Makefile” была опция SUPPORT_MBX. Если опция “mbx_format” установлена с опцией “file”, сообщение добавляется к почтовому ящику в формате MBX, вместо формата традиционного UNIX. Этот формат поддерживается Pine4, и связан с его POP3 и IMAP даемонами путём используемой всеми ими “c-client” библиотеки.
Отметьте: Опции “message_prefix” и “message_suffix” не меняются автоматически, при использовании “mbx_format”. Обычно, при использовании формата MBX, они должны устанавливаться пустыми? таким образом, эта опция почти всегда появляется в такой комбинации:
mbx_format = true message_prefix = message_suffix =
Если в конфигурации не упомянута ни одна из опций блокировки, предполагается “use_mbx_lock”, и другие опции блокировки, по дефолту, ложны. С “mbx_format” возможно определить другие виды блокировок, но “use_fcntl_lock” и “use_mbx_lock” являются взаимоисключающими. Блокировка MBX взаимодействует с “c-client”, предоставляя общий (может быть - распределённый - прим. lissyara) доступ к почтовому ящику. Она не должна использоваться, если любая иная программа, не использующая эту форму блокировки, собирается обращаться к этому почтовому ящику, или если почтовый ящик находится на файловой системе смонтированной по NFS, поскольку она работает лишь когда к почтовому ящику обращаются с одного хоста.
Если вы устанавливаете “use_fcntl_lock” с почтовыми ящиками в формате MBX, вы не можете использовать стандартную версию “c-client”, поскольку пока есть открытый ящик (это бывает при сессии Pine или IMAP), exim не в состоянии добавить к нему сообщение.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
message_prefix | appendfile | string† | смотрите ниже |
Строка заданная в этом пункте раскрывается и выводится в начале каждого сообщения. По умолчанию, она незадана, если не определена опция “file”, и не установлена “use_bsmtp”, когда она:
message_prefix = "From ${if def:return_path{$return_path}\ {MAILER-DAEMON}} $tod_bsdinbox\n"
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
message_suffix | appendfile | string† | смотрите ниже |
Строка заданная в этом пункте раскрывается и выводится в конце каждого сообщения. По умолчанию, она незадана, если не определена опция “file”, и не установлена “use_bsmtp”, в этих случаях она состоит из единственного символа - символа новой строки. Суффикс может быть подавлен путём установки:
message_suffix =
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mode | appendfile | octal integer | 0600 |
Если создаётся файл вывода - на него устанавливается такой режим. Если он существует и на него установлены более широкие разрешения, они уменьшаются до указанного в этой опции. Если на него установлены более жёсткие ограничения, то происходит ошибка, если не ложна опция “mode_fail_narrower”. Однако, если доставка - результат команды “save” в файле фильтра, задающей особый режим, режим выходного файла всегда принудительно приводится к этому значению, и эта опция игнорируется.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
mode_fail_narrower | appendfile | boolean | истина |
Эта опция применяется в случае, когда существующий файл почтового ящика имеет более строгие ограничения чем заданные опцией “mode”. Если опция “mode_fail_narrower” истинна - доставка задерживается (“mailbox has the wrong mode”); иначе - exim продолжает попытки доставки, используя существующий режим файла.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
notify_comsat | appendfile | boolean | ложь |
Если эта опция истинна, даемон “comsat” уведомляется после каждой успешной доставки в пользовательский почтовый ящик. Это даемон, который уведомляет залогиненых пользователей о пришедшей почте.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota | appendfile | string† | незадана |
Эта опция налагает ограничения на размер файла, к которому exim добавляет сообщение, или на полный размер используемый деревом директорий, когда установлена опция “directory”. В последнем случае, вычисление используемого места дорого стоит, поскольку должны быть индивидуально осмотрены и просуммированы все файлы в директории (и любых субдиректориях). (Смотрите “quota_size_regex” и “maildir_use_size_file” для способов избежать этого в окружении где пользователи не имеют shell-доступа к своим почтовым ящикам.)
Нет блокировки от двух одновременных доставок в многофайловый почтовый ящик, и в этом случае возможно превышение квоты. Для однофайловых почтовых ящиков, разумеется, блокировка - необходимость.
Размер файла берётся как его используемое значение. Из-за эффектов блокировки, оно может быть намного меньше дискового пространства, фактически используемого файлом. Если складываются размеры большого числа файлов, эффект округления может стать весьма заметным, особенно на системах использующих большой размер блока. Однако, кажется лучше придерживаться используемого числа, поскольку оно - очевидное значение, наиболее легко понимаемое пользователями.
Значение опции раскрывается, и должно быть числовым значением (разрешена десятичная точка), опционально сопровождаемая одной из букв K, M, или G - для килобайт, мегабайт, или гигабайт. Если exim работает на системе с поддержкой больших файлов (FreeBSD и Linux имеют такую поддержку), могут быть обработаны ящики более 2G размером.
Отметьте: Значение нуля интерпретируется как “нет квоты”.
Раскрытие происходит когда exim работает как root, до того, как он для доставки меняет uid. Это означает, что для содержания квоты, которая ищется в раскрытии можно использовать файлы, которые недоступны конечному пользователю. При неудаче доставки по причине превышения квоты, ошибка обрабатывается как ошибка системной квоты.
По умолчанию, проверка квоты exim`ом подражает системным квотам, и ограничивает почтовый ящик заданным максимальным размером, хотя значение не является точным до последнего байта, из-за строк разделителей, и дополнительных заголовков, которые могут добавляться при доставке сообщения. Когда почтовый ящик почти полный, большие сообщения могут быть отклонены, а маленькие приняты, поскольку размер текущего сообщения добавляется к квоте, при проверке. Это поведение может быть изменено путём установки “quota_is_inclusive” в ложь. Когда это сделано, проверка на превышение квоты не включает текущее сообщение. Таким образом, доставки продолжаются до превышения квоты; после этого никакие последующие сообщения не доставляются. Также смотрите опцию “quota_warn_threshold”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_directory | appendfile | string† | незадана |
Эта опция задаёт директорию для проверки квоты при доставке в отдельные файлы. ПО умолчанию - это директория для доставки, или, если в “maildir” директории существует файл с именем “maildirfolder”, родительский каталог, по отношению к директории для доставки.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_filecount | appendfile | string† | 0 |
Эта опция применяется когда установлена опция “directory”. Она ограничивает общее число файлов в директории (сравните с лимитом на иноды в системных квотах). Она может использоваться, лишь когда установлена опция “quota”. Значение раскрывается; ошибка доставки вызывает задержку доставки. Значение нуля интерпретируется как “нет квоты”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_is_inclusive | appendfile | boolean | истина |
Смотрите выше, опцию “quota”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_size_regex | appendfile | string | незадана |
Эта опция применяется когда используется один из режимов доставки, записывающий отдельный файл для каждого сообщения. Когда exim хочет найти размер одного из этих файлов, для проверки квоты, он вначале проверяет “quota_size_regex”. Если она установлена в регулярное выражение, которое совпадает с именем файла, и является одной строкой, строка интерпретируется как представление размера файла. Значение “quota_size_regex” не раскрывается.
Эта особенность полезна лишь когда пользователи не имеют shell-доступа к своим почтовым ящикам - иначе они могли бы обойти квоту простым переименованием файлов. Это средство может использоваться для “maildir” доставок, путём установки “maildir_tag” для добавления длинны файла к имени файла. Например:
maildir_tag = ,S=$message_size quota_size_regex = ,S=(\d+)
Альтернативой “$message_size” является “$message_linecount”, которая содержит число линий в сообщений.
Регулярное выражение не должно предполагать что размер сообщения - в конце имени файла (даже при том, что её там помещает “maildir_tag”), поскольку MUA обрабатывающие “maildir” иногда добавляют иную информацию в конец имени сообщения.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_warn_message | appendfile | string† | смотрите ниже |
Смотрите ниже, при использование этой опции. Если эта опция не задана, когда установлена “quota_warn_threshold”, значение по умолчанию будет:
quota_warn_message = "\ To: $local_part@$domain\n\ Subject: Your mailbox\n\n\ This message is automatically created \ by mail delivery software.\n\n\ The size of your mailbox has exceeded \ a warning threshold that is\n\ set by the system administrator.\n"
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
quota_warn_threshold | appendfile | string† | 0 |
Эта опция раскрывается точно таким же образом, как и “quota” (смотрите выше). Если результирующее значение больше нуля, и доставка сообщения приводит к размеру файла или общему размеру дерева директорий более данного порога, посылается предупреждающее сообщение. Если, также, установлена “quota”, порог может быть определён как процент от её значения, путём сопровождения значения символом процента. Например:
quota = 10M quota_warn_threshold = 75%
Если “quota” не задана, установка “quota_warn_threshold” заканчивающаяся символом процента - игнорируется.
Само предупреждающее сообщение определяется путём опции “quota_warn_message”, и оно должно начинаться со строки заголовка “To:”, содержащей получателя (получателей) предупреждающего сообщения. Они не обязательно должны включать отправителей оригинального сообщения. Также, обычно, должна предоставляться строка “Subject:”. Вы можете включить любые другие строки заголовков, которые вам необходимы. Если вы не включите строку “From:”, то значение по умолчанию будет:
From: Mail Delivery System <mailer-daemon@$qualify_domain_sender>
Если вы предоставляете строку “Reply-To:”, она перезадаёт глобальную опцию “errors_reply_to”.
Опция “quota” не нуждается в приведении в порядок, для использования этой опции; они независимы друг от друга, кроме случаев, когда порог определён как процент.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_bsmtp | appendfile | boolean | ложь |
Если эта опция установлена в истину, “appendfile” пишет сообщения в формате “пакетного SMTP”, с отправителем конверта и получателем(получателями) включёнными в SMTP-команды. Если вы хотите включить начальную команду HELO в эти сообщения, вы можете это сделать путём установки опции “message_prefix”. Для получения дополнительных деталей о пакетном SMTP, смотрите раздел 44.10.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_crlf | appendfile | boolean | ложь |
Эта опция заставляет строки заканчиваться двухсимвольной CRLF последовательностью (возврат каретки, перевод строки), вместо одного символа перевода строки. В случае пакетного SMTP, записанная в файл последовательность байт, - точное изображение того, что произвело бы отключение реального SMTP-соединения.
Содержимое опций “message_prefix” и “message_suffix” пишется дословно, таким образом, они должны содержать свои символы возврата каретки, если они необходимы. В случаях, когда эти опции имеют непустые значения по умолчанию, значение завершается единственным переводом строки, таким образом, они должны быть изменены, чтобы заканчиваться на “\r\n”, если установлена опция “use_crlf”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_fcntl_lock | appendfile | boolean | смотрите ниже |
Эта опция контролирует использование функции “fcntl()”, для блокировки файла в целях исключительного использования, при добавлении сообщения. По умолчанию, она установлена, когда не установлена “use_flock_lock”. Иначе, она должна быть выключена, лишь если вы знаете что все ваши MUA используют блокировку путём файла блокировки. Когда не установлены обе опции, “use_fcntl_lock” и “use_flock_lock”, опция “use_lockfile” должна быть задана.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_flock_lock | appendfile | boolean | ложь |
Эта опция предоставлена для поддержки блокировки файлов с использованием “flock()”, в тех немногих ситуациях, когда это необходимо. Самые современные операционные системы поддерживают блокировки “fcntl()” и “lockf()”, и эти две функции взаимодействуют друг с другом. По умолчанию, exim использует блокировку “fcntl()”.
Эта опция требуется лишь если вы используете операционную систему где “lockf()” используется программами обращающимися к почтовым ящикам (обычно - MUA), и где “flock()” некорректно взаимодействует с “fcntl()”. Если вы хотите, то можете одновременно использовать обе блокировки “fcntl()” и “flock()”.
Не все операционные системы предоставляют “flock()”. Некоторые версии Solaris не имеют её (и некоторые, я думаю, предоставляют не совсем правильные версии, собранные на верху “lockf()”). Если операционная система не имеет “flock()”, exim будет собран без способности её использовать, и любые попытки сделать это приведут к конфигурационной ошибке.
Предупреждение: Блокировка “flock()” не работает на NFS файлах (только если “flock()” не отображается (mapped) на “fcntl()” с помощью операционной системы).
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_lockfile | appendfile | boolean | смотрите ниже |
Если эта опция выключена, exim не пытается создать файл блокировки при добавлении к файлу почтового ящика. В этой ситуации, единственная блокировка - “fcntl()”. Вы должны отключать “use_lockfile” лишь в случае, если вы абсолютно уверены, что любые MUA, которые когда-либо будут просматривать почтовые ящики пользователей, используют “fcntl()” вместо блокировочного файла и тогда, когда вы не передаёт через NFS более чем от одного хоста.
Для безопасного добавления к файлам NFS более чем от одного хоста, необходимо снять блокировку до открытия файла, и блокировочный файл достигает этого. Иначе, даже с блокировкой “fcntl()”, есть риск повреждения файла.
Опция “use_lockfile” установлена по умолчанию, если не задана “use_mbx_lock”. Не возможно выключить обе опции - “use_lockfile” и “use_fcntl_lock”, кроме случаев, когда установлена “mbx_format”.
Имя | Использование | Тип | Дефолтовое значение |
---|---|---|---|
use_mbx_lock | appendfile | boolean | смотрите ниже |
Эта опция доступна лишь когда exim скомпилирован с установленной SUPPORT_MBX в “Local/Makefile”. Установка опции определяет, что используются специальные правила блокировки MBX. По умолчанию, она установлена, если установлена “mbx_format”, и ни одной опции блокировки нет в конфигурации. Правила блокировки - такие же, как используются библиотекой “c-client”, лежащей в основе даемонов Pine, IMAP4 и POP, которые идут вместе с ней (ниже, смотрите обсуждение). Правила разрешают общий доступ к почтовому ящику. Однако, этот вид блокировки не работает, когда почтовый ящик примонтирован по NFS.
Вы можете установить “use_mbx_lock” с одной или обеими опциями “use_fcntl_lock” “use_flock_lock” для контроля, какая блокировка используется в осуществлении правил блокировки MBX. Значение по умолчанию использует “fcntl()” если “use_mbx_lock” установлена без “use_fcntl_lock” или “use_flock_lock”.
Операционные детали для добавления
До добавления к файлу, производятся следующие подготовительные операции:
- Если имя файла - “/dev/null”, не предпринимается никакого действия, и выдаётся успешное завершение.
- Если какие-либо директории на пути файла отсутствуют, exim создёт их, если установлена опция “create_directory”. Режим созданных директорий даётся опцией “directory_mode”.
- Если установлена “file_format”, проверяется формат существующего файла. Если она указывает, что должен использоваться иной транспорт, управление передаётся этому транспорту.
- Если установлена “use_lockfile”, создаётся файл блокировки для способа, который будет надёжно работать по NFS, следующим образом:
- 1. Создание “сцепленного файла” чьё имя - имя файла блокировки с текущим именем, первичным именем хоста, и добавленным идентификатором процесса, путём открытия для записи нового файла. Если происходит неудача с ошибкой доступа, доставка задерживается.
- 2. Закрытие “сцепленного файла”, жёсткая ликовка его на имя файла блокировки.
- 3. Если вызов “link()” успешен, создание файла блокировки успешно. Удаление имени сцепленного файла.
- 4. Иначе, используется “stat()” для получения информации о сцепленном файле, и, затем, удаляется ссылка на имя сцепленного файла. Если число ссылок - ровно две, создание блокировочного файла успешно, но иногда (например, падение и рестарт NFS-сервера) вызывает несообщение этого факта вызову “link()”.
- 5. Если создание блокировочного файла неудачно, ждётся “lock_interval” и снова пробуется, вплоть до времени “lock_retries”. Однако, т.к. любая программа пишущая в почтовый ящик должна завершить свою задачу очень быстро,это разумный таймаут старых блокировочных файлов, которые, обычно, результат сбоев пользовательского агента и системы. Если существующий файл блокировки старее чем “lockfile_timeout”, exim пытается удалить его до новой попытки.
- К “lstat()” производится запрос, для обнаружения, существует ли главный файл, и если это так, каковы его характеристики. Если “lstat()” - неудачна для по какой-либо причине, кроме несуществования, доставка задерживается.
- Если файл действительно существует, и является симлинком, доставка задерживается, если незадана опция “allow_symlink”, в случае чего проверяется владелец ссылки, и, затем, вызывается “stat()”, для нахождения реального файла, подвергаемого последующим проверкам. Проверка владельца вышестоящей ссылки предотвращает создание пользователем ссылки на чужой почтовый ящик в “липкой” директории, разрешение симлинков, в этом случае, - не самая хорошая идея. Если существует цепочка симликов, промежуточные не проверяются.
- Если файл реально существует, но он не регулярный файл, или владелец и группа файла (если группа проверяется - смотрите выше, опцию “check_group”) отличаются от пользователя и группы под которыми производится доставка, доставка задерживается.
- Если разрешения файла более широкие, чем указанные, - они уменьшаются. Если они недостаточны - доставка задерживается, если опция “mode_fail_narrower” не установлена в ложь, в случае чего пробуется доставка с существующими разрешениями.
- Сохраняется номер иноды файла, и файл открывается для добавления. Если это неудачно, по причине что файл исчез, “appendfile” ведёт себя так, как будто его не существовало (смотрите ниже). Для любых других ошибок - доставка задерживается.
- Если файл открыт успешно, проверяется, что не изменился его номер иноды, что это - всё ещё регулярный файл, и что не изменились его владелец и права. Если что-то не так - доставка задерживается, и сообщение замораживается.
- Если файл изначально не существовал, доставка задерживается, если установлена опция “file_must_exist”. Иначе, если установлена опция “create_file”, проверяется что файл создан в разрешённом каталоге, и, затем, открывается для записи новый файл, с опциями O_EXCL и O_CREAT, кроме случаев, когда это производится с символической ссылкой (должна быть установлена опция “allow_symlink”). В этом случае, который может произойти если ссылка указывает на несуществующий файл, файл открывается для записи используя O_CREAT, но не O_EXCL, поскольку это мешает связи с ссылкой.
- Если открытие неудачно, поскольку файл существует, происходят проверки данные выше, для существующих файлов. Однако, для избежания петель в ситуациях, когда файл непрерывно создаётся и удаляется, петля существует/несуществует разрывается после 10 повторов, и сообщение замораживается.
- Если открытие неудачно по любой другой причине - доставка задерживается.
- Как только файл открыт, если неложны опции “use_fcntl_lock” и “use_flock_lock”, он блокируется, используя “fcntl()” или “flock()” или обе. Если “use_mbx_lock” - ложна, в каждом случае запрашивается эксклюзивная блокировка. Однако, если “use_mbx_lock” - истинна, exim забирает общую блокировку открытого файла, и эксклюзивно блокирует файл с именем
/tmp/.<device-number>.<inode-number>
используя устройство и номер иноды открытого файла почтового ящика, в соответствии с правилами блокировки MBX. Этот файл создаётся с режимом, определённым путём опции “lockfile_mode”.
Если exim не в состоянии заблокировать файл, есть два возможных действия, в зависимости от значения таймаута блокировки. Оно получается из “lock_fcntl_timeout” и “lock_flock_timeout”, соответственно.
Если значение таймаута - ноль, файл закрывается, exim ждёт “lock_interval”, и, затем, возвращается и повторно открывает файл, как описано выше, и снова пробует его заблокировать. Это случается до времени “lock_retries”, после которого доставка задерживается.
Если значение таймаута более нуля, блокировка вызывает “fcntl()” или “flock()”, которая используются (с данным таймаутом), таким образом, уже будет некоторое значение таймаута, путём ошибок блокировки. Однако, exim не прекращает немедленно. Он повторяет до времени (округлённого)
(lock_retries * lock_interval) / <timeout>
В конце доставки, exim закрывает файл (освобождая блокировки “fcntl()” и/или “flock()”), и после этого удаляет, если он существует, файл блокировки.
Операционные детали для доставки в новый файл
Когда опция “directory” установлена вместо “file”, каждое сообщение доставляется в недавно созданный файл, или установленные файлы. Когда “appendfile” активирован непосредственно из роутера “redirect”, то обычно ни “file”, ни “directory” не устанавливаются, поскольку путь для доставки предоставляется роутером. (Смотрите, например, транспорт “address_file”, в дефолтовой конфигурации.) В этом случае, доставка осуществляется в новый файл, если имя пути завершается на “/”, или установлена опция “maildir_format” или “mailstore_format”.
При записи сообщения в новый файл блокировка не требуется, следовательно, различные опции блокировки транспорта - игнорируются. Строка “From”, которая по умолчанию, разделяет сообщения в одном файле, обычно не требуется, ни экранирование строк сообщения начинающихся с “From”, и нет необходимости обеспечивать новую строку в конце каждого сообщения. Следовательно, значения по умолчанию “check_string”, “message_prefix” и “message_suffix” - все незаданы, когда установлена любая из опций “directory”, “maildir_format” или “mailstore_format”.
Если exim должен проверять установку “quota”, он складывает размеры всех файлов в дефолтовой директории для доставки. Однако, вы можете задать иную директорию, путём установки “quota_directory”. Также, для доставок “maildir” (смотрите ниже), соблюдается соглашение “maildirfolder”.
Есть три различных пути, которыми может быть сделана доставка в индивидуальные файлы,контролируемые параметрами настройки опций “maildir_format” и “mailstore_format”. Отметьте, что код для поддержки форматов “maildir” или “mailstore” не включен в бинарник, если SUPPORT_MAILDIR, или, соответственно, SUPPORT_MAILSTORE не установлены в “Local/Makefile”.
Во всех трёх случаях, делается попытка создать директорию и все необходимые субдиректории, если они не существуют, при условии что установлена опция “create_directory” (по дефолту - установлена). Расположение созданного каталога может быть ограничено установкой “create_file”. Режим созданной директории даётся опцией “directory_mode”. Если создание неудачно, или если опция “create_directory” не установлена, когда требуется создание, доставка задерживается.
Доставка “maildir”
Если истинна опция “maildir_format”, exim доставляет каждое сообщение путём записи его в файл, чьё имя - “tmp/<stime>.H<mtime>P<pid>.<host>”, в директории, определённой опцией “directory” (“директория доставки”). Если доставка успешна, файл переименовывается внутрь субдиректории “new”.
В имени файла, “<stime>” - текущее время дня, в секундах, и “<mtime>” - часть микросекунд времени. После “maildir” доставки, exim проверяет, что часы дневного времени ушли дальше по крайней мере на микросекунду, перед завершением процесса доставки. Это гарантирует уникальность имени файла. Однако, предусмотрительно, exim вызывает “stat()” для файла, до его открытия. Если даётся какой угодно ответ кроме ENOENT (не существует), exim ждёт две секунды, и пробует снова, вплоть до времени “maildir_retries”.
До того, как exim выполнит “maildir”-доставку, он обеспечивает что директории с именами “new”, “cur” и “tmp” существуют в директории доставки. Если они не существуют, exim пробует создать их, и другие предстоящие директории в пути, подчиняясь опциям “create_directory” и “create_file”. Если задана опция “maildirfolder_create_regex”, и её регулярное выражение содержит совпадение с директорией доставки, exim, также, гарантирует, что в директории доставки существует файл “maildirfolder”. Если отсутствующая директория, или файл “maildirfolder” не могут быть созданы, доставка задерживается.
Эти особенности позволяют использовать exim для создания всех необходимых файлов и каталогов в почтовом ящике, включая субдиректории для папок “maildir++”. Рассмотрите этот пример:
maildir_format = true directory = /var/mail/$local_part\ ${if eq{$local_part_suffix}{}{}\ {/.${substr_1:$local_part_suffix}}} maildirfolder_create_regex = /\.[^/]+$
Если пуста “$local_part_suffix” (нет суффикса для локальной части), доставка происходит в вышележащую “maildir”, с именем типа “/var/mail/pimbo” (для юзера с именем “pimbo”). Регулярное выражение в “maildirfolder_create_regex” не совпадает с этим именем, таким образом, exim не будет искать или создавать “/var/mail/pimbo/maildirfolder”, хотя он, в случае необходимости, создаст “/var/mail/pimbo/{cur,new,tmp}”.
Однако, если “$local_part_suffix” содержит, например, “-eximusers”, доставка происходит в папку “maildir++” “/var/mail/pimbo/.eximusers”, которая не совпадает с “maildirfolder_create_regex”. В этом случае, exim создаст “/var/mail/pimbo/.eximusers/maildirfolder”, также как и три директории “maildir” - “/var/mail/pimbo/.eximusers/{cur,new,tmp}”.
Предупреждение: При установке “maildirfolder_create_regex” позаботьтесь о том, чтобы она, по неосторожности, не совпадала с вышестоящей директорией “maildir”, поскольку файл “maildirfolder” на вышестоящем уровне полностью нарушил бы подсчёт квоты.
Если exim обязан проверять установку “quota” до “maildir” доставки, и “quota_directory” не установлена, он ищет файл с именем “maildirfolder” в “maildir”-директории (рядом “new”, “cur”, “tmp”). Если он существует, exim предполагает, что директория - директория папок “maildir++”, которая одним уровнем ниже верхнего уровня пользовательской директории почтового ящика. Это заставляет его начать подсчёт используемого места с родительского каталога, вместо текущей директории.
Проблема, при доставке в многофайловый почтовый ящик, состоит в том, что в вычислительном отношении дорого подсчитать размер почтового ящика, для проверки квоты. Были предприняты различные подходы для уменьшения необходимой работы. Следующие два раздела описывают два из них. Третья альтернатива заключается в использовании какого-то внешнего процесса для обслуживания данных о размере, и использовании раскрытия опции “mailbox_size” как способа импортировать эти данные в exim.
Использование тэгов для записи размера сообщений
Если установлена “maildir_tag”, строка раскрывается для каждой доставки. Когда “maildir”-файл переименовывается в субдиректорию “new”, к его имени добавляется тэг. Однако, если добавялемый тэг берёт длинну имени с которой проверочный вызов “stat()” неудачен по причине ENAMETOOLONG, тег удаляется, и “maildir”-файл создаётся без тега.
Теги могут использоваться для кодирования размеров файлов в их именах; для примера, смотрите выше, опцию “quota_size_regex”. Раскрытие “maildir_tag” происходит после записи сообщения. Значение переменной “$message_size” устанавливается в число фактически записанных байт. Если раскрытие принудительно неудачно, тэг игнорируется, но непринудительная неудача раскрытия приводит к задержке доставки. Раскрытый тэг может содержать любые печатные символы, кроме “/”. Непечатные символы в строке - игнорируются; если результирующая строка пустая - она игнорируется. Если она начинается с алфавитно-цифрового символа - вставляется начальное двоеточие.
Использование файла “maildirsize”
Если истинна опция “maildir_use_size_file”, exim осуществляет правила “maildir++”, для хранения квоты и информации о размере файла в файле с именем “maildirsize”, в директории “maildir” верхнего уровня. Если этот файл не существует, exim создаст его, устанавливая квоту из транспортной опции “quota”. Если не существует сам каталог “maildir”, он его создаст до любых попыток записать файл “maildirsize”.
Файл “maildirsize” используется для хранения информации о размерах сообщений в “maildir”, ускоряя подсчёт квоты. Значение квоты в файле - всего лишь кэш; если квота изменяется в транспорте, новое значение перезаписывает кэшированное при доставке следующего сообщения. Кэш поддерживается для других программ, которые обращаются к “maildir” и должны знать квоту.
Если опция “quota” в транспорте незадана, или равна нулю, файл “maildirsize” поддерживается (с нулевой установкой квоты), но никакой квоты не накладывается.
Для контроля, какие каталоги используются в вычислении квоты при использовании файла “maildirsize”, доступно регулярное выражение. Для дополнительных деталей, смотрите “maildir_quota_directory_regex”, выше.
Доставка “mailstore”
Если истинна опция “mailstore_format”, каждое сообщение записывается как два файла в данной директории. Уникальное базовое имя создаётся из идентификатора сообщения, и текущего процесса доставки, и файлы записываются с использованием этого базового имени, плюс суффиксов “.env” и “.msg”. Файл “.env” содержит конверт сообщения, и файл “.msg” - непосредственно сообщение. Базовое имя помещается в переменную “$mailstore_basename”.
В процессе доставки, конверт, вначале, записывается в файл суффикс.tmp. Затем пишется файл “.msg”, и по завершении записи, файл “.tmp” переименовывается в файл “.env”. Программы, обращающиеся к сообщениям, должны ожидать появления обоих файлов - “.env” и “.msg”, до доступа к любому из них. Альтернативный подход заключается в ожидании исчезновения файла “.tmp”.
Файл конверта начинается с любого текста, заданного опцией “mailstore_prefix”, раскрытой и завершённой символом новой строки, если таковой отсутствует. Затем следует адрес отправителя в одной строке, затем все адреса получателей - по одному на строке.Может быть более одного получателя лишь в случае, если значение опции “batch_max” более одного. В конце, раскрывается “mailstore_suffix” и результат добавляется в файл, сопровождаемый символом новой строки, если он им не заканчивается.
Если раскрытие “mailstore_prefix” или “mailstore_suffix” завершается принудительной неудачей - они игнорируются. Другие ошибки раскрытия рассматриваются как конфигурационные ошибки, и доставка задерживается. Переменная “$mailstore_basename” доступна для использования в процессе этих раскрытий.
Неспециальная доставка в новый файл
Если не установлены ни “maildir_format” ни “mailstore_format”, непосредственно в названном каталоге создаётся единичный новый файл. Например, при доставке сообщений в файлы в пакетном формате SMTP, для позднейшей доставки на другой хост (смотрите раздел 44.10), могут использоваться установки типа таких:
directory = /var/bsmtp/$host
Сообщение записывается в файл с временным именем, которое переименовывается, когда доставка завершена. Финальное имя файла получается путём раскрытия опции “directory_file”.