4. Настройка

В зависимости от потребностей вашего узла, вы можете захотеть изменить те или иные конфигурационные параметры. Большинство из них устанавливаются опциями в файле конфигурации. Например, строка "O Timeout.queuereturn=5d" устанавливает опции "Timeout.queuereturn" значение "5d" (пять дней).

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

Все версии sendmail до 8.7 имели имена опций, состоящие из одного символа. С 8.7, опции имеют длинные (состоящие из нескольких символов) имена. Хотя старые короткие имена до сих пор принимаются, многие новые опции не имеют коротких эквивалентов.

Этот раздел описывает только те опции, которые вам, вероятно, захочется изменить; более детальное описание опций дано в разделе 5.

Все временные интервалы устанавливаются с использованием масштабного синтаксиса. Например, "10m" означает десять минут, в то время как "2h30m" означает два с половиной часа. Вот полный набор масштабов:

Аргумент для флага -q определяет, как часто поддемон будет обрабатывать очередь. Обычно это значение меняется от пятнадцати минут до одного часа. Секция 5.3.1.1 RFC 1123 рекомендует устанавливать его равным как минимум 30 минутам.

Все таймауты имеют имена типа "Timeout.подопция". Все распознаваемые подопции, их значения по умолчанию, и минимальные значения, позволяемые секцией 5.3.2 RFC 1123 таковы:

Для совместимости со старыми файлами конфигурации, если ни одна подопция не определена, таймауты обозначенные знаком | устанавливаются равными указанному значению.

Многие из минимальных значений в RFC 1123 слишком малы. Sendmail был разработан для протоколов RFC 822, которые не определяют таймауты чтения; следовательно, версии sendmail до 8.1 не гарантируют быстрого ответа на сообщения. В частности, команда "RCPT" определяющая список рассылки будет расширена и проверит весь список полностью; большой список на медленной системе может запросто занять времени больше, чем пять минут². Я рекомендую таймаут в один час - так как обрыв соединения во время фазы RCPT достаточно редки, длительный таймаут не обременителен, но может сильно помочь в уменьшении загрузки сети и повторных сообщений.

Например, строки:

Устанавливает серверу SMTP таймаут на команды 25 минут и таймаут на ввод блока данных 3 часа.

Если сообщение будет находиться в очереди несколько дней, то время его обработки закончится. Это делается для того, чтобы быть уверенным, что отправитель, по крайней мере, предупрежден о невозможности доставки сообщения. Обычно таймаут равен пяти дням. Иногда удобно также посылать предупреждение, если сообщение находится в очереди на протяжении нескольких часов (подразумевается, что обычно у вас хорошая связь; если же обычно отсылка ваших сообщений занимает несколько часов, то вам не захочется получать такие сообщения, так как это вполне нормальное событие). Эти таймауты выставляются опциями Timeout.queuereturn и Timeout.queuewarn в файле конфигурации (раньше оба значения выставлялись опцией T).

Так как эти опции глобальны, и вы не знаете заранее, сколько времени хост вне вашего домена будет отключен, рекомендуемый таймаут составляет пять дней. Это позволяет получателю исправить проблему, даже если она случилась в самом начале длительных выходных. Секция 5.3.1.1 RFC 1123 говорит, что этот параметр должен быть "как минимум 4-5 дней".

Значение Timeout.queuewarn может быть вложено в опцию T указанием времени, по истечении которого должно быть послано предупреждение; два таймаута разделяются слешем. Например, строка

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

Указанием опции ForkEachJob (Y), можно заставить sendmail ветвиться перед каждым отдельным сообщением во время прохода очереди. Это защитит вас от потребления sendmail большого количества памяти, что очень полезно, если у вас не очень много памяти. Однако если опция ForkEachJob не выставлена, sendmail во время прохода очереди будет помнить об отключенных хостах, что может повысить производительность системы.

Если опция ForkEachJob не выставлена, sendmail не может использовать кэшированные соединения.

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

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

