Кратко

  • Открытое письмо Apache от 2 сентября 2004 года объявило тогдашние условия бесплатной патентной лицензии Microsoft препятствием для реализации Sender ID в SpamAssassin и JAMES. Фонд указывал на передачу прав последующим распространителям и требование обращаться к правообладателю.
  • RFC 4406 2006 года зафиксировал отсутствие общего технического согласия между Sender ID и SPF и риск потери добросовестной почты. Обзор IETF 2012 года показал широкое применение SPF и слабое внедрение Sender ID; в 2020 году документы Sender ID получили статус Historic.

В одном письме несколько имён отправителя

Человек видит адрес в поле From. Почтовые серверы во время SMTP-обмена используют MAIL FROM и имя из EHLO. Пересылка способна разорвать связь между видимым адресом и сервером, который доставил сообщение дальше. Когда владелец домена публикует в DNS перечень машин, которым разрешено посылать почту от его имени, принимающая сторона должна сначала выбрать, к какому имени относится разрешение.

Устав рабочей группы MARID перечислял From, Sender, MAIL FROM и EHLO, а выбор идентификатора называл первым делом группы. Sender ID применял алгоритм PRA к заголовкам сообщения, чтобы определить предполагаемый ответственный адрес. SPF проверял идентификатор SMTP-транзакции. Публикация правил в одной системе DNS скрывала расхождение в предмете проверки.

Нулевая цена лицензии оставила контроль над передачей

В сентябрьском письме Apache заявила, что действовавшее предложение Microsoft несовместимо с Apache License 2.0. Её решение было практическим: фильтр SpamAssassin и почтовый сервер JAMES не будут реализовывать либо внедрять Sender ID на этих условиях.

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

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

Две RFC и предупреждение о потерянном письме

В апреле 2006 года IETF опубликовала Sender ID и SPF одновременно, в категории Experimental. Примечание IESG сообщало, что общего технического консенсуса нет, а попытки объединить подходы не удались. Там же говорилось, что получатель Sender ID может применить свою логику к записи DNS, подготовленной для SPF, и отбросить действительное письмо. Автоматическая пересылка и заголовки Resent-* создавали ещё один источник несовместимости.

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

Обзор экспериментов 2012 года обнаружил широкое распространение SPF и слабое использование PRA и SUBMITTER, важных частей Sender ID. Реализации обоих подходов существовали; IETF прямо указала, что нехватка программ не определила выбор. Обзор сопоставлял наблюдаемое внедрение, а не присуждал одному алгоритму звание безусловно правильного. В 2014 году SPF перешёл на путь стандартизации. В феврале 2020 года RFC 4405, 4406 и 4407 были переведены в Historic.

Решение Apache закрыло в 2004 году конкретный путь поставки кода. Позднейший итог описал выбор множества почтовых операторов. Между ними осталось техническое предупреждение 2006 года: разрешение, записанное в DNS, не поможет, если стороны проверяют по нему разных «отправителей».