Кратко

  • RFC 5364 создаёт из одного раскрытого URI-списка отдельную историю для каждого адресата. Отсутствующий copyControl означает bcc; скрытые записи исчезают из чужих копий, а анонимизированные могут оставить фиктивный URI и число.
  • Повторяющийся URI должен получить не более одного запроса. Класс выбирается в порядке to, cc, bcc, а bcc отдельно имеет приоритет над anonymize. Сопоставление и раскрытие требуют разных квитанций.
  • recipient-list-history передаётся как необязательная часть и не доказывает существование адреса, достижимость, принятие, участие или начисление платы. Защита транспорта подтверждает сохранность, но не полноту или истинность проекции.

Защищённые байты могут описывать неверную картину

Списки адресатов раскрывают отношения, поэтому аутентификация, авторизация, TLS и S/MIME необходимы. Они ограничивают доступ и защищают канал либо содержимое в рамках своих моделей доверия.

Но эти механизмы не отвечают, взял ли relay правильную версию списка, применил ли правила сравнения URI, выбрал ли правильный класс среди дубликатов, соблюл ли приоритет bcc и верно ли посчитал анонимные записи.

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

Храните peer, сертификат или ключ, результат проверки и область защиты отдельно от hash входа, версии преобразователя, версии правил и hash каждой выходной истории.

Сохранность отвечает на вопрос, менялись ли байты в определённой цепочке. Семантическая квитанция отвечает, должны ли именно эти байты были быть созданы для именно этого наблюдателя.

Каждый адресат получает собственную проекцию

После раскрытия списка relay знает операционный набор URI, но не рассылает этот мастер-набор всем. Он строит recipient-list-history для каждого исходящего запроса.

Записи to и cc могут оставаться видимыми. bcc удаляется из копий других адресатов. В отдельной копии для самого скрытого адресата его URI может сохраниться как предупреждение о риске ответа всем.

Поэтому разные hash истории в одном fan-out не обязательно означают подмену. Нужны личность наблюдателя, правило, видимый набор, удалённый набор и анонимные заменители.

Свяжите исходный XML и hash, граф раскрытия, разрешённую классификацию, ID исходящего запроса и hash конкретного тела. Единая плоская таблица стирает доказательство того, кто кого видел.

Автор списка распоряжается входным заданием, relay отвечает за раскрытие, а конечный адресат получает ограниченную видимость. Эти поверхности нельзя называть общей ведомостью участников.

Молчание поля означает bcc

Если copyControl отсутствует, RFC 5364 назначает bcc. Старый формат, неполный генератор или потеря атрибута при миграции не дают разрешения показать URI.

Явное bcc и применённое по умолчанию дают одинаковую внешнюю проекцию, но разные диагнозы. Первое выражает намерение автора, второе фиксирует безопасную обработку неполного входа.

Сохраните исходные байты, hash, schema, факт присутствия атрибута, parser, правило default и итоговый класс. Если нормализация просто допишет bcc, источник пробела станет невосстановим.

При обновлении parser один и тот же fixture без атрибута должен оставаться скрытым. Регрессия default способна незаметно открыть многолетние списки.

Bcc и anonymize скрывают разные факты

bcc удаляет запись из историй остальных. anonymize=true может оставить заданный стандартом анонимный SIP-placeholder и count, представляющий несколько скрытых записей.

Во втором случае личность скрыта, но существование и размер группы раскрыты. Сведения о пяти анонимных получателях могут изменить решение участников даже без одного имени.

Если присутствуют обе инструкции, bcc сильнее anonymize. Анонимный placeholder в таком случае уже разглашает существование, которое blind-правило требовало убрать.

Проверяйте утечку идентичности и утечку численности отдельно. Записывайте исходные атрибуты, правило приоритета, полностью исключённый набор, анонимные группы, count и точное тело.

Единая метка «скрыто» в продукте не позволяет понять, какая информация всё-таки была раскрыта.

Дубликат выбирает не только адрес, но и видимость

Раскрытие вложенных списков может дать несколько записей, равных по правилам URI-схемы. Простое сравнение строк пропустит часть совпадений, а чрезмерная нормализация сольёт разные назначения.

Спецификация не видит разумной цели в нескольких запросах одному получателю. Должен уйти максимум один. При конфликте выигрывает to, затем cc, затем bcc.

Алгоритм «оставить первую строку» делает смысл зависимым от порядка. Двойная отправка может передать одному терминалу противоречивые истории. Это решение о раскрытии, а не нейтральная очистка.

Сохраняйте исходные формы, метод сравнения, группу коллизии, пути происхождения, все атрибуты, победивший класс и единственный request ID.

Опубликованный материал по RFC 5363 уже исследует общий fan-out, нормализацию и раздельные результаты. Здесь принадлежит более узкая граница: какая видимость выживает при совпадении идентичности.

Reply-all завершает или разрушает blind-политику

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

Если собственный URI отсутствует или отмечен как blind, пользовательский агент должен запретить либо ограничить коллективный ответ.

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

Сохраните полученное тело, результат parser, выбранную локальную identity, совпадение, состояние действия и реальные адреса отправленного ответа. Серверная квитанция не доказывает конфиденциальность endpoint.

Тест заканчивается на исходящем сообщении, а не на снимке выключенной кнопки.

Запрос может быть принят без истории

Тело получает disposition recipient-list-history и handling=optional. Старый endpoint может принять основной SIP-запрос и проигнорировать неизвестную multipart-часть.

Принятие запроса и потребление истории — разные факты. «Доставлено с историей» может означать лишь, что relay приложил байты. Оно не доказывает хранение, parsing, показ или применение правила ответа.

Сохраняйте MIME-структуру, boundary, disposition, параметр, возможности endpoint, результат разбора, отображение и fallback. Допустимое отбрасывание должно быть наблюдаемым событием.

Совместимость сохраняет доступность, но может убрать контекст приватности. Чувствительный сервис должен явно решить, допустим ли такой деградированный режим.

История не является ведомостью присутствия

RFC прямо говорит, что список не доказывает фактических участников. URI может не существовать, быть недостижимым, не ответить, отказаться или принадлежать автомату. Человек может войти под другой identity.

История не даёт основания для billing. Приглашение не равно потреблению, запрос не равен принятой сессии, видимая строка не измеряет длительность, ресурс или плательщика.

Историю можно spoof. Валидный XML подтверждает форму, а не социальную истину. Шифрование не меняет этот предел.

Endpoint response, аутентифицированное присоединение, media, длительность, ресурс и платёжное событие должны существовать как последующие отдельные квитанции. Их можно коррелировать, но нельзя заменять записью в истории.

История отвечает, какую проекцию приложили к запросу. Она не отвечает, кто реально присутствовал.

Проекционный журнал хранит и невидимое

Первая квитанция фиксирует submitter, авторизацию, XML и контекст. Вторая — граф раскрытия. Третья — сравнение URI и группы коллизий.

Четвёртая хранит явные значения, default-bcc, anonymize и приоритеты. Пятая связывает для каждого получателя видимые, исключённые и заменённые записи, count и hash тела с исходящим запросом.

Затем идут обработка optional-части, показ, защита reply-all, доставка, реальное участие и отдельный billing. У каждого этапа свой субъект и время.

Одна проекция не доказывает, что было правильно скрыто. Один мастер-список не доказывает, что было раскрыто. Нужны обе стороны и преобразование.

Проверять нужно точные тела по наблюдателям

Fixtures должны включать отсутствующий атрибут, to, cc, bcc, одиночную и групповую анонимизацию, совместные blind/anonymize, эквивалентные URI с конфликтом, личную копию blind-получателя, обычную видимую копию и старый клиент без обработки optional-части.

Для каждого случая проверяйте число запросов и точные байты всех историй. Затем проверяйте self-match, отображение и ответ. Системы attendance и billing не должны получать факт из членства в истории.

Подмените источник после авторизации, поменяйте порядок дубликатов, удалите атрибут, измените count, подделайте историю, снимите optional-часть и повторите старую проекцию. Каждый принятый путь обязан иметь объяснимую квитанцию.

Статус Proposed Standard с октября 2008 года и отсутствие совпадений на захваченной странице errata описывают документальный срез. Они не доказывают современную реализацию, внедрение или реальный инцидент.