Библиотека сайта rus-linux.net
Sendmail – Архитектура и принципы разработки
Глава 17 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: "Sendmail"
Автор: Eric Allman
Перевод: Vlad http://vlad8.com/
17.5. Другие соображения
Некоторые другие проектировочные и архитектурные моменты, которые стоит отметить.
17.5.1. Об оптимизации масштабных Интернет-систем
В большинстве сетевых систем существуют конфликты между клиентом и сервером. Хорошая стратегия для клиента может быть неверной для сервера и наоборот. Например, при возможности на сервере стараются минимизировать затраты на обработку данных, перекладывая эти обязанности как можно больше на клиента, и конечно клиенту также необходимы подобные меры, но в обратном направлении.
Например, на сервере может быть выгоднее держать соединение открытым, обрабатывая спам-сообщения, так как это снижает затраты на отклонение сообщений (что на сегодняшний день является обычным делом), но клиент хочет отключиться как можно быстрее. Если посмотреть на всю систему целиком, Интернет в целом, оптимальным решением может быть баланс между этими двумя необходимостями.
Существовали такие агенты передачи почты, которые явно предпочитали один или другой способ – клиента или сервера. Они могут себе это позволить только потому, что у них довольно немного установок. Если ваша система используется на значительной части Интернета, вам необходимо спроектировать ее так, чтобы сбалансировать нагрузку между двумя сторонами в попытках оптимизировать Интернет как целое. Эта задача осложняется тем, что всегда будут существовать агенты передачи, полностью использующие только один подход, например, массовые почтовые системы, заботящиеся только об оптимизации исходящей стороны.
При разработке системы, которая включает обе стороны соединения, важно избегать подобных предпочтений. Заметьте, что это находится в разительном контрасте с обычной ассиметрией клиентов и сервисов, например, веб-серверы и веб-клиенты обычно не разрабатываются одной и той же группой.
17.5.2. Milter
Одним из наиболее важных дополнений к sendmail был интерфейс milter (mail filter). Milter позволяет использование сторонних плагинов для обработки почты. Изначально они разрабатывались для антиспамовой обработки. Протокол milter работает синхронно с протоколом сервера SMTP. По мере того, как каждая новая команда SMTP, получается от клиента, sendmail вызывает milter с информацией от этой команды. Milter имеет возможность принять эту команду или послать отказ, что отклоняет фазу протокола, соответствующую команде SMTP. Фильтры Milter созданы как callback-функции, поэтому когда приходит команда SMTP, вызывается соответствующая подпрограмма milter. Фильтры Milter работают как подпроцессы, указатель контекста передается в каждом соединении для каждой подпрограммы, что позволяет передачу текущего состояния.
В теории фильтры milter могли работать как подгружаемые модули в пространстве адресов sendmail. Мы отклонили это решениие по трем причинам. Во-первых, вопросы безопасности были слишком значительны: даже если sendmail был запущен под уникальным пользователем-неадминистратором, этот пользователь имел бы доступ ко всем состояниям всех остальных сообщений. Было неизбежно, что некоторые авторы фильтров milter попытались бы получить доступ к внутреннему состоянию sendmail. Во-вторых, мы хотели создать экран между sendmail и фильтрами milter: если фильтр падал, мы хотели, чтобы было ясно, чья была ошибка, и при этом потенциально почта продолжала отправляться. В-третьих, автору фильтра было гораздо легче отлаживать отдельный процесс, а не весь sendmail. Быстро стало понятно, что фильтры были полезны не только для обработки спама. Сайт milter.org содержит список фильтров для борьбы со спамом, вирусами, архивации, мониторинга контента, логирования, изменения траффика и многих других категорий. Фильтры создаются коммерческими компаниями и в качестве проектов с открытым исходным кодом. Программа postfix также добавила поддержку фильтров milter, используя тот же самый интерфейс. Фильтры Milter оказались одним из самых успешных введений sendmail.
17.5.3. Расписание релизов
Довольно популярны споры между двумя подходами – “выпускай быстро и часто” и “выпускай стабильные системы”. Sendmail использовал и тот, и другой подход в разное время. Во время значительных изменений иногда я делал более, чем один релиз в день. Моей общей философией было делать релиз после каждого изменения. Это похоже на предоставление публичного доступа к системному дереву управления исходным кодом. Лично я предпочитаю делать релизы, а не давать публичный доступ к дереву исходного кода, отчасти потому что я использую управление исходным кодом таким образом, который сейчас не одобряется: при больших изменениях я заношу в систему управления контроля версий нефункционирующие версии кода. Если дерево открыто для общего доступа, я использую для этих версий ветки (branches), но в любом случае они доступны для всех и это может привести к значительной путанице. Кроме того, создание релиза означает задание для него номера, а это облегчает отслеживание изменений при работе с баг-репортами. Конечно, это требует того, чтобы релизы можно было делать легко, а это не всегда так.
Со временем, когда sendmail начал использоваться во все более критичном окружении, это стало вызывать проблемы. Другим не всегда было легко понять, было ли выпущенное изменение для тестирования или оно действительно могло использоваться в продакшне. Наименование релизов как “альфа” или “бета” помогало, но не решало проблему. Результатом стало то, что с развитием sendmail перешел от более частых к более объемным релизам. Это стало особенно критично, когда sendmail стал выпускаться коммерческой компанией, клиенты которой хотели последние и самые лучшие и при этом одновременно и стабильные версии и не приняли бы того, что релизы нестабильны.
Эти разногласия между нуждами open source разработчиков и коммерческим продуктом никогда не исчезнут. Есть множество преимуществ в ранних и частых релизах, в частности потенциально большая аудитория отважных (и иногда глуповатых) тестировщиков, которая проверяет систему способами, которые вы никогда не ожидали бы повторить в стандартной системе разработки. Но как только проект становится успешным, есть тенденция превратить его в продукт (даже если этот продукт с открытыми исходными кодами и бесплатный), а продукты имеют другие потребности, нежели проекты.
Продолжение статьи: Безопасность