요약

  • SMTPUTF8은 SMTP 봉투의 메일박스 이름과 메시지 헤더를 UTF-8로 확장했지만, 각 서버가 그 기능을 광고한 이후에만 적용되었으며, 이를 지원하는 서버는 8BITMIME도 함께 광고해야 했습니다.
  • 도메인은 IDNA A-라벨로 표현할 수 있었지만, 비ASCII 로컬파트에는 일반적인 대응물이 없었습니다. 경로가 SMTPUTF8을 더 이상 지원하지 않을 때 정직한 선택은 책임 있는 제출 시점 변환, 다른 경로, 재시도 또는 실패였지, 만들어낸 메일박스가 아니었습니다.

익숙한 이름은 아직 주소가 아니었

MIME은 메일의 표시 이름과 제목에 ASCII 범위 밖의 문자를 담을 수 있게 했습니다. 독자는 자신의 문자로 된 사람 이름을 볼 수 있었지만, 꺾쇠 괄호 안의 실제 주소는 여전히 ASCII 문자열이었습니다.RFC 6530은 이 경계를 짚습니다. 표시 이름 속의 인코딩된 자료는 SMTP 봉투에는 보이지 않으며, 많은 목적에서 주소의 일부조차 아니라고 합니다.

국제화 도메인 이름은@의 오른쪽만 해결했습니다. IDNA는 유니코드 도메인을 DNS 조회에 적합한 ASCII A-라벨 형태로 표현할 수 있게 했습니다. 왼쪽의 메일박스 로컬파트는 여전히 최종 배달 시스템의 명명 규칙에 속했고, 전통적 SMTP에서는 ASCII로 남았습니다.

이 비대칭이 중요한 이유는 도메인에는 표준화된 변환이 있지만 로컬파트에는 그렇지 않기 때문입니다. 음역, 정규화 또는 라틴 철자로의 대체는 어느 메일박스도 가리키지 않거나—다른 사람의 메일박스를 가리킬 수 있습니다. 따라서 주소 전체를 익숙하게 만드는 것은 새로운 조판 이상을 요구했습니다. 명명된 그대로 수신지를 보존할 수 있는 경로가 필요했습니다.

표준 트랙 설계는 유혹적인 지름길을 버렸

이 작업은 먼저 실험적 단계를 거쳤습니다. RFC 6530은 RFC 4952를 대체하면서, 실험적 전송 중 다운그레이드 명세들이 무관해졌으며 Historic으로 이동해야 한다고 기록했습니다. 그 교훈은 아키텍처적이었습니다. 중간의 릴레이는 국제화된 메일박스를 위한 ASCII 신원을 만들어낼 만큼의 권한을 갖지 못한다는 것이었습니다.

2012년 2월에 발표된 표준 트랙 문서군은 책임을 나누었습니다. RFC 6530은 프레임워크를 제공했습니다.RFC 6531은 SMTP 확장을 정의했습니다.RFC 6532는 적절한 메시지 헤더 값에 직접 UTF-8을 허용했습니다.RFC 6533은 배달 및 처리 통지를 확장하여 원래의 국제화된 수신자가 보고서 속에서 살아남도록 했습니다.

이것은 보편적 번역표가 아니었습니다. 전송, 구문, 배달, 실패 증거가 같은 주소에 대해 합의하는 조율된 환경이었습니다.

하나의 EHLO 토큰이 진지한 주장을 했

기능 키워드는SMTPUTF8입니다.IANA SMTP 서비스 확장 레지스트리는 이를 국제화 이메일 주소 지원으로 기록하며 EHLO 매개변수를 두지 않습니다.

매개변수가 없다고 해서 그 약속이 모호해지지 않습니다. RFC 6531은 SMTPUTF8을 광고하는 서버가 그 명세 버전을 완전히 준수해야 한다고 말합니다. 기본 SMTP 문법이 메일박스를 허용하는 어디에서든 UTF-8을 받아들여야 합니다. 또한8BITMIME을 지원하고 광고해야 합니다.

이 의존성이 이전 역사가 여전히 관련되지만 불충분한 이유를 설명합니다. 8BITMIME은 SMTP의 행 프레이밍 아래에서 MIME 본문의 상위 비트 옥텟을 허가합니다. SMTPUTF8은 송신자, 수신자, 메시지 관계를 명명하는 봉투와 헤더를 확장합니다. 서버는 자신의 UTF-8 헤더를 운반하는 경로가 8비트 클린하지 않은 상태에서 후자를 책임 있게 제공할 수 없습니다.

MAIL은 그 신원에 확장이 필요하다고 선언했

RFC 6531은MAIL FROM에 값이 없는 선택적SMTPUTF8매개변수를 추가합니다. 그 존재는 클라이언트가 확장을 이해하며, 봉투에 비ASCII 주소가 포함되어 있거나, 메시지가 국제화되어 있거나, 일부가 SMTPUTF8 지원을 필요로 함을 말합니다.

reverse-path와 forward-path 규칙은 이어서 메일박스 이름에 UTF-8을 허용합니다. 기본 구분자는 사라지지 않습니다.@, quoted-string 경계 및 기타 SMTP 구문은 자신의 역할을 유지하고, 허용되는 문자 레퍼토리만 확대됩니다.

도메인은 여전히 DNS를 위해 IDNA 규칙을 통과합니다. 유니코드 U-라벨은 A-라벨로 처리될 수 있습니다. 그 변환은 도메인에 관한 것입니다. 그것을 로컬파트에 ASCII 대응물이 있다는 증거로 인용해서는 안 됩니다.

경로가 도달 가능성의 일부가 되었