Коэффициенты получателя и класса могут быть установлены в файле конфигурации, используя опции RecipientFactor (y) и ClassFactor (z) соответственно. По умолчанию, они равны: 30000 (для коэффициента получателя) и 1800 (для коэффициента класса). Первичный приоритет таков:

pri = msgsize - (class умноженный на ClassFactor) + (nrcpt умноженное на RecipientFactor)

(Запомните, более высокое значение этого параметра на самом деле означает, что работа будет обработана с низким приоритетом.)

Приоритет работы скорректирован при каждой обработке сообщения (то есть, при каждой попытке его доставки) использованием "рабочего коэффициента времени", установленного опцией RetryFactor (Z). Он добавляется к приоритету, поэтому обычно он уменьшает старшинство работы, на основании того, что работа, не выполненная много раз, вполне может быть не выполнена опять. Опция RetryFactor по умолчанию равна 90000.

Sendmail можно попросить принимать и откладывать в очередь (но не доставлять) почту, если средняя загрузка системы становиться слишком большой. Для этого используется опция QueueLA (x). Когда средняя загрузка системы превышает значение опции QueueLA, устанавливается режим q (только очередь), если опция QueueFactor (q) деленная на разность средней загрузки системы и значения опции QueueLA плюс единица, превысит приоритет сообщения - то есть, сообщение откладывается в очередь, если, и только если:

pri > { QueueFactor } / { LA - { QueueLA } + 1 }

По умолчанию опция QueueFactor равна 600000, так что каждая единица средней загрузки стоит 600000 пунктов приоритета (как описано выше).

Для крутых случаев, опция RefuseLA (X) определяет среднюю загрузку, при которой sendmail будет отказываться принимать сетевые соединения. Локально созданная почта (включая входящую почту UUCP) будет приниматься.

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

Есть и компромиссы. Режим "i" дает отправителю быстрейшую обратную связь, но может замедлить некоторые почтовые программы намного больше необходимого. Режим "b" доставляет быстро, но может наплодить кучу процессов, если ваша почтовая программа тратит много времени на доставку сообщений. Режим "q" минимизирует загрузку вашей машины, но доставка сообщений будет задержана до наступления очередного интервала. Режим "d" идентичен режиму "q", за исключением того, что он также предотвращает работу всех просмотров; он предназначен для узлов "dial on demand", где просмотр DNS может стоить реальные деньги. Некоторые простые сообщения об ошибках (например, host unknown during the SMTP protocol) в этом режиме будут задержаны. По умолчанию обычно используется режим "b".

Если вы запускаете sendmail в режиме "q" (только очередь), "d" (отсрочка), или "b" (доставка в фоне), то он не будет разворачивать псевдонимы и следовать файлам .forward, вплоть до первого получения почты. Это ускоряет ответ на команду RCPT. Режим "i" не может быть использован сервером SMTP.

Sendmail'у может быть указан уровень протоколирования. По умолчанию стандартной таблицей конфигурации используется уровень 9. Имеются следующие уровни:

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

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

Sendmail может вполне безопасно сделан setuid на root. Тогда, когда он собирается запустить с помощью exec(2) почтовую программу, он проверяет, равен ли userid нулю; если равен, то он переустанавливает userid и groupid на значения по умолчанию (выставляемые равенством U= в строке почтовой программы; если это равенство не установлено, используется опция DefaultUser). Это может быть преодолено выставкой флага S у почтовой программы для доверенных почтовых программ, которые могут быть запущены от root. Однако, это заставит обработку почты быть засчитанной sa(8) как потребление пользователем root системных ресурсов, вместо того, чтобы засчитать это пользователю, посылающему почту.

