Sendmail Installation and Operation Guide (part 2)

2. НОРМАЛЬНА РОБОТА2.1. Системний протоколСистемний протокол підтримується програмоюsyslogd(8). Всі повідомлення відsendmailпротоколюються за допомогою LOG_MAIL 1 .2.1.1. ФорматКожен рядок у системному протоколі складається з тимчасової позначки, імені машини, що створила її (для протоколювання з декількох машин через локальну мережу), слова "sendmail:", та самого повідомлення 2 . Більшість повідомлень є послідовністю парім'я=значення.

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

to	Список одержувачів для цієї поштової програми, розділений комами.
ctladdr	"Контрольний користувач", тобто ім'я користувача, чиї параметри ми використовуємо при доставці.
delay	Загальний час затримки між отриманням та доставкою повідомлення.
xdelay	Час, який знадобився для спроби доставки (зазвичай показує швидкість з'єднання).
mailer	Ім'я поштової програми, що використовується для доставки до одержувача.
relay	Ім'я хоста, що прийняв повідомлення для одержувача (або відмовив у доставці).
dsn	Удосконалений код помилки (RFC 2034), якщо доступний
stat	Статус доставки.

Не всі ці поля є для всіх повідомлень; наприклад, для локальних повідомлень немає поля relay.2.1.2.Якщо у вас встановленоsyslogd(8) або його еквівалент, то ви можете проводити протоколювання. Євелика кількість інформації, яку можна запротоколювати. Протокол організовано як послідовність рівнів. На нижньому рівні протоколюються лише найдивніші ситуації. На найвищому рівні навіть звичайнісінькі та нецікаві події записуються для потомства. Відповідно до угоди, рівні протоколювання нижче десятого зазвичай вважаються "корисними"; рівні протоколювання вище 64 зарезервовані з метою налагодження. Рівні з 11 до 64 зарезервовані для багатослівної інформації, що можуть захотіти деякі вузли.

Повний опис рівнів протоколювання наведено в розділі 4.6.2.2. Стан СкиданняВи можете попроситиsendmailскинути протокол відкритих файлів та кешу з'єднань, надіславши йому сигнал SIGUSR1. Результати протоколюються за черговістю LOG_DEBUG.2.3. Поштова чергаІнодіsendmailне може обслуговувати повідомлення негайно. Наприклад, він може бути перевантажений, або взагалі впасти, наслідком чого буде відмова від з'єднань. Тоді хост, що посилає, повинен буде зберегти це повідомлення у своїй поштовій черзі і спробувати доставити його пізніше.

За нормальних умов поштова черга оброблятиметься прозоро. Однак ви можете виявити, що іноді потрібно втрутитися руками. Наприклад, якщо основний хост довгий час вимкнено, черга може засмічитися. Хочаsendmailмає нормально відновити все під час завантаження хоста, тим часом ви можете знайти його продуктивність неприйнятно низькою.2.3.1. Друк ЧергиВміст черги можна роздрукувати, використовуючи командуmailq(або вказавшиsendmailпрапор-bp): mailq Результатом її виконання буде список ідентифікаторів повідомлень, що знаходяться у черзі, розмірів повідомлень, дати надходження повідомлення в чергу, тавідправник із одержувачами.2.3.2. Прискорення ЧергиSendmailмає обробляти чергу автоматично через певний інтервал. При використанні безлічі черг для обробки кожної з черг буде запущено окремий процес, якщо обробка черги не ініційована користувачем з прапором подробиць (verbose flag). Алгоритм такий: прочитати та відсортувати чергу, а потім опрацювати всі повідомлення по порядку. При спробі запустити роботу,sendmailспочатку перевіряє, чи не заблоковано її. Якщо блокування є, він ігнорує цю роботу.

Не робиться жодної спроби переконатися в тому, що тільки один обробник черги існує у будь-який час, тому немає жодної гарантії, що робота не буде проводитися вічно (проте,sendmailмає деяку евристику, щоб спробувати припинити роботу, що займає абсурдно багато часу, технологічно, це порушує вимоги RFC 821, але схвалюється в RFC 1123). Згідно з алгоритмом блокування, одна робота не може заморозити всю чергу. Однак, недружній хост, що приймає, або програма прийому, яка ніколи нічого не повертає, може зібрати велику кількість процесів у вашій системі. На жаль, немає жодного спільного рішення для вирішення подібних проблем.

У деяких випадках, ви можете помітити, що основний хост другий день як впав, і у вас накопичилася неймовірно велика черга. В результатіsendmailбільшу частину часу проводитиме, сортуючи цю чергу. Ця ситуація може бути виправлена, якщо ви заберете чергу в якесь тимчасове місце і створите нову чергу. Стару чергу можна буде обробити згодом, коли хост-порушник знову почне працювати.

Щоб це зробити, можна перенести весь каталогчерги: cd /var/spool

mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue Потім ви повинні убити працюючий демон (бо він все ще буде продовжувати обробляти старий каталог черги) і створити нового демона.

Щоб обробити стару чергу, запустіть наступну команду: /usr/sbin/sendmail -oQ/var/spool/omqueue -q Прапор-oQвизначить альтернативний каталог черги, а прапор-qскаже про те, що потрібна лише обробка кожного повідомлення в черзі. Якщо у вас є потяг до вуайєризму, ви можете використовувати прапор-v, щоб подивитися, що відбуватиметься.

Коли на черзі нарешті не залишиться жодного повідомлення, ви зможете видалити цей каталог: rmdir /var/spool/omqueue2.4. Дискова інформація про з'єднанняПро кожну віддалену систему, з якою було з'єднання,sendmailзберігає в пам'яті велику кількість інформації. Тепер можна зберігати деяку частину цієї інформації на диску, використовуючи опціюHostStatusDirectory, яка може одночасно використовуватися кількома процесамиsendmail. Це дозволяє негайно ставити пошту в чергу або пропустити її при обробці черги, якщо нещодавно було невдале з'єднання з віддаленою машиною.

Додатково, включення опціїSingleThreadDeliveryдасть додатковий ефект доставки пошти до місця призначення одним ланцюжком. Це може допомогти, якщо на віддаленій машині працює сервер SMTP, який легко навантажується, або може працювати тільки з одним з'єднанням за раз. Вона застосовується довсімхостів, тому її установка через те, що на вашому вузлі для доставки пошти використовується одна машина, на якій працює додаткове програмне забезпечення, що збільшує завантаження машини, може призвести до уповільненнядоставки пошти на інші хости. Якщо ця опція виставлена, то вам, можливо, захочеться виставити опціюMinQueueAge, щоб ваша черга оброблялася досить часто; в результаті роботи, пропущені через те, що інший процес sendmail розмовляв з тим же хостом, незабаром будуть випробувані знову, а не відкладені на довгий час.

З метою оптимізації таймаутів, інформація, що зберігається на диску, обслуговується так само, як і інформація, що зберігається у пам'яті. За промовчанням інформація про помилки хостів дійсна протягом 30 хвилин. Це значення можна змінити опцієюTimeout.hoststatus.

З дисковою інформацією про з'єднання щодо таймаутів звертаються так само, як і з тією, що знаходиться в пам'яті. За умовчанням, інформація про невдачі з хостами вважається дійсною протягом 30 хвилин. Це значення можна змінити опцієюTimeout.hoststatus.

Якщо операційна система не підтримує сервісний перемикач (наприклад, SunOS 4.x, HP-UX, BSD), тоsendmailвикористовуватиме свою фіктивну реалізацію. ОпціяServiceSwitchFileвказує на ім'я файлу, що містить визначення сервісів. Кожен рядок містить ім'я сервісу та можливі реалізації цього сервісу. Наприклад, файл: hosts dns files nis aliases files nis попроситьsendmailпереглядати імена хостів спочатку в Domain Name System. Якщо ім'я хоста не знайдено, він спробує локальні файли, якщо і там не знайде, то спробує NIS. Так само, при перегляді псевдонімів, спочатку він спробує локальні файли, а потім NIS.

Друга форма обробляється бібліотекоюndbm(3) 5 або бібліотекою Berkley DB. Ця форма знаходиться у файлах/etc/mail/aliases.db(якщо використовується NEWDB) або/etc/mail/aliases.dirта/etc/mail/aliases.pag(якщо використовується NDBM). Це та форма, яку використовуєsendmailщодо псевдонімів. Ця технологія використовується збільшення продуктивності.

Управління порядком пошуку виставляється безпосередньо сервісним перемикачем. Фактично, входження O AliasFile=switch:aliases завжди додається як перше входження псевдонімів; також, перше ім'я файлу псевдонімів без класу (наприклад, без "nis:" спочатку) буде використано як ім'я файлу для входження "files" у перемикачі псевдонімів. Наприклад, якщо конфігурація містить O AliasFile=/etc/mail/aliases, а сервісний перемикач містить aliases nis files nisplus то псевдоніми спочатку шукатимуться в базі даних NIS, потім /etc/mail/aliases, а потім у базі даних NIS+.

Також можна використовувати файли псевдонімів на основі NIS. Наприклад, визначення: O AliasFile=/etc/mail/aliases

Якщо ви визначили кілька баз даних псевдонімів, прапор-biперебудує всі типи баз даних, які він розуміє (наприклад, він може перебудовувати бази даних NDBM, але не може бази даних NIS).2.6.2. Потенційні проблеми Існує кілька проблем, які можуть статися з базою даних псевдонімів. Всі вони походять з того, що процесsendmailможе почати використовувати DBM-версію псевдонімів, коли вона буде побудована лише частково. Це може статися за двох умов: один процес використовує базу даних, тоді як другий її перебудовує, або процес, що займається перебудовою бази даних, помирає (через те, що його вбили, або система раптом впала) до завершення перебудови.

unix-wizards-request: eric@ucbarpa змусить "eric@ucbarpa" отримувати помилки, які відбудуться, коли хтось посилає в unix-wizards і потрапляє під входження "nosuchuser" у списку.

Заголовок Errors-To: офіційно вже прибрано, і в наступних випусках не буде.2.9.2. Apparently-To: RFC 822 вимагає в кожному повідомленні мати принаймні одне поле одержувача (рядок To:, Cc:, або Bcc:). Якщо повідомлення надходить без вказівки будь-якого одержувача в повідомленні,sendmailдодасть заголовок на основі опції "NoRecipientAction". Однією з можливих дій буде добавка до заголовка рядка "Apparently-To:" для кожного одержувача, про який він знає.

Заголовок Apparently-To: нестандартний та опротестований.2.9.3. PrecedenceЗаголовок Precedence: може бути використаний як грубе управління пріоритетом повідомлення. Він перебудовує порядок у черзі і може бути налаштований на зміну значень таймаутів для повідомлення. Пріоритет листа також контролює обробку повідомлення про статус доставки (DSN - delivery status notification) для цього листа.2.10. Підтримка протоколу IDENTSendmailпідтримує протокол >6. Положення безпеки

Інформації, що повертається цим протоколом, можна довіряти настільки, наскільки можна довіряти хосту АБО організації, в якій знаходиться цей хост. Наприклад, PC у відкритій лабораторії має небагато, якщо взагалі взагалі щось забороняє користувачеві вказати цьому протоколу повертати будь-який ідентифікатор, який він захоче. Так само, якщо хост був скомпрометований, інформація, що їм повертається, може бути повністю помилкова і невірна.

Використання інформації, отриманої з цього протоколу, для чогось іншого, ніж посвідчення, дуже не радиться. Особливо, використання Ідентифікаційного Протоколу для винесення рішень про доступ - як головного методу (тобто.єдиної перевірки) так і як доповнення до інших методів може призвести до послаблення нормальної безпеки хоста.

У деяких випадках ваша система може не працювати нормально з підтримкою IDENT через помилку реалізації TCP/IP. Симптоми будуть такі: для деяких хостів з'єднання SMTP закриватиметься майже відразу. Якщо це дійсно так відбувається, або ви не хочете використовувати IDENT, ви повинні встановити тайм-аут IDENT рівним нулю; це відключить протокол IDENT.

1. Крім Ultrix, що не підтримує в Syslog різні засоби. [назад]

2. Цей формат може бути трохи іншим, якщо ваш постачальник змінив синтаксис. [назад]

3. Це нормальне значення опції HostStatusDirectory; звичайно ж, якщо ви захочете, вона може вказувати на будь-яке місце у вашій файловій системі. [назад]

4. Насправді будь-яка поштова програма, що має виставлений поштовий прапор "A", дозволятиме псевдонімізацію; зазвичай це обмежено локальною поштовою програмою. [назад]

---