요약

  • RFC 5233은 Sieve 비교에:user와:detail주소 부분을 추가했지만, 하나의 구분 기호나 보편적인 플러스 주소 형식을 표준화하지는 않았습니다.
  • 포괄적인 메일 시스템이 로컬 인코딩을 소유하며, 봉투(envelope)의to는 표시 헤더가 보존하지 않는 수신자 디테일을 보존할 수 있습니다.

기호는 지역적이었고, 계약은 경계였다

디테일 접미사가 붙은 주소는 메시지를 폴더로 분류하거나, 메일링 리스트 구독을 식별하거나, 음성 사서함을 구분할 수 있습니다. 플러스 기호는 그 디테일을 표시하는 익숙한 방법 중 하나이지만, 그것은 하나의 예시일 뿐입니다. 2008년 1월에 발표된 RFC 5233은 Sieve에 두 개의 추가 주소 부분, 즉:user와:detail을 제공했습니다. 이 문서는 필터가 비교할 수 있는 구성 요소를 설명했을 뿐, 전역 주소 문법을 정의하지 않았습니다.

이 구분이 중요한 이유는 이메일 로컬 파트가 로컬 메일 시스템 안에서 해석되기 때문입니다. RFC 5233은 사용자 뒤에 오는 디테일을+로, 그리고 사용자 앞에 오는 디테일을로 표시하는 예를 보여줍니다. 선택된 구분 기호가 두 번 이상 나타날 때 분할 방식은 구현에 따라 정의되며, 일반적으로 포괄적인 시스템의 형식을 따릅니다. 구현은 해당 시스템이 사용하거나 허용하는 인코딩과 일치해야 하며, 그 형식이 어떻게 정의되거나 조회되는지는 RFC의 범위 밖입니다. 필터는 다른 제공자가 그렇게 사용한다는 이유만으로+가 '디테일'을 의미한다고 안전하게 추론할 수 없습니다.

인코딩된 디테일이 없는 주소의 경우,:user는 전체 로컬 파트를 의미하며 Sieve의:localpart와 동일합니다.:detail은 요청된 값과 일치하지 않습니다. 인코딩된 빈 디테일은 다릅니다. 즉, 빈 문자열로 해석됩니다. 이 규칙들은 스크립트가 '디테일 구성 요소가 없는' 경우와 '존재하지만 텍스트가 없는' 구성 요소를 구분할 수 있게 합니다.

RFC 5233은 또한 주소의 출처를 구분합니다.address테스트는 구조화된 메시지 헤더를 검사하고, 선택적인envelope테스트는 전송 봉투 데이터를 검사합니다. 필터가 이 수신자에게 전달을 유발한 주소를 기준으로 메일을 분류하는 경우, RFC는 대부분의 경우 봉투의to가 선호된다고 명시합니다. 메일링 리스트, 별칭, 가상 도메인은 그 봉투를 수신자별 디테일이 유일하게 남는 장소로 만들 수 있습니다. 발신자나 봉투from같은 외부 주소에 자신의 로컬 인코딩을 적용하면 일관성 없거나 잘못된 결과가 나올 수 있습니다.

이 확장은 RFC 3598의 이전 서브주소(subaddress) 텍스트를 대체했습니다. 변경 노트는 인코딩 언어를 일반화하고 봉투 및 외부 주소 관련 주의 사항을 추가했습니다. IANA는 이 기능을subaddress로 기록합니다. 그 레지스트리 항목은 확장 이름을 알리는 것이며, 모든 메일 시스템이 어떤 특정 태그 주소든 받아들인다는 약속이 아닙니다. 따라서 이 프로토콜 역사는 경계에 관한 이야기입니다. 호스트 자체의 해석이 제공되면 Sieve는 로컬 파트를 비교할 수 있지만, 그 해석을 만들어내거나 사서함이 어떻게 프로비저닝되었는지 증명할 수는 없습니다.

출처