Если вы не делаете sendmail setuid'ным на root, он все равно будет работать, но вы потеряете большиую часть функциональности и конфиденциальности, а так же вам придется открыть всем на запись каталог очереди. Также вы можете сделать sendmail setuid'ным на какого-либо псевдопользователя (например, создав пользователя "sendmail" и сделав sendmail setuid'ным на него) что исправит проблему конфиденциальности, но не вопросы функциональности. Также, это не будет являться гарантией безопасности: например, пользователь root посылает почту, и демон будет часто работать от пользователя root.

В качестве компромисса можно сделать sendmail setuid'ным на пользователя root, но выставить опцию RunAsUser. В результате это заставит sendmail стать указанным пользователем сразу же после запуска, требующего привилегии пользователя root (главным образом, открытия порта SMTP). Если вы используете опцию RunAsUser, каталог очереди (обычно /var/spool/mqueue) должен принадлежать этому пользователю, а все файлы и базы данных (включая пользовательские файлы .forward, файлы псевдонимов, файлы :include, и внешние базы данных) должны быть открыты для этого пользователя на чтение. RunAsUser скорее всего наиболее подходит для конфигурации на брандмауэрах, не имеющих регулярных заходов пользователей.

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

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

При обработке очереди, sendmail будет пытаться держать несколько последних соединений открытыми, во избежание потерь при запуске и остановке. Это применяется только к IPC соединениям.

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

Кэшем соединений управляют два параметра. Опция ConnectionCacheSize (k) определяет количество позволенных одновременно открытых соединений. Если оно равно нулю, соединения будут закрываться, как только это станет возможным. По умолчанию оно равно одному. Его можно установить такого размера, как вам потребуется; оно будет ограничивать количество системных ресурсов, используемых sendmail при обработке очереди. Никогда не устанавливайте это значение больше 4.

Опция ConnectionCacheTimeout (K) определяет максимальное время бездеятельности любого кэшированного соединения. Когда время простоя превысит это значение, соединение будет закрыто. Это число должно быть небольшим (до 10 минут), чтобы вы не занимали системные ресурсы других машин. Значение по умолчанию пять минут.

Управление просмотром адресов хостов назначается вхождением сервиса hosts в вашем файле сервисного переключателя. Если ваша система имеет встроенную поддержку сервисного переключателя (например, Ultrix, Solaris, или DEC OSF/1) то вполне вероятно, что ваша система уже нормально сконфигурирована. В ином случае, sendmail проконсультируется с файлом /etc/service.switch, который должен быть создан. Sendmail использует только два вхождения: hosts и aliases, хотя системные программы могут использовать иные сервисы (особенно сервис passwd для просмотра имени пользователя с помощью getpwname).

Однако, некоторые системы (типа SunOS) будут производить просмотр DNS независимо от установленных значений сервисного переключателя. В частности, системная подпрограмма gethostbyname(3) используется для просмотра имен хостов, а многие версии поставщиков пытаются использовать комбинации DNS, NIS, и просмотр файла /etc/hosts без консультации с сервисным переключателем. Sendmail не пытается обойти эту проблему, и просмотр DNS будет сделан в любом случае. Если же у вас вообще не сконфигурирован сервер имен, например, у вас чисто UUCP узел, sendmail будет получать сообщения "connection refused" при попытке соединения с сервером имен. Если вхождение hosts переключателя имеет перечисленным в любом месте списка сервис "dns", sendmail будет считать это временной неудачей и поставит сообщение в очередь для последующей обработки; другими словами, он игнорирует данные сервера имен.

Такая же технология используется при решении о просмотре MX. Если вы хотите иметь поддержку MX, вы должны иметь "dns" перечисленным как сервис во вхождении hosts переключателя.

Опция ResolverOptions (I) позволяет вам изменять опции сервера имен. Командная строка принимает последовательность флагов, как описано в resolver(3) (с удаленным первым "RES_"). Каждый из них может быть предварен опциональным "+" или "-". Например, строка

включает опцию AAONLY (принимать только авторитативные сообщения) и выключает опцию DNSRCH (поиск по доменному пути). По умолчанию большинство флагов библиотеки разрешителя отключены, включены только DNSRCH, DEFNAMES, и RECURSE. Вы также можете включить "HasWildcardMX", чтобы указать, что существует масочная запись MX, соответствующая вашему домену; это отключает сопоставление MX при канонификации имен, что может привести к неверной канонификации.

Версия конфигурации уровня 1 выключает DNSRCH и DEFNAMES для просмотров, делаемых при доставке, но оставляет их включенными во всех остальных случаях. Версия 8 sendmail игнорирует их при канонификационных просмотрах (при использовании $[ ... $]), и всегда делает поиск. Если вы не хотите автоматического расширения имен, не вызывайте $[ ... $].

Правила поиска для $[ ... $] - это что-то непохожее, чем необычное. Если просматриваемое имя имеет хотя бы одну точку, оно всегда будет опробовано без изменений. Если это не удастся, будет опробован уменьшенный путь поиска, и в конце концов будет опробовано неизмененное имя (но только для имен без точек, потому что имена с точками уже были опробованы). Это позволяет именам типа "utc.CS" совпадать с узлами в Чехословакии, а не с узлами в вашем местном отделении Computer Science. Они также предпочитают записи типов A и CNAME записям типа MX- поэтому, если находится запись MX, о ней делается заметка, но просмотр продолжается. Таким образом, если вы имеете масочную запись MX, соответствующую вашему домену, то это не будет распознано, как будто все имена совпадают с ней.

Для полного выключения доступа к серверу имен в, системах без поддержки сервисного переключателя (типа SunOS), вы должны будете перекомпилировать sendmail с -DNAMED_BIND=0 и удалив -lresolv из списка искомых при линковании библиотек.

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

Опция ForwardPath (J) позволяет вам назначить путь к файлам перенаправления. Например, строка файла конфигурации

Сначала будет искать файл с именем, совпадающим с именем пользователя в /var/forward; если он не найден, или к нему нет доступа, в домашнем каталоге пользователя будет искаться файл ".forward.machinename". Только узел настоящих извращенцев может также искать по отправителю, используя $r, $s, или $f.

Если вы создаете каталог типа /var/forward, он должен иметь пермиссии 1777 (то есть, должен быть выставлен sticky bit). Пользователи должны создавать файлы с пермиссиями 644. Заметьте, что для разрешения файлов перенаправления в каталоге, открытом всем на запись, вы должны использовать флаги ForwardFileInUnsafeDirPath и ForwardFileInUnsafeDirPathSafe с опцией DontBlameSendmail.

В системах, имеющих один из системных вызовов семейства statfs(2) (включая statvfs и ustat), вы можете указать минимальное количество свободных блоков в файловой системе очереди, используя опцию MinFreeBlocks (b). Если в файловой системе, содержащей очередь, доступно меньше, чем указанное количество блоков, сервер SMTP будет отказываться от почты кодом ошибки 452. Такой отказ приглашает клиентов SMTP попытаться установить соединение позднее.

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

Во избежание переполнения вашей системы большим сообщением, может быть выставлена опция MaxMessageSize, указывающая абсолютное ограничение размера любого сообщения. Это будет сообщено в диалоге ESMTP и проверено при передаче сообщения.

Опция PrivacyOptions (p) позволяет вам установить конкретные "конфиденциальные" флаги. На самом деле, многие из них не дадут вам экстра конфиденциальности, а только лишь настоят на том, чтобы клиентские сервера SMTP использовали команду HELO до использования конкретных команд, или добавлением дополнительных заголовков, для распознания попыток подкачки.

Опция принимает последовательности имен флагов; крайняя конфиденциальность - включение всех этих флагов. Например:

Настоит на том, чтобы команда HELO или EHLO была использована до принятия команды MAIL и отключает команду EXPN.

Флаги подробно описаны в разделе 5.6.

Обычно, sendmail удаляет (конвертного) отправителя из любого списка расширений. Например, если "matt" посылает письмо в список, содержащий "matt" как одного из своих членов, то он, скорее всего, не захочет получить копию своего же сообщения. Если в командной строке есть флаг -m (мне тоже), или в файле конфигурации выставлена опция MeToo (m), это свойство не используется. Некоторые узлы любят запускать демон SMTP с -m.

1. В некоторых системах по умолчанию нуль, чтобы окончательно отключить протокол. [назад]