요약

  • RFC 9873은 EPP 명령-응답 확장을 정의하여 연락처 객체에 하나의 추가 이메일 주소를 연결합니다.
  • 추가 값은 ASCII 또는 SMTPUTF8 국제화 메일이 될 수 있으며, 이 확장 내에서primary는 선호 주소를 식별합니다.
  • 빈addlEmail은 두 번째 주소를 제거하며, 이 제거 형식에서는primary가 반드시 있어서는 안 됩니다.

여기서의 권위는 좁고 구체적입니다. RFC 5730은 EPP 명령 및 응답 프레임워크를 제공하고, RFC 5733은 연락처 객체와 공개 처리 방식을 정의하며, RFC 9873은 추가 이메일 요소와 그 갱신 의미론을 더합니다. 연락처 공개 플래그가 적용되는 경우 두 이메일 필드 모두에 적용됩니다. 협상된 지원에는 전송상의 결과도 있습니다. 클라이언트와 서버는 ASCII 및 SMTPUTF8 형식을 모두 처리해야 하며, 메일을 주고받을 때 SMTPUTF8을 지원해야 합니다. RFC 6530과 RFC 6531이 이 국제화 메일 맥락을 설명합니다.

이 RFC는 데이터 모델과 프로토콜 동작을 확립합니다. 사서함 소유권을 검증하거나 전송을 보장할 수는 없습니다. SMTPUTF8 지원이 레지스트리나 등록 대행기관에 보편적으로 배포되었다는 것을 보여주지도 않습니다. 주소를 primary로 표시한다고 해서 모든 하류 레지스트리 워크플로가 자동으로 바뀌는 것은 아닙니다. 두 번째 주소가 모든 프라이버시, 어뷰즈 연락처 또는 도메인 이전 문제를 해결하지도 않습니다. 마지막으로, RFC 자체만으로는 채택, 성능, 인시던트 또는 특정 운영자의 배포에 대한 주장의 근거가 되지 않습니다.

이 경계가 중요한 이유는, 두 번째 필드가 단순한 프로토콜 상태일 뿐인데도 라우팅 약속처럼 보일 수 있기 때문입니다. 운영자는 유니코드 혼동성, 이메일 도메인 구문, 도달 가능성을 정책 통제로서 검증해야 하며, 그러한 검사가 EPP의 연락처 표현과 별개로 유지됨을 인식해야 합니다.

출처