Когда интернета еще не было почта уже была¶

"Перевороты совершаются в тупиках".

В 1965 году интернета еще не было, однако два сотрудника Массачусетского технологического института Ноэль Морис и Том Ван Влек, написали программу MAIL для операционной системы CTSS.

Пользователи тогда работали каждый со своего терминала на одном компьютере (персоналок тоже еще не было). Между ними и осуществлялась пересылка с помощью программы MAIL следующим образом: в домашней папке пользователя, кому адресовалось сообщение, формировался или редактировался файл MAIL BOX (почтовый ящик), в него записывался текст сообщения.

Удивительно, что формат mbox дожил до наших дней и используется до сих пор (наряду с его новой редакцией maildir).

Официальной датой создания электронной почты считается 1971 год. Её создателя зовут Рэй Томлинсон, который написал свою программу для сети APRANET.

Программа состояла из двух частей: READMAIL (прочитать письмо) и SNDMSG (отправить письмо). Чтобы различать компьютеры, Рэй использовал символ « @ », что имело такой вид: от_меня@мой_компьютер => вам@ваш_компьютер (много позднее с появлением доменов компьютер в адресе был заменен на домен). Таким образом, сообщения можно было отправлять уже на удаленные компьютеры в сети. Этот метод используется и до сих пор.

Вот так и получилось, что Email старше, чем интернет.

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

Классический почтовый сервер состоит из двух компонентов: MTA - транспортный агент и MDA - агент доставки (хранилище). Сегодня к данной схеме привыкли настолько, что специалисты даже рассуждают в этих терминах. Чтобы понять причину давайте совершим путешествие в прошлое. Это сегодня SMTP победил во всем интернет и считается единственным стандартом, однако так было не всегда. Относительно недавно существовало огромное количество типов электронной почты, каждый из которых предполагал собственный протокол, собственную адресацию и разумеется собственный транспортный агент. Сервера того времени могли иметь несколько транспортных агентов для каждого протокола, но только одну систему хранения, работающую с пользовательскими программами. Тогда такая архитектура была обоснована, но сегодня является пережитком прошлого, мешающим работать.

Первоначально письма хранились в папке MAIL, которая находилась в домашнем каталоге (/home/user) каждого пользователя. В результате получился одни из несложных форматов - mbox . Основная проблема с форматом mbox заключается в блокировке файлов - если у вас более одного процесса, пытающегося получить доступ к почтовому ящику, вы рискуете получить поврежденный почтовый ящик. Но даже в случае одного процесса чрезвычайно затруднены массовые процессы. Именно поэтому сейчас формат Mbox считается устаревшим и поддерживается в основном для обеспечения обратной совместимости (в частности, для архивирования, поскольку mbox позволяет изначально хранить несколько сообщений в одном файле).

Поэтому в 2000 году Дэниэлом Бернштейном (автором почтового сервера qmail) был разработан новый формат - maildir . Позднее Сэм Варшавчик (автор почтового сервера Courier Mail Server) написал расширение формата - Maildir++ (в котором реализованы вложенные папки и квоты на почту). Принципиальное отличие maildir в том, что каждое сообщение хранится в отдельном файле, тем самым снижается риск конфликта процессов, связанных с блокировкой файлов. Данный формат получил значительное распространение и сейчас является популярным.

Однако и maildir не лишен серьезных недостатков. В частности:

Некорректное состояние при работе без блокировок. Maildir спроектирован так, чтобы несколько процессов могли безопасно производить запись параллельно даже при использовании NFS. В процессе чтения структуры каталога любые файлы, которые будут переименованы между первым и последним системными вызовами readdir(), могут не появиться в списке файлов. Это заставляет читающий процесс поверить, что сообщение было удалено, в то время как на самом деле изменились только его флаги. Когда процесс считывает список сообщений снова, вдруг вновь появляется «удалённое» сообщение. Поэтому некоторые программы используют собственный нестандартный способ блокировки.

Совместимость с файловыми системами. Стандарт Maildir нельзя реализовать на системах, не поддерживающих двоеточия в именах файлов. Сюда входят Microsoft Windows и Novell Storage Services.

Но главный недостаток - это проблема масштабирования. Существуют неявные блокировки, используемые файловой системой при обновлении каталогов. Некластерные файловые системы обычно позволяют только одному потоку выполнения ядра в любой момент времени обновлять данные о том, что находится в каталоге, поэтому системный вызов rename() обеспечит необходимую блокировку. Maildir не является системой без блокировок (lock-free), только без явных блокировок (explicit-lock-free). Для многих почтовых систем размером от маленьких до средних это адекватно масштабируется даже на NFS, но когда система становится большой и обрабатывает множество параллельных доставок, постоянное изменение содержимого многих каталогов одновременно будет постоянно приводить к недействительности данных кеша (cache invalidation) разных NFS-клиентов, поэтому нужно будет повторно производить удалённые вызовы процедур (RPC) READDIR, что плохо масштабируется.

Собственно по этой причине ряд разработчиков предприняли усилия по разработке собственных форматов.

Примером может служить собственный формат dbox от Dovecot. В формате dbox почтовые сообщения хранятся в одном или нескольких файлах, каждый из которых может содержать одно или более сообщений.

Следующим собственным форматом является Mailstore, созданный компанией exim. Каждое сообщение записывается в виде двух уникальных имен файлов, заканчивающихся на .env и .msg. Файл .env содержит конверт сообщения, а файл .msg содержит само сообщение. При доставке электронного письма заголовок электронного письма создается с суффиксом .tmp, а сообщение создается с помощью .msg. Когда файл .msg будет завершен, файл .tmp будет переименован в env. Программы, желающие получить доступ к электронной почте, должны дождаться наличия обоих файлов или отсутствия файла .tmp.

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

Вот почему для систем относительно небольшого масштаба (примерно до 1-2 тысяч пользователей) мы рекомендуем наши редакции с системой хранения maildir - это Tegu Freware и Tegu Professional . Они удобны тем, что разворачиваются на одной ноде, которая является и вычислительной, и системой хранения на собственном (или NFS) диске.

Однако для системы с большим количеством пользователей (более 2 тысяч пользователей) мы рекомендуем флагманскую версию Tegu Enterprise , в которой мы полностью отказались от файлового хранилища в пользу СУБД PostgreSQL .

В качестве СУБД нами выбрана Postgres (далее PG). И весьма неслучайно. Дело в том, что ванильная версия распространяется под лицензией PostgreSQL License, являющейся пермиссивной (разрешительной) такой же как BSD или MIT. Но при этом одним из семи основных центров разработки PostgreSQL находится у нас в России - это компания - Постгрес Профессиональный https://postgrespro.ru/ . Компанию возглавляют люди, которые находились у самых истоков разработки продукта. Этот факт дает уверенность в качестве, надежности и отечественности продукта, что крайне немаловажно при выборе стратегического партнера.

Функциональность же Postgres выше всяческих похвал - именно благодаря этому Tegu обладает рядом конкурентных отличий и уникальных свойств. И теперь самое время этими строками сказать спасибо нашим коллегам.

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