Кратко

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

Адрес электронной почты мог вести не только в почтовый ящик. В модели RFC 3965 он мог указывать и на выходной факсимильный шлюз: программную систему, которая получала письмо, а затем набирала номер аппарата Group 3. В одном маршруте соединялись два разных действия: передача почты через Интернет и телефонный вызов, способный расходовать ресурсы и деньги.

Из-за этой границы привычный жест мог иметь неожиданное последствие. Получатель, выбравший «ответить всем», мог направить новое письмо тому же факсимильному шлюзу, который стоял среди первоначальных адресатов. Если шлюз повторно использовал разрешение прежнего отправителя, ответ мог вызвать ещё один звонок, хотя написал его не тот человек, который разрешил первую отправку. RFC приводит это как безобидный пример повторного использования. Это модель угроз, а не сообщение о реально повторно отправленном факсе или взломанной системе.

Различие начинается с полей, поступающих на шлюз. RFC указывает, что номер и ссылка на узел выходного шлюза должны находиться в транспортных полях электронной почты, например в SMTP RCPT TO. Локальную часть адреса интерпретирует агент передачи почты, указанный доменом. Поэтому шлюз — не просто контакт, скопированный из адресной книги факса. Именно служба решает, может ли письмо стать телефонным вызовом. Шлюз для многих пользователей может работать как MTA, а для одного получателя — скорее как пользовательский агент.

Видимый адрес не доказывает, кто составил сообщение. RFC предупреждает: фактический отправитель может отличаться от значений From или Sender в заголовке письма и от MAIL FROM в конверте SMTP. SMTP сам по себе не удостоверяет автора. Шлюз может аутентифицировать источник и проверить собственную таблицу разрешений либо фильтровать по исходному узлу или сети. Но документ отмечает, что стандартного способа авторизации для этой службы средствами интернет-протоколов не существовало. Он определяет границу контроля, а не общепринятый межсистемный токен.

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

На этой же границе возникал риск раскрытия другой информации. Данные для телефонного вызова — например, номер авторизации телефонной карты — могли передаваться в параметрах адреса и печататься на титульном листе факса. RFC рекомендует предоставить отправителю способ предотвратить такое раскрытие, но отмечает, что стандартных механизмов защиты тогда не было. Получателю также следует передавать достаточно сведений для отслеживания источника; одних From или MAIL FROM недостаточно. Авторизация, конфиденциальность и подотчётность связаны, но не заменяют друг друга.

Уведомления об ошибках тоже относятся к разным этапам. При сбое SMTP-реле требуется сформировать сообщение об ошибке, предпочтительно в формате уведомления о статусе доставки (DSN). Неспособность устройства обработать TIFF — отдельный сбой, порядок уведомления о котором определяется локально. Успешная передача письма не доказывает, что факс был распечатан, прочитан или принят человеком; возвратное уведомление также не показывает конечный результат на факсимильном аппарате. Спецификация описывает этапы, но не объединяет их в одну сквозную квитанцию.

Историческое значение RFC 3965 в том, что он сделал видимым разрыв между перепиской и правом на действие: список адресатов может сохраниться, а полномочие у каждого нового письма — измениться. Осторожный шлюз не должен выводить право на звонок из того, что адрес факса просто скопировали. Нужно определить, чьё разрешение применяется к какому сообщению. RFC фиксирует эту проблему проектирования, но не измеряет её частоту или распространённость конкретных решений.

Источники: RFC 3965, RFC 2305, RFC 3191, RFC 3192, RFC 3461, RFC 3464, RFC 5321, RFC 5322, RFC 3949, RFC 2306.