Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

Sendmail – Архитектура и принципы разработки

Глава 17 из 1 тома книги "Архитектура приложений с открытым исходным кодом".

Оригинал: "Sendmail"
Автор: Eric Allman
Перевод: Vlad http://vlad8.com/

17.7. Эволюция sendmail

Программное обеспечение не выживает в быстро изменяющемся окружении без изменений для приспособления к этому окружению. Появляются новые технологии, которые оказывают влияние на операционные системы, которые в свою очередь влияют на библиотеки и фреймворки, а те – на приложения. Если приложение имеет успех, его начинают использовать в еще более проблемном окружении. Изменения неизбежны; для того, чтобы преуспеть, вам необходимо принять и использовать это. Эта секция описывает наиболее важные изменения в sendmail, которые происходили по мере его развития.

17.7.1. Конфигурирование становится более подробным

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

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

По мере того, как окружение в котором работал sendmail становилось более сложным и 16-битное окружение исчезало, небходимость более богатой конфигурации стала очевидной. К счастью, было возможно добавлять изменения с сохранением обратной совместимости. Эти изменения кардинально улучшили читаемость конфигурационного файла.

17.7.2. Большее количество соединений с другими подсистемами: большая интеграция

Когда sendmail был написан, почтовая система была главным образом изолирована от остальной операционной системы. Существовало несколько служб, которые требовали интеграции, например, файлы /etc/passwd и /etc/hosts. Переключатели служб не были еще изобретены, службы каталогов не существовали, конфигурационные файлы были небольшими и поддерживались вручную.

Но все быстро изменилось. Одним из первых нововведений были DNS. Хотя абстракция поиска системного хоста (gethostbyname) работала для поиска IP-адресов, электронная почта должна была использовать другие запросы, такие как MX. Позже IDA sendmail включила функциональность поиска по внешним базам данных, используя файлы dbm(3). Sendmail 8 получил в обновлении общую службу сопоставления данных, которая позволяла взаимодействие с другими типами баз данных и внутренними данными, с которыми нельзя было работать, использовуя простые преобразования (например, деэкранирование в адресах).

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

17.7.3. Адаптация к враждебному миру

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

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

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

Аналогично, sendmail прошел путь от довольно простого потребителя TCP/IP соединений до гораздо более сложной системы, способной “просматривать” данные, получаемые из сети, чтобы понять, передает ли отправитель команды до того, как предыдущая команда была принята. Это разрушает некоторые предыдущие абстракции, которые были сделаны для того, чтобы sendmail работал в различных типах сетей. Сегодня потребовалось бы немало работы для адаптации sendmail к сети XNS или DECnet, так как информация о работе с TCP/IP уже встроена в большую часть кода.

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

17.7.4. Внедрение новых технологий

Многие новые стандарты появились за эти годы, они потребовали серьезных изменений в sendmail. Например, добавление TLS (шифрования) потребовало значительных изменений в большей части кода. Конвейерная обработка SMTP (pipelining) потребовала низкоуровневого взаимодействия с потоком TCP/IP для избежания дедлоков. Добавление порта отправки (587) требовало способности слушать несколько входящих портов, включая поддержку различного поведения, в зависимости от входящего порта.

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

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


Продолжение статьи: Что если бы я делал sendmail сегодня?


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

Комментарии отсутствуют