Message Disposition Notification

Message Disposition Notification (MDN, также известное как «уведомление о состоянии доставки» или «уведомление о диспозиции сообщения») — это стандартизированный протокол электронной почты, позволяющий отправителю запросить и получить автоматическое уведомление о том, что произошло с отправленным письмом после его успешной доставки на почтовый сервер получателя. В отличие от уведомлений о недоставке (bounce messages), MDN информирует не о сбоях, а о статусе обработки сообщения получателем: прочитано ли оно, удалено без прочтения или отклонено. Стандарт определён в RFC 3798 (Internet Message Format — Message Disposition Notification), опубликованном IETF в 2004 году, и расширяет функциональность протокола SMTP.

История и стандартизация

Потребность в механизме подтверждения получения и прочтения электронных писем возникла по мере развития деловой переписки. В ранних версиях SMTP (RFC 821, 1982) не было встроенных средств для отслеживания судьбы сообщения после его доставки. В 1990-х годах появились проприетарные решения (например, в Microsoft Exchange), но они не были совместимы между разными почтовыми системами.

Работа над стандартизацией началась в конце 1990-х годов. В 2000 году был опубликован проект RFC 2298, который после доработки стал RFC 3798. Этот стандарт определил формат MDN-уведомлений, их заголовки и механизмы запроса. В 2010-х годах, с ростом популярности веб-почты и мобильных клиентов, поддержка MDN стала шире, но остаётся опциональной. В России MDN часто называют «уведомлением о прочтении» (read receipt), хотя технически оно охватывает и другие состояния.

Принцип работы

MDN основан на механизме, при котором отправитель указывает в заголовке письма специальный параметр, а почтовый клиент получателя (при условии поддержки) генерирует и отправляет обратно отправителю автоматическое сообщение с информацией о статусе обработки.

Запрос уведомления

Отправитель включает в заголовок письма поле Disposition-Notification-To с адресом электронной почты, на который должно быть отправлено уведомление. Например: Disposition-Notification-To: sender@example.com

Это поле может быть добавлено как почтовым клиентом отправителя (например, при установке флажка «Запросить уведомление о прочтении»), так и вручную. RFC 3798 рекомендует, чтобы почтовые клиенты запрашивали согласие получателя перед отправкой MDN, но на практике многие клиенты (особенно веб-сервисы) игнорируют этот запрос.

Формирование уведомления

При обработке письма почтовый клиент получателя (MUA — Mail User Agent) анализирует заголовок Disposition-Notification-To. Если поддержка включена и получатель не запретил отправку уведомлений, клиент генерирует новое письмо со следующими характеристиками:

• Тип содержимого: message/disposition-notification (зарегистрирован в IANA).
• Заголовки: включает оригинальные заголовки письма (например, Message-ID, From, Subject) для идентификации.
• Тело: структурированный текст в формате MIME, содержащий поля:
• Disposition — статус обработки (например, displayed — прочитано, deleted — удалено, processed — обработано автоматически).
• Original-Message-ID — идентификатор исходного письма.
• Final-Recipient — адрес получателя (может отличаться от исходного при пересылке).
• Error — в случае сбоя (например, unsupported — неподдерживаемый формат).

Уведомление отправляется на адрес, указанный в Disposition-Notification-To, как обычное SMTP-сообщение.

Обработка отправителем

Почтовый клиент отправителя (или сервер) принимает MDN и сопоставляет его с исходным письмом по Original-Message-ID. В зависимости от реализации, отправитель может увидеть статус в интерфейсе (например, галочку «Прочитано» в некоторых сервисах). MDN не гарантирует, что письмо было прочитано человеком — только что оно было обработано клиентом.

Виды уведомлений

Стандарт RFC 3798 определяет несколько типов диспозиции, которые могут быть указаны в поле Disposition:

• displayed — сообщение было открыто (показано пользователю). Это наиболее распространённый тип, часто называемый «уведомлением о прочтении».
• deleted — сообщение было удалено без прочтения (например, пользователь переместил его в корзину).
• processed — сообщение было обработано автоматически (например, почтовым фильтром или роботом).
• denied — получатель отказался от отправки уведомления (клиент может вернуть этот статус вместо молчания).
• failed — обработка не удалась (например, из-за ошибки в клиенте).
• warning — предупреждение о возможных проблемах (например, слишком большой размер письма).

