Кратко

  • RFC 2368 расширил mailto: получателями, заголовками и коротким телом в простом тексте, но разрешение URL не требовало немедленного сетевого взаимодействия.
  • Клиент мог отбросить опасные поля и должен был показать полностью декодированное письмо до запроса согласия; ссылка, щелчок и заполненный черновик не подтверждали отправку или доставку.

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

RFC 1738 задавал простую форму с адресом. RFC 2368 добавил список почтовых ящиков и пары имени и значения после ?, разделённые &. Особое имя body задавало первую часть text/plain. Страница могла подготовить подписку на рассылку, запрос информационному роботу, ответ архиву или письмо с копией, избавляя читателя от ручного ввода.

Удобство не объединяло владельцев истины. Издатель управлял исходным URL. Парсер превращал экранированные октеты в адреса и поля. Почтовый клиент применял местную политику. Пользователь видел результат и принимал решение. Сервер отправки, транспорт и удалённый ящик создавали свои факты позже. Предыдущая стадия не могла выдать квитанцию за следующую.

Кодирование было частью границы управления. Знаки ?, = и & определяли структуру, поэтому в данных требовали процентного кодирования. Пробел становился %20, перевод строки %0D%0A, буквальный процент %25. В HTML разделитель & записывался как &. Исходный документ, разобранный URL и показанный черновик были разными представлениями. Ошибка порядка или двойное декодирование могли изменить адресата либо границы полей.

Документ показывал ограничения интернационализации 1998 года. Некодированные восьмибитные символы запрещались. MIME encoded-word допускался в значениях заголовков, но не в body. Подстановки переменных не было: статическая ссылка не могла надёжно вставить адрес щёлкнувшего пользователя или сформировать подпись из локальных данных. Это был ограниченный шаблон, а не программа.

Широкая грамматика не обязывала клиент исполнять каждое поле. При опасном заголовке он мог отказаться от создания письма либо оставить безопасное подмножество. Subject, Keywords и Body считались полезными; From, Bcc, маршрутизация и ряд MIME-полей вызывали особое подозрение. Синтаксическая возможность не давала внешнему документу власть над личностью отправителя или скрытым адресатом.

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

Поэтому доказательства идут ступенями. Наличие URL подтверждает предложение шаблона. Щелчок подтверждает максимум активацию. Черновик показывает, какие поля принял клиент. Решение отправить, приём сервером, доставка, чтение и выполнение команды требуют отдельных записей.

RFC 6068 заменил спецификацию в 2010 году, добавив UTF-8 перед процентным кодированием и уточнив повторы и безопасность. Главная пауза сохранилась: URI оставался шаблоном сообщения. Верные символы не были согласием, а согласие не было доказательством доставки.

Историческое значение RFC 2368 — в сдержанной автоматизации. Внешний документ мог сократить набор текста, но не получал права говорить от имени человека.

Источники