Кратко

  • RFC 1703, опубликованный в октябре 1994 года, описал передачу интернет-почты на сервер радиопейджинга. Положительные ответы на RCPT и DATA удостоверяли разные события в зависимости от первого SMTP-командного слова: MAIL, SEND, SOML или SAML.
  • Прямое SMTP-соединение клиента с сервером в один переход вместе с SEND или SAML позволяло считать положительный ответ подтверждением отправки сообщения по радиосети. Граница подтверждения проходит по действию сети.

У зеленой лампочки оказался мелкий шрифт

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

Marshall Rose предложил искать ответ в команде SMTP. Сервер радиопейджинга обязан поддерживать MAIL, а SEND, SOML, SAML может поддерживать по выбору. Смысл положительной пары ответов на RCPT и DATA меняется в зависимости от этой команды. Для MAIL минимальный результат — сообщение поставлено в очередь на передачу в радиосеть. Сотрудник приемной уже расписался; посыльный еще не вышел.

Команда SEND закрепляла следующий этап: радиосеть приняла сообщение для доставки адресату. При SOML и SAML формулировка RFC осторожнее: положительный ответ может означать такое принятие сетью. Это не стилистическая прихоть. Одинаковый на вид код отвечает на разные вопросы, а вопрос задается первым глаголом в сеансе. Журнал, где хранится только финальное «OK», теряет смысл квитанции.

Адрес строился из телефонного номера: цифры превращались в метки DNS под tpc.int, MX-запись направляла почту к серверу, готовому попытаться обслужить номер. Подстановочная MX-запись охватывала диапазон; она говорила о готовности попробовать, а не о наличии пейджера по каждой цифре. Этот механизм вырос из принципов TPC.INT в RFC 1530. Он помогал найти дверь, за которой RFC 1703 уточнял значение ответа.

Само устройство накладывало ограничения на содержание. Для pager-numeric тело сообщения состояло только из цифр. Формы pager. и pager-alpha. относились к буквенно-цифровым услугам. Почтовый конверт был универсальнее аппарата, поэтому шлюз должен был подготовить запрос к возможностям конкретной радиослужбы. Значение слова «передано» начиналось с этого практического перевода.

Почтовый маршрут добавлял свою неопределенность. Ретрансляторы и шлюзы могли хранить письмо перед очередной пересылкой; RFC перечислял задержки в минуты, часы или дни. Для вызова, привязанного ко времени, маршрут превращался в лотерею ожидания. Rose описал прямое соединение IP/SMTP от клиента к серверу радиопейджинга: всего один SMTP-переход. Промежуточные почтовые очереди исчезали из пути подачи запроса.

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

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