Также возможны комбинации, например, displayed/deleted (прочитано, затем удалено).

Применение

MDN используется в различных сценариях, где требуется подтверждение обработки сообщения:

• Деловая переписка: компании запрашивают уведомления о прочтении для подтверждения получения важных документов (договоров, отчётов). В России это распространено в корпоративных почтовых системах (например, Microsoft Exchange, CommuniGate Pro).
• Автоматизированные системы: почтовые роботы (например, для подтверждения регистрации) могут использовать MDN для отслеживания, что письмо было обработано.
• Электронные рассылки: маркетологи иногда запрашивают MDN, чтобы оценить процент открытий, хотя это менее надёжно, чем трекинг с помощью пикселей.
• Государственные и муниципальные структуры: в некоторых странах (включая Россию) MDN используется для подтверждения получения официальных уведомлений в электронном виде.

Ограничения и критика

MDN имеет ряд недостатков, которые ограничивают его применение:

• Необязательность: получатель может отключить отправку уведомлений в настройках почтового клиента. Большинство веб-почтовых сервисов (Gmail, Яндекс.Почта, Mail.ru) по умолчанию игнорируют запросы MDN или запрашивают согласие пользователя, что снижает практическую ценность.
• Конфиденциальность: MDN раскрывает факт обработки письма, что может нарушать приватность получателя. Стандарт рекомендует запрашивать согласие, но на практике это часто игнорируется.
• Спам: злоумышленники могут использовать MDN для проверки существования адреса (верификация), что приводит к увеличению спама. Поле Disposition-Notification-To может быть подделано.
• Ненадёжность: MDN не гарантирует, что письмо было прочитано человеком — только что оно было отображено в клиенте. Автоматические фильтры или предпросмотр в списке писем могут вызвать ложное уведомление.
• Совместимость: не все почтовые клиенты поддерживают MDN. Например, некоторые мобильные приложения (Apple Mail на iOS) не генерируют уведомления, а другие (Outlook) требуют настройки.

Реализация в почтовых клиентах

Поддержка MDN варьируется в зависимости от почтового клиента:

• Microsoft Outlook: поддерживает запрос и отправку MDN. Пользователь может настроить автоматическую отправку уведомлений или запрос подтверждения.
• Mozilla Thunderbird: поддерживает MDN с возможностью запроса согласия получателя.
• Gmail: не поддерживает MDN в классическом интерфейсе. Уведомления о прочтении реализованы через собственный механизм (пиксель-трекинг), который несовместим со стандартом RFC 3798.
• Яндекс.Почта: не поддерживает MDN. Вместо этого используется трекинг открытий с помощью изображений.
• Mail.ru: аналогично — не поддерживает MDN, использует собственные методы.

Альтернативы

Из-за ограничений MDN в современных системах часто используются другие методы:

• Трекинг с помощью пикселей (web beacon): в письмо вставляется невидимое изображение, загрузка которого фиксируется сервером. Это позволяет отследить открытие, но не даёт информации о других действиях (удаление, обработка).
• Уведомления о доставке (DSN — Delivery Status Notification): стандарт RFC 3461, который информирует о доставке письма на почтовый сервер получателя, а не о его обработке клиентом.
• Собственные протоколы (например, в Microsoft Exchange): корпоративные системы могут использовать проприетарные механизмы для отслеживания статуса.

В России, где распространены почтовые сервисы, не поддерживающие MDN, этот стандарт чаще всего используется в корпоративных средах с Microsoft Exchange или аналогичными системами.

Источники

• RFC 3798 — Message Disposition Notification (IETF, 2004).
• RFC 5321 — Simple Mail Transfer Protocol (IETF, 2008).
• RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (IETF, 2003).
• Книга: «Электронная почта и протоколы интернета» (М. В. Семёнов, 2015).
• Документация Microsoft Exchange Server по уведомлениям о прочтении (Microsoft Docs, 2023).