Кратко

  • RFC 784 описала диспетчер почты на TOPS20: по таблице возможностей адресата он выбирал MTP через TCP, MTP через NCP, прежний FTP через NCP либо особый путь.
  • RFC 785 определила два файла на сообщение. Один хранил текст, второй — отправителя, маршруты получателей и ссылку на текст. Изменять можно было список оставшейся работы, сохраняя одно письмо.

Чтобы написать одно и то же четырём людям, достаточно одного текста и четырёх адресов. Некоторые старые почтовые программы делали четыре копии текста. Suzanne Sluizer и Jon Postel в июле 1981 года предложили поручить правки отдельной карточке. Их RFC 784 о реализации MTP на TOPS20 в ISI отделяла файл письма от файла с поручениями по доставке. Если дорога закрылась, черкали на карточке; письмо оставалось на столе.

Дороги были действительно разными. Авторы создавали программу на BLISS-10, которая должна была отправлять и принимать почту через TCP и прежний NCP, а также обмениваться ею с соседними почтовыми системами. Программы составления писем и сетевые приёмники создавали файлы в каталогах пользователей. Фоновый диспетчер распределял их по выходным каналам. Пользовательская версия могла попробовать отправить письмо сразу, когда канал свободен. Таблица возможностей каждого хоста показывала, понимает ли он MTP через TCP, MTP через NCP или старый способ FTP через NCP.

Ещё одна таблица отвечала за исключения, например путь к хостам в Англии через систему UCL.

Получателей одного письма можно было продвигать независимо. Контрольный файл содержал сведения для доставки и ссылку на второй файл с текстом и заголовком RFC 733. Обслуженного адресата диспетчер отмечал или удалял из рабочего списка. Если канал другого был недоступен, тот оставался в очереди. Текст читался для каждой попытки; позднее файл могли переименовать или удалить, закончив местную обработку. Менялось состояние поручений, а не слова отправителя. Перепечатывать письмо из-за каждого закрытого канала было бы странным делом даже для почтовой конторы.

В RFC 785 с определениями файлов карточка получила точный вид. Строка FILE: называла полный путь к тексту, FROM: указывала отправителя, а каждый TO: — ещё одного получателя. В другом файле лежали заголовок и тело сообщения. Авторы сравнили такую пару со старыми программами, которые делали N копий текста для N адресов в полях To, Cc и Bcc. Новый интерфейс начинался с двух файлов при любом числе имён. Видимый адресный заголовок и рабочий маршрут курьера выполняли разные обязанности.

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

Sluizer и Postel перечислили создаваемые компоненты, программы, которые надеялись приспособить, и таблицы, которые ещё предстояло завести. RFC 784 зафиксировала конкретный план реализации, а RFC 785 — подробный интерфейс файлов. Главный выигрыш виден уже в плане: один адрес мог выйти из очереди, другой — ждать своей дороги. Общий текст при этом оставался общим.

На столе лежит письмо. Рядом карточка, на которой записано, кому оно предназначено и через какую дверь уйдёт. В 1981 году двери назывались TCP, NCP и FTP поверх NCP. Закрытая дверь оставляла имя в списке; остальные адреса могли двигаться дальше. Два файла позволяли компьютеру работать как аккуратному сортировщику писем.