서버가 SMTPUTF8을 광고한 후에는 클라이언트가 국제화된 메일박스 이름과 UTF-8 헤더를 보낼 수 있습니다. 광고가 없다면, 국제화된 주소나 RFC 6532 헤더—그 헤더가 중첩된 MIME 구조 안에 있을 때에도—를 보내서는 안 됩니다.

그 결과는 드물지만 정확합니다. 같은 이름의 메일박스가 한 MX 경로로는 도달 가능하고 기능이 다른 다른 경로로는 일시적으로 도달 불가능할 수 있습니다. 대체 MX가 도움이 될 수 있고, 재시도가 수리된 경로를 찾을 수 있습니다. 어느 행위도 주소가 바뀌었다는 증거가 아닙니다. 경로는 그 이름을 충실히 운반하기 위한 전제 조건입니다.

메시지 제출 에이전트(MSA)에는 특별한 재량이 있습니다. 저자가 아직 참여하는 경계에서 권위 있는 정보를 갖고 있다면 주소를 변환하거나 메시지를 보통 RFC 5321 형태로 수리할 수 있습니다. 여기에는 명시적으로 프로비저닝된 ASCII 별칭이 포함될 수 있습니다. RFC 6531은 그 변환을 의도적으로 자신의 범위 밖에 둡니다.

전송 중 릴레이에는 그런 일반적 면허가 없습니다. 유효한 호환 메시지를 선택할 수 없다면, 거부하거나, 규격에 맞는 비배달 통지를 생성하거나, 큐에 다시 넣거나, 적절한 대체 호스트를 시도해야 합니다. 실패는 "이 경로가 주소를 운반할 수 없다"와 "이 메일박스가 존재하지 않는다" 사이의 구분을 보존합니다.

UTF-8은 필드 이름을 바꾸지 않은 채 헤더에 들어왔

RFC 6532는 많은 헤더 필드 본문에 직접 UTF-8을 허용합니다. Subject 같은 비구조화 값, 주소 로컬파트, quoted string, 도메인, 일부 Message-ID 구조가 그렇습니다. 헤더 필드 이름 자체는 ASCII로 남습니다.

행 규칙은 문자와 바이트 사이의 또 다른 구분을 드러냅니다. 경질 최대치는 998 옥텟이 됩니다. UTF-8 문자 하나가 여러 옥텟을 차지할 수 있기 때문입니다. 권장되는 78단위 표시 폭은 여전히 문자로 측정됩니다. 하나의 경계는 전송 용량을 보호하고, 다른 하나는 사람의 표현을 보호합니다.

정규화는 가볍게 신원을 지울 수 없습니다. RFC 6532는 NFC를 권장하고, 호환 접기가 철자 구분을 잃을 수 있는 NFKC를 경고합니다. 비슷해 보이거나 다르게 정규화되는 두 문자열을 중간 릴레이가 하나의 메일박스라고 선언할 수 없습니다. 최종 배달 시스템이 로컬파트 해석에 대한 권한을 유지합니다.

실패 보고서는 실패한 이름을 보존해야 했

배달 상태 통지(DSN)가 어느 수신자가 실패했는지 말할 수 없다면 국제화된 주소는 운영적으로 불완전할 것입니다. 그래서 RFC 6533은 UTF-8 주소 유형과 ORCPT 및 DSN 필드에 적합한 형태를 정의하며, 원시 UTF-8을 운반할 수 없는 맥락을 위한 7비트 안전 인코딩도 포함합니다.

이것은 다운그레이드가 아니라 보존입니다. 원래 수신자를 통지에 인코딩하는 것은 주소의 증거를 유지할 뿐, 원래 메시지를 받을 수 있는 ASCII 메일박스를 만들지 않습니다. 이 구분은 보고 메커니즘이 라우팅 해법으로 오해되는 것을 막습니다.

서버가 SMTPUTF8과 DSN을 모두 광고한다면, RFC 6531은 그 서버가 RFC 6533을 구현하도록 요구합니다. 기능의 조합이 다시 명시적입니다. 시스템은 실패와 연관 짓는 데 필요한 신원을 버리면서 국제화된 배달 보고를 약속해서는 안 됩니다.

기능은 소유권이 아니었

SMTPUTF8은 서버가 한 부류의 문자열을 구문 분석하고 전송할 수 있다고 말합니다. 메일박스가 존재한다는 것, 어떤 사람이 그것을 소유한다는 것, 시각적으로 비슷한 두 이름이 동등하다는 것, 도메인이 신뢰할 수 있다는 것, 최종 응용이 모든 문자를 안전하게 렌더링할 것이라는 것을 증명하지 않습니다.

지속적인 거버넌스 교훈은 기술적 관용을 신원 권한으로 변환하기를 거부하는 것입니다. 원 측은 별칭을 프로비저닝할 수 있습니다. 최종 배달 시스템은 자신의 로컬 네임스페이스를 해석할 수 있습니다. 릴레이는 기능을 보고하고 정확한 바이트를 운반할 수 있습니다. 어느 쪽도 경로를 계속 움직이게 하기 위해 대체 인물을 발명할 수는 없습니다.

출처와 한계

아키텍처는RFC 6530에서, SMTP 동작은RFC 6531에서, 헤더 구문은RFC 6532에서, 통지 증거는RFC 6533에서, 현재 키워드 기록은IANA SMTP 레지스트리에서 옵니다. 이 출처들은 표준과 그 명시된 역사를 정의합니다. 현재 공급자 지원 수준, 전역 도달 가능성, 메일박스 소유권 또는 유니코드 혼동 사건은 측정하지 않습니다.