GNU Mailman

Оригинал: GNU Mailman
Автор: Barry Warsaw
Перевод: А.Панин

10.5. Правила, звенья и цепочки

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

Единственной проблемой данного подхода является тот факт, что смешивание функций модерации и модификации сообщений в рамках одного канала может привести к проблемам. Обработчики должны быть установлены в канале в определенной последовательности, иначе результаты обработки сообщений могут быть непредсказуемыми и нежелательными. Например, если обработчик сообщения добавит заголовки List-*, описанные стандартом RFC 2369, после того, как другой обработчик сообщения скопирует его в хранилище каталога, подписчикам, получающим каталоги, будут отправлены некорректные копии сообщений из списка рассылки. В различных случаях может оказаться выгодной модерация сообщения до или после его модификации. В версии 3 системы Mailman операции модерации и модификации были разделены и реализованы в рамках отдельных подсистем для лучшего контроля над последовательностью их выполнения.

Как было описано ранее, обработчик для поддержки протокола LMTP производит разбор входящего байтового потока, преобразует его в дерево объектов сообщения и создает начальный словарь метаданных сообщения. После этого он перемещает сообщения в одну из других директорий очередей. Некоторые сообщения могут быть email-командами (email commands) (т.е., командами для создания или удаления подписки на список рассылки, для получения автоматизированной справки, и.т.д.), обрабатываемыми в рамках отдельной очереди. Большинство сообщений являются сообщениями для размещения в списке рассылки, которые помещаются в очередь входящих сообщений (incoming queue). Обработчик очереди входящих сообщений обрабатывает каждое сообщение последовательно в цепочке (chain), состоящей из любого количества звеньев (links). Существует встроенная цепочка, которую использует большинство списков рассылки, но даже это возможно изменить путем изменения параметра конфигурации.

Рисунок 10.3 иллюстрирует стандартный набор цепочек версии 3 системы Mailman. Каждое звено в цепочке показано с помощью прямоугольника со скругленными краями. Встроенная цепочка отличается тем, что в ней в отношении входящих сообщений применяются начальные правила модерации, а также в этой цепочке каждое звено ассоциировано с правилом (rule). Правила являются простыми фрагментами кода, которым передается три стандартных параметра: объект списка рассылки, дерево объектов сообщения и словарь метаданных сообщения. Правила не предназначены для модификации сообщения; они просто принимают решение и возвращают логическое значение, отвечая на вопрос: "Выполняется ли правило или нет?". Правила также могут записывать информацию в словарь метаданных сообщения.

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

Рисунок 10.3: Упрощенный вид стандартных цепочек с их звеньями

Важно отметить, что сами правила не выполняют действий на основании результатов. Во встроенной цепочке каждое звено ассоциировано с действием (action), которое выполняется в случае выполнения правила. Например, когда выполняется правило "повтора" (определяющее, что это сообщение уже встречалось ранее в списке рассылки), сообщение немедленно перемещается в цепочку "отклоненных сообщений", из которой оно будет удалено по истечении некоторого периода хранения. Если правило "повтора" не выполняется, то следующее звено в цепочке будет обрабатывать это же сообщение.

На Рисунке 10.3 звенья, ассоциированные с правилами административной проверки ("administrivia"), проверки максимального размера ("max-size") и истинного решения ("truth") не возвращают логических результатов. В случае первых двух правил такая реализация объясняется тем, что их действие отсрочено, поэтому они просто записывают результат сравнения и обработка сообщения продолжается следующим звеном. После этого правило проверки любого значения ("any") проверяет, выполнено ли любое из предыдущих правил. Таким образом система Mailman может сообщить о всех причинах запрета на размещение сообщения, вместо единственной первой причины. Существует еще несколько таких правил, которые не были отображены на рисунке с целью упрощения представления.

Правило истинного решения ("truth") немного отличается. Оно обычно ассоциируется с последним звеном в цепочке и всегда выполняется. В комбинации с предпоследним в цепочке правилом проверки любого значения ("any"), затрагивающим результаты выполнения правил в отношении всех ранее обработанных сообщений, последнее звено может быть уверенно в том, что любое достигшее его сообщение должно быть размещено в списке рассылки, поэтому оно безусловно перемещается в цепочку разрешенных для размещения сообщений ("accepted" chain).

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

Что случится с сообщением после попадания в цепочку разрешенных для размещения сообщений ("accept" chain)? Сообщение, которое теперь считается подходящим для списка рассылки направляется в очередь канала (pipeline queue) для выполнения некоторых модификаций перед доставкой принимающим сообщения подписчикам списка рассылки. Этот процесс более подробно описан в следующем разделе.

Цепочка хранения сообщений ("hold" chain) помещает сообщение в специальное хранилище для ознакомления с ним человека, выполняющего функции модератора. Цепочка модерации ("moderation" chain) выполняет небольшое количество дополнительных операций для формирования решения по поводу того, должно ли сообщение быть принято, заблокировано для утверждения модератором, не принято или отклонено. Для того, чтобы избежать чрезмерного усложнения диаграммы, очередь отклоненных сообщений, которая используется для возвращения сообщений отправителям, не отображена.

Далее: Обработчики сообщений и каналы