Кратко
- RFC 2298, опубликованный в марте 1998 года, разрешил отправителю указывать
Disposition-Notification-Toдля запроса отчёта о судьбе письма. Почтовая программа получателя могла тихо проигнорировать просьбу либо в исходном формате ответитьdenied. - Отчёт называл действие программы: показ, отправку дальше, обработку или удаление. Документ настоятельно рекомендовал согласие пользователя и допускал не более одного отчёта на получателя и письмо. RFC 3798 в 2004 году удалил редко применявшиеся
deniedиfailed.
Бумажка в электронном конверте
Представьте офис конца девяностых. Сотрудник отправляет сообщение, а затем хочет узнать, увидели ли его на другом конце. Почтовая программа добавляет в заголовок Disposition-Notification-To и адрес для ответа. Письмо попадает в чужой ящик. Дальше вступают в силу настройки чужой программы и воля другого человека. Отправитель сформулировал просьбу, но кнопку ответа он у себя не держит.
RFC 2298 определил формат Message Disposition Notification — MDN. Во втором разделе заголовок прямо назван запросом. Агент получателя вправе оставить его без ответа. В первом варианте был и статус denied: явный отказ раскрывать, что произошло с письмом. Авторы настоятельно рекомендовали получать согласие пользователя перед отправкой уведомления. Это мог быть отдельный вопрос для каждого письма или сохранённая настройка. У чужого ящика появлялась процедура для вежливого «да», «нет» и молчания.
Привычное название «уведомление о прочтении» шире того, что фиксировала машина. Displayed означало, что программа показала письмо человеку, открывшему ящик. Dispatched охватывало печать или пересылку. Processed могло означать обработку правилом или сервером. Deleted означало удаление. Определения RFC перечисляли действия системы. Внимание и понимание живут у читателя; у программы есть запись о показе.
Дополнительные поля уточняли происхождение отчёта. Одно различало ручное действие и автоматическое. Другое различало разрешение пользователя на этот конкретный отчёт и отправку по заранее установленному правилу. Два одинаковых displayed могли скрывать разные локальные пути. Если отправителю нужна была точность, короткое зелёное уведомление требовало чтения всех полей.
Чтобы автоматизация не размножалась сама собой, RFC ограничил число ответов. От имени каждого получателя агент мог выдать максимум одну MDN на исходное письмо. Сам отчёт не имел права просить отчёт о себе; получение MDN также не запускало новую MDN. Иначе два почтовых клиента могли бы бесконечно обмениваться расписками о получении расписок. Этот комический сценарий при большой нагрузке быстро перестал бы быть смешным.
Другая опасность скрывалась в адресе ответа. Отправитель мог указать адрес постороннего человека и разослать множество писем, заставив чужие ящики засыпать этого человека уведомлениями. RFC рекомендовал сверять Disposition-Notification-To с Return-Path. Несовпадение, отсутствие обратного адреса или несколько разных целей требовали подтверждения пользователя либо отказа от автоматического ответа. Текст прямо упоминал почтовые петли и почтовую бомбардировку. Вежливый вопрос нуждался в защите от подмены адресата.
В результате роли распределялись по сторонам линии. Отправитель просил. Агент получателя сверял адреса, правила и локальные настройки. Пользователь разрешал ответ или сохранял тишину. Если отчёт уходил, он описывал конкретное событие обработки. Факт доставки сам по себе оставлял получателю право распоряжаться следующим шагом.
Историческая насмешка появилась в следующей редакции. RFC 3798 заменил исходный документ в мае 2004 года и убрал denied и failed, поскольку они не получили заметного применения или реализации. Формальный штамп отказа исчез. Возможность ничего не посылать сохранилась. Отправитель мог лишиться официального «нет» и всё равно стоять перед закрытой дверью.
Небольшой протокол оказался разговором о власти над чужим почтовым ящиком. Система могла сообщить, что вывела письмо на экран, обработала или удалила его. Решение послать этот отчёт принималось на стороне получателя. Строка в заголовке долетала далеко, но ключ от ящика с собой не приносила.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров





