Кратко

  • APNIC намечает на третий квартал 2026 года постоянный учёт всех адресов IRT и проверку их действительности при входе вместо статического признака блокировки учётной записи.
  • Проект меняет источник и момент решения о доступе. В открытых материалах нет указания, что он отменяет шестимесячный цикл, отметку Invalid через 15 дней или ограничение MyAPNIC через 30 дней.
  • Адрес, проверочный запрос, объект IRT, область учётной записи и решение при входе — разные состояния. Один булев признак не сохраняет происхождение результата.
  • Конфиденциальный протокол решения мог бы фиксировать версии состояний, сроки, правило агрегации и источник ответа, не раскрывая адрес или проверочный код.

Решение должно встретиться с актуальным доказательством

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

APNIC не заявляет, что подобное произошло с конкретным участником. Публичная дорожная карта описывает предотвращаемый риск: учётные записи не должны оставаться ошибочно заблокированными или разблокированными. Предложенное решение — непрерывно отслеживать все адреса IRT и проверять их при входе вместо статического признака. Работу ведёт команда Membership для APNIC Login и Whois, целевой срок — Q3 2026.

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

Однако дорожная карта не раскрывает окончательную модель, дату запуска, правило для нескольких объектов IRT или нескольких адресов. Она также не говорит о завершённом внедрении. Поэтому слово «текущее» требует точного набора входных данных, времени и версии правила.

У действующей политики три отдельных срока

prop-125 отмечено APNIC как внедрённое предложение. Действующая политика номерных ресурсов требует объект IRT для каждой ресурсной записи. Адреса email и abuse-mailbox должны контролироваться, а поступившие жалобы — получать своевременный ответ.

Проверка содержит три временных рубежа. Контакты проверяются периодически или раз в шесть месяцев. Владелец учётной записи имеет 15 дней после письма; при неудаче объект IRT получает отметку Invalid в Whois. Если через 30 дней проверка всё ещё не пройдена, доступ к MyAPNIC ограничивается до её завершения.

Объявление 2019 года датирует начало режима 30 июня. Форма проверки просит ввести уникальный код из письма. Завершение подтверждает доступ к сообщению в момент испытания.

Ничто в дорожной карте не отменяет эти сроки. Шесть месяцев определяют необходимость нового доказательства, 15 дней — видимый статус объекта, 30 дней — последствие для портала. Вход является моментом чтения результата, а не заменой правил, которые его сформировали.

Поэтому объяснимое ограничение должно называть причину: истёкший запрос, переход 15- или 30-дневной границы, изменение объекта, состояние другого адреса либо чтение старой версии. Более свежий результат без основания остаётся непрозрачным.

За одним флагом скрываются пять состояний

Адрес электронной почты имеет чувствительное значение и историю. Проверочный запрос — время выпуска, доставки, окончания и результата. Объект IRT — ключ, версию и набор атрибутов. Руководство APNIC различает e-mail и abuse-mailbox, а mnt-by указывает сопровождающего, уполномоченного изменять объект.

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

Эти сущности связаны, но не тождественны. Проверка одного адреса не проверяет второй. Редактирование объекта может изменить применимый контакт. Одна учётная запись может быть связана с несколькими IRT через разные ресурсы. Верное решение устаревает после нового события.

Непрерывное отслеживание полезно только при явных связях. APNIC Login должен знать, какие объекты и атрибуты входят в область, каким событием создано каждое состояние и какое правило объединяет результаты. Иначе непрозрачный статический признак сменится непрозрачным запросом в реальном времени.

Главный вопрос — как объединять несколько адресов

Если в объекте два адреса для жалоб и один общий адрес, должны ли действовать все три? Достаточно ли одного действительного abuse-mailbox? Распространяется ли одна проверка общего адреса на все объекты, где он указан? Если связанные с ресурсами объекты расходятся, ограничивается вся учётная запись, отдельная функция или только соответствующий ресурс?

Открытая информация не даёт ответов, поэтому нельзя приписывать их APNIC. Но требование очевидно: выбранное правило должно иметь имя и версию. Фразу «проверено при входе» можно воспроизвести лишь при известном наборе и способе объединения.

Исходное событие и производный вывод следует хранить раздельно. Событие говорит, что запрос для идентификатора адреса завершён в указанное время. Состояние определяет период действия. Оценка IRT перечисляет рассмотренные состояния. Решение учётной записи ссылается на оценку и версию правила. Исправление тогда заменяет вывод, не уничтожая прежних фактов.

Это ускоряет диагностику. Если проверка завершилась в 10:04, а вход в 10:05 остался ограничен, причиной может быть задержка распространения, другой просроченный адрес или иная область. Это разные инциденты с разными владельцами.

Контроль почтового ящика не доказывает работу с жалобами

Цель prop-125 — обеспечить доступность команд, отвечающих за сетевые злоупотребления. Но ввод кода показывает только то, что обладатель доступа к сообщению завершил запрос. Он не доказывает, что будущие жалобы попадут в нужную очередь, пройдут фильтры, будут прочитаны и приведут к исправлению.

Истечение запроса, в свою очередь, не доказывает отсутствия ящика или игнорирования конкретной жалобы. Доставка, доступ, наблюдение, разбор и решение — разные факты.

Граница защищает обе стороны. Действительный статус не является гарантией качественной обработки для заявителя. Пропущенный срок не является выводом о злоупотреблении со стороны участника. Ограничение MyAPNIC — мера управления доступом, а не судебное решение, отзыв ресурсов или оценка поведения сети.

Протокол источника решения

APNIC могла бы сопровождать новую проверку протоколом решения о доступе IRT. Это редакционная рекомендация, а не опубликованное обязательство APNIC. Протокол скрывает адрес и код, но содержит:

  • время и конфиденциальную ссылку на учётную запись;
  • ключи и версии рассмотренных объектов IRT;
  • маскированные или хешированные идентификаторы адресов;
  • последнее успешное событие, состояние и время вступления в силу;
  • даты шести месяцев, 15 и 30 дней;
  • версии правил области, агрегации и политики;
  • точный снимок, прочитанный APNIC Login;
  • результат, типизированную причину и источник решения;
  • ссылки на проверку, исправление и последующее решение.

Источник решения позволит в переходный период отличить живую оценку IRT от результата старого признака. Два пути можно считать параллельно, объяснять расхождения и отключить прежний только после уменьшения необъяснимых различий.

Представления могут различаться. Участник видит маскированные контакты и сроки, поддержка — дополнительные ссылки на события, внешняя сторона — при необходимости лишь отпечаток протокола и тип статуса. Проверяемость не требует публикации адреса.

Источники