이메일 주소

전자 메일 주소는 메시지가 배달되는 전자 메일 상자를 식별한다.초기 메시징 시스템은 주소 지정을 위해 다양한 형식을 사용했지만, 오늘날, 전자 메일 주소는 1980년대에 인터넷 엔지니어링 태스크포스(IETF)에 의해 원래 표준화되었고, 에 의해 업데이트되었다. RFC5322와 6854.이 글에서 이메일 주소라는 용어는 주소나 우편함이 아닌 RFC 5322의 addr-spec, 즉 표시 이름이 없는 원시 주소를 가리킨다.

john.smith@example.com과 같은 이메일 주소는 로컬 파트, 기호 @ 및 도메인으로 구성되며, 도메인 이름은 괄호로 묶인 도메인 이름 또는 IP 주소일 수 있다.표준은 로컬 부분이 대소문자를 구분하도록 요구하지만,^[1] 수신 호스트가 대소문자를 구분하여 메시지를 전달할 것을 촉구한다.^[2] 예를 들어 도메인 example.com의 메일 시스템이 존을 취급한다.스미스는 존 스미스와 동등하다; 어떤 우편 시스템은 그들을 존 스미스와 동등하게 취급하기도 한다.^[3]메일 시스템은 종종 사용자의 이름 선택을 기술적으로 허용된 문자의 하위 집합으로 제한한다.

국제화된 도메인명의 도입으로, 비 ASC를 허용하는 노력이 진전되고 있다.이메일 주소의 II 문자.

메시지 전송

전자 메일 주소는 로컬 부분과^[a] 도메인의 두 부분으로 구성된다. 도메인이 IP 주소가 아닌 도메인 이름인 경우 SMTP 클라이언트는 도메인 이름을 사용하여 메일 교환 IP 주소를 조회한다.이메일 주소의 일반 형식은 local-part@domain(예: jsmith@[1994.1.2], jsmith@example.com이다.SMTP 클라이언트는 메시지를 메일 교환소로 전송하며, 메일 교환은 수신인의 메일 시스템 호스트에 최종적으로 도착할 때까지 다른 메일 교환소로 전달할 수 있다.

저자의 컴퓨터에서 그리고 인터넷의 메일 호스트들 사이에 전자우편의 전송은 RFC 5321과 5322에 정의된 SMTP(Simple Mail Transfer Protocol)와 RFC 6531과 같은 확장을 이용한다.우편함은 SMTP 프로토콜과 POP(Post Office Protocol) 또는 IMAP(Internet Message Access Protocol)를 사용하여 개인용 컴퓨터, 모바일 장치 또는 웹 메일 사이트의 애플리케이션에 의해 액세스 및 관리될 수 있다.

전자 메일 메시지를 전송할 때 메일 사용자 에이전트(MUA)와 메일 전송 에이전트(MTA)는 도메인 이름 시스템(DNS)을 사용하여 수신인의 도메인에 대한 리소스 레코드(RR)를 검색한다.메일 교환기 리소스 레코드(MX 레코드)는 수신인의 메일 서버의 이름을 포함한다.MX 레코드가 없는 경우, 주소 레코드(A 또는 AAAA)가 메일 호스트를 직접 지정한다.

전자 메일 주소의 로컬 부분은 최종 사서함 호스트 이외의 중간 메일 릴레이 시스템에 의미가 없다.전자 메일 송신자와 중간 릴레이 시스템은 최종 사서함 호스트가 이를 대소문자를 구분하지 않는다고 간주해서는 안 된다.관리자가 구성한 경우, 단일 우편함은 여러 전자 메일 주소에 대한 메일을 수신할 수 있다.반대로 단일 전자 메일 주소는 많은 사서함에 대한 메일 그룹의 별칭일 수 있다.전자우편 별칭, 전자우편 목록, 하위 주소 지정, 캐치-올 어드레싱, 후자는 로컬 부분에 관계없이 메시지를 수신하는 우편함으로서 다양한 배달 목표를 달성하기 위한 일반적인 패턴이다.

이메일 메시지의 헤더 필드에 있는 주소는 메일 교환에서 메시지를 배달하는 데 직접 사용되지 않는다.이메일 메시지에는 메일 라우팅에 대한 정보가 들어 있는 메시지 봉투도 포함되어 있다.봉투와 헤더 주소가 같을 수 있지만, 위조된 이메일 주소(스푸핑된 이메일 주소라고도 함)는 스팸, 피싱, 그리고 많은 다른 인터넷 기반 스캠에서 흔히 볼 수 있다.이것은 그러한 사기성 이메일의 위조를 더 쉽게 찾아낼 수 있도록 하는 것을 목표로 하는 몇몇 계획으로 이어졌다.

구문

이메일 주소의 형식은 local-part@domain이며, 여기서 로컬 부분은 최대 64 옥텟이 될 수 있고 도메인은 최대 255 옥텟이 될 수 있다.^[4]공식 정의는 RFC 5322(3.2.3절 및 3.4.1절)와 RFC 5321에 있으며, 정보 RFC 3696^[b] 및 관련 에라타에 더 읽기 쉬운 형식이 제공된다.

또한 이메일 주소에는 주소 사양보다 앞에 있는 수신인에 대한 관련 표시 이름이 있을 수 있으며, 예를 들어 존 스미스 <john.smith@example.org>과 같이 각진 괄호로 둘러싸여 있다.

인터넷 이외의 다른 네트워크에 대한 초기 형태의 이메일 주소에는 X.400에서 요구하는 것과 같은 다른 표기법과 메시지가 전달되어야 하는 일련의 컴퓨터 형태로 주소가 주어진 UUCP 뱅 경로 표기법이 포함되어 있었다.이것은 몇 년 동안 널리 사용되었지만, 인터넷 엔지니어링 태스크포스(IETF)에 의해 공포된 인터넷 표준으로 대체되었다.

로컬 파트

이메일 주소의 로컬 부분은 인용 부호가 없거나 인용 부호로 묶을 수 있다.

인용 부호가 없는 경우 다음 ASCII 문자 중 하나를 사용할 수 있다.

• 대문자와 소문자.A로Z그리고a로z
• 숫자0로9
• 인쇄할 수 있는 문자!#$%&'*+-/=?^_`{ }~
• 점을 찍다., 처음 또는 마지막 문자가 아니며 연속적으로 나타나지 않는 경우(예:John..Doe@example.com허용되지 않음).^[5]

인용된 경우, 그것은 Backslash와 Quote를 제외한 모든 ASCII 그래픽과 HT, Space 또는 ASCII 그래픽으로 구성된 인용 쌍을 포함할 수 있으며, HT 또는 Space가 나타나는 곳이면 어디든 선 간에 분할될 수 있다.인용되지 않은 로컬 부품과 대조적으로, 주소".John.Doe"@example.com,"John.Doe."@example.com그리고"John..Doe"@example.com허용된다.

이메일 주소의 로컬 부분의 최대 총 길이는 64 옥텟입니다.^[6]

일부 메일 서버는 로컬 부분에 대한 와일드카드 인식을 지원하므로, 일반적으로 플러스 이하의 문자와 마이너스를 따르는 문자는 프레드+바흐@domain 및 fred+foo@domain과 동일한 받은 편지함에 속하거나 심지어 fred@domain과 같은 편지함에 유의하십시오.이 기능은 전자 메일의 정렬 태그 지정(아래 참조) 및 스팸 제어에 유용할 수 있다.^[7]교정기{그리고}비록 덜 자주 쓰이기는 하지만, 그러한 방식으로도 사용된다.^{[citation needed]}

• 공간과 특수 문자"(),:;<>@[\]제한사항이 허용된다(아래 단락에서 설명한 대로 인용된 문자열 내에서만 허용되며, 인용된 문자열에서 백슬래시 또는 이중슬래시는 백슬래시가 한 번 선행되어야 한다).
• 코멘트는 로컬 파트의 양쪽 끝에 괄호로 허용된다. 예를 들어,john.smith(comment)@example.com그리고(comment)john.smith@example.com둘 다 에 해당한다.john.smith@example.com.

SMTPUTF8 및 8BITMIME을 지원하는 메일 시스템에서도 로컬 부품을 할당할 때 사용할 문자를 제한할 수 있지만 위의 ASCII 문자 외에도 UTF-8로 인코딩된 U+007F 이상의 국제 문자는 RFC 6531에 의해 허용된다.

로컬 부분은 도트 문자열 또는 따옴표로 묶인 문자열이며 조합이 될 수 없다.그러나 인용된 문자열과 문자는 일반적으로 사용되지 않는다.^{[citation needed]}또한 RFC 5321은 "메일 수신을 예상하는 호스트는 로컬 파트가 인용된 문자열 양식을 요구하거나 사용하는 우편함을 정의하지 않아야 한다"고 경고한다.

로컬 파트postmaster특별히 취급됨—대소문자를 구분하며, 도메인 전자 메일 관리자에게 전달해야 함.기술적으로 다른 모든 지역 부품은 대소문자를 구분하므로jsmith@example.com그리고JSmith@example.com다른 우편함을 지정하지만, 많은 조직에서는 대문자와 소문자를 동등하게 취급한다.실제로 RFC 5321은 "메일을 수신할 것으로 예상되는 호스트는 다음과 같은 위치에 사서함을 정의하지 않아야 한다"고 경고한다.Local-part는 대소문자를 구분한다."

기술적으로 유효한 특수문자의 광범위한 범위에도 불구하고, 조직, 메일 서비스, 메일 서버, 메일 클라이언트는 실제로 모든 문자를 받아들이지 않는다.예를 들어 Windows Live Hotmail에서는 영숫자, 도트(점)를 사용하는 이메일 주소만 만들 수 있다..(), 밑줄()._) 및 하이픈().-일반적인 조언은 거부된 이메일의 위험을 피하기 위해 일부 특수 문자를 사용하지 않는 것이다.^[8][9]

도메인

전자 메일 주소의 도메인 이름 부분은 엄격한 지침을 준수해야 한다: 호스트 이름의 요구사항, 점으로 구분된 DNS 라벨 목록과 일치해야 하며, 각 라벨은 63자로 제한되고 다음과 같이 구성된다.^{[5]: §2}

• 대문자와 소문자.A로Z그리고a로z;
• 숫자0로9최상위 도메인 이름이 모두 지정되지 않은 경우,
• 하이픈을 치다-첫 번째 문자나 마지막 문자가 아닌 경우.

이 규칙은 LDH 규칙(글자, 숫자, 하이픈)으로 알려져 있다.또한 도메인은 대괄호로 둘러싸인 IP 주소 리터럴일 수 있다.[]예를 들어jsmith@[192.168.2.1]또는jsmith@[IPv6:2001:db8::1]비록 이것은 이메일 스팸을 제외하고는 거의 보이지 않는다.국제화된 도메인 이름(호스트 이름 요구 사항을 준수하도록 인코딩됨)은 ASCII가 아닌 도메인의 표시를 허용한다.RFC 6531 및 RFC 6532를 준수하는 메일 시스템에서 이메일 주소는 도메인 이름뿐만 아니라 로컬 부분인 UTF-8로 인코딩될 수 있다.

코멘트는 로컬 파트뿐만 아니라 도메인에서도 허용된다. 예를 들어,john.smith@(comment)example.com그리고john.smith@example.com(comment)와 같다john.smith@example.com.

예약된 도메인

RFC 2606은 문서화 및 시험을 목적으로 하는 도메인과 같은 특정 도메인을 확인할 수 없어야 하며 그 결과 해당 도메인의 우편함과 하위 도메인으로 발송되는 우편물이 배달되지 않아야 한다고 명시한다.이메일에 대한 주의사항은 예시, 무효, example.com, example.net, 그리고 example.org이다.

예

유효한 이메일 주소

simple@example.com

very.common@example.com

disposable.style.email.with+symbol@example.com

other.email-with-hyphen@example.com

fully-qualified-domain@example.com

user.name+tag+sorting@example.com(가도 좋다)user.name@example.com메일 서버에 따라 받은 편지함)

x@example.com(한글자 로컬 부품)

example-indeed@strange-example.com

test/test@test.com(슬래시는 인쇄 가능한 문자이며, 허용됨)

admin@mailserver1(ICANN이 점 없는 전자 메일 주소를^[10] 매우 저해하지만 TLD가 없는 로컬 도메인 이름)

example@s.example(인터넷 최상위 도메인 목록 참조)

" "@example.org(따옴표 사이의 공백)

"john..doe"@example.org(이중 점)

mailhost!username@example.org(uucp 메일러에 사용되는 호스트 경로 확인)

"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(문자가 아닌 문자 AND와 기호에 여러 개 포함, 첫 번째 문자가 이중으로 인용됨)

user%example.com@example.org(% 탈출 메일 경로: user@example.com을 통해 user@example.com)

user-@example.org(인쇄 가능한 문자 목록에서 영숫자가 아닌 문자로 끝나는 로컬 부분)

postmaster@[123.123.123.123](대괄호로 묶인 경우 도메인 대신 IP 주소가 허용되지만 강력하게 금지됨)

postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](IPv6는 다른 구문을 사용함)

잘못된 전자 메일 주소

Abc.example.com(no @ 문자)

A@b@c@example.com(따옴표 외부에는 하나의 @만 허용됨)

a"b(c)d,e:f;g<h>i[j\k]l@example.com(이 로컬 파트의 특수 문자는 인용 부호 외부로 허용됨)

just"not"right@example.com(이중 문자열은 점으로 구분하거나 로컬 부품을 구성하는 유일한 요소여야 함)

this is"not\allowed@example.com(따옴표, 따옴표 및 백슬래시는 따옴표된 문자열 내에 있을 때만 존재할 수 있음)

this\ still\"not\\allowed@example.com(백슬래시로 표시된 경우에도 공백, 따옴표 및 백슬래시는 따옴표로 포함되어야 함)

1234567890123456789012345678901234567890123456789012345678901234+x@example.com(로컬 파트가 64자를 초과함)

i_like_underscore@but_its_not_allowed_in_this_part.example.com(도메인 부분에서는 언더스코어가 허용되지 않음)

QA[icon]CHOCOLATE[icon]@test.com(아이콘 문자)

공통로컬-부품 의미론

RFC 5321 2.3.11 우편함 및 주소에 따르면 "...로컬 파트에서는 반드시 주소의 도메인에 지정된 호스트만 의미론을 해석하고 할당해야 한다."이것은 다른 메일 서버의 로컬 부분의 의미에 대해 어떠한 가정도 할 수 없다는 것을 의미한다.그것은 전적으로 메일 서버의 구성에 달려 있다.

국소-부품 정규화

이메일 주소의 로컬 부분에 대한 해석은 메일 서버에서 구현되는 규약과 정책에 따라 달라진다.예를 들어, 사례 민감도는 그리 흔하지는 않지만, 로컬 파트의 문자 대문자만 다른 우편함을 구별할 수 있다.^[11]Gmail은 계정 ID를 결정하기 위해 @gmail.com 주소의 로컬 부분에 있는 모든 점을 무시한다.^[12]

서브어드레싱

일부 메일 서비스는 주소가 로컬 부분의 접두사에 대한 별칭인 것처럼 로컬 파트에 포함된 태그를 지원한다.예를 들어 주소 jouser+tag@example.com은 joeuser@example.com과 동일한 배송 주소를 나타낸다.RFC 5233은 ^[13]이 관례를 하위 주소 지정이라고 부르지만, 주소 지정, 태그 지정 또는 메일 확장이라고도 한다.

기본 이름과 태그 사이에 다양한 구분자를 사용하는 이 형식의 주소는 Andrew Project(플러스),^[14] Runbox(플러스), Gmail(플러스), ^[15]Rackspace(플러스), Yahoo! 등 여러 이메일 서비스에 의해 지원된다. 메일플러스(^[16][22]Outlook.com), 애플의 아이클라우드(플러스),^[17] Outlook.com(플러스), 프로토메일(플러스),^[18] 패스트메일(플러스 및 서브도메인 어드레싱),^[19] postale.io(^[20]플러스), 포박스(플러스),^[21] MMDF(플러스), Qmail, Courier Mail 서버(스튜디오) 등이다.^[23][24]Postfix 및 Exim은 법적 문자 집합에서 임의 구분 기호를 구성할 수 있다.^[25][26]

태그의 텍스트는 필터링을 적용하거나 ^[23]일회용 또는 일회용 전자 메일 주소를 만드는 데 사용될 수 있다.^[27]

실제로 일부 웹 사이트의 양식 검증은 이메일 주소의 "+"와 같은 문자를 거부하여 잘못된 문자로 취급할 수 있다.이로 인해 경고나 오류 메시지 없이 웹사이트에 의해 "+"가 자동으로 벗겨진 경우 잘못된 사용자가 전자 메일을 수신하게 될 수 있다.예를 들어, 사용자가 입력한 이메일 주소 foo+bar@example.com을 위한 이메일이 foobar@example.com으로 잘못 전송될 수 있다.사용자 등록 페이지와 같은 사이트 일부에서는 "+" 문자를 허용하지만 사이트의 메일 목록에서 등록을 취소하기 위한 페이지와 같은 다른 부분은 그렇지 않은 경우 사용자 환경이 열악할 수 있다.

검증 및 검증

이 섹션은 검증을 위해 추가 인용구가 필요하다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오. 공급되지 않은 재료는 도전하여 제거할 수 있다.(2019년 7월) (이 템플릿 메시지를 제거하는 방법과 시기 알아보기)

이메일 주소는 종종 사용자 존재의 확인으로서 웹사이트에 입력으로 요청된다.휴대폰 번호 확인, 우편물 확인, 팩스 확인과 같은 다른 확인 방법을 사용할 수 있다.

RFC 822와 후속 RFC에 상세하게 기술된 사양이 더 광범위하지만, 이메일 주소는 일반적으로 at-sign(@)과 함께 결합된 두 부분으로 인식된다.^[28]

구문적으로 올바르고 검증된 이메일 주소가 이메일 박스가 존재한다고 보장하지는 않는다.따라서 많은 메일 서버는 다른 기법을 사용하며, 도메인의 도메인 네임 시스템과 같은 관련 시스템과 비교하거나 콜백 확인을 사용하여 우편함이 존재하는지 여부를 확인한다.콜백 검증은 디렉터리 수집 공격을 피하기 위해 비활성화할 수도 있고, 콜백이 스팸으로 보고되어 DNSBL 상장으로 이어질 수도 있기 때문에 불완전한 해결책이다.

사용자 이메일 주소의 유효성을 검사하기 위해 몇 가지 유효성 검사 기법을 사용할 수 있다.예를 들어,^[29]

• 확인 링크: 전자 메일 주소 검증은 종종 사용자가 제공한 전자 메일 주소로 특별 임시 하이퍼링크를 사용하여 전자 메일을 전송하여 웹 사이트에서 계정을 생성하기 위해 수행된다.수신 시 사용자는 링크를 열어 계정을 즉시 활성화한다.전자 메일 주소는 웹 사이트의 메시지, 예를 들어 사용자 메시지, 사용자 작업, 전자 메일 받은 편지함으로 메시지를 전달하는 수단으로도 유용하다.

• 공식 및 비공식 표준: RFC 3696은 전자 메일 주소를 포함한 인터넷 식별자 검증에 대한 구체적인 조언을 제공한다.일부 웹 사이트는 대신 + 및 /와 같이 유효한 문자가 포함된 주소를 거부하거나 임의 길이 제한을 적용하는 등 임의 표준을 통해 전자 메일 주소의 유효성을 평가하려고 시도한다.이메일 주소 국제화는 UTF-8로 인코딩된 U+0080 이상의 모든 유니코드 문자와 같이 많은 현재 유효성 검사 알고리즘이 허용하는 것보다 훨씬 더 큰 범위의 문자를 제공한다.

• 알고리즘 도구: 대용량 웹 사이트, 대량 메일러 및 스팸 발송자는 전자 메일 주소의 유효성을 검사하는 효율적인 도구를 필요로 한다.그러한 도구는 경험적 접근법과 통계적 모델에 따라 달라진다.^[30]

• 보낸 사람 평판:전자 메일 보낸 사람의 평판은 보낸 사람이 신뢰할 수 있는지 또는 잠재적인 스팸 발송자인지 확인하는 데 사용될 수 있다.발신자 평판의 평가에 통합될 수 있는 요인은 발신자의 IP 주소 또는 이메일 주소의 참여 수준 또는 콘텐츠에 의해 제공된 과거 접촉의 품질을 포함한다.

• 브라우저 기반 검증: 많은 브라우저에서 구현된 HTML5 양식은 브라우저가 전자 메일 주소 유효성 검사를 처리할 수 있도록 한다.^[31]

일부 회사들은 종종 애플리케이션 프로그래밍 인터페이스를 사용하여 이메일 주소의 유효성을 검사하는 서비스를 제공하지만, 그것이 정확한 결과를 제공할 것이라는 보장은 없다.

국제화

IETF는 이메일 주소 국제화(EAI, IMA, Internationalized Mail Address)라는 제목의 이메일 주소의 국제화 문제에 전념하는 기술 및 표준 작업 그룹을 수행한다.^[32]이 그룹은 RFC 6530, 6531, 6532 및 6533을 생산했으며, 추가 EAI 관련 RFC에 대한 작업을 계속하고 있다.

IETF의 EAI 작업 그룹은 RFC 6530 "국제화된 전자 메일에 대한 개요 및 프레임워크"를 발표하여 비 ASC를 활성화하였다.전자 메일 주소의 로컬 부분과 도메인 모두에 사용할 II 문자.RFC 6530은 유니코드의 완전한 레퍼토리를 허용하는 UTF-8 인코딩 기반의 이메일을 제공한다.RFC 6531은 SMTP 서버가 SMTPUTF8 콘텐츠 전송을 협상할 수 있는 메커니즘을 제공한다.

기본적인 EAI 개념은 UTF-8로 메일을 교환하는 것을 포함한다.당초 제안에는 레거시 시스템 다운그레이드 메커니즘이 포함됐지만 지금은 이 기구가 떨어졌다.^[33]로컬 서버는 주소의 로컬 부분을 담당하지만, 도메인은 UTF-8로 전송되지만 국제화된 도메인 이름의 규칙에 의해 제한될 것이다.메일 서버는 IMA 양식과 ASCII 별칭 사이의 매핑 메커니즘도 담당한다.

EAI는 사용자가 기존 시스템과 통신하거나 스크립트에 독립적인 사용을 위한 ASCII 형식뿐만 아니라 네이티브 언어 스크립트 또는 문자 집합에서 지역화된 주소를 가질 수 있도록 한다.국제화된 도메인 이름과 메일 주소를 인식하는 애플리케이션에는 이러한 표현을 변환할 수 있는 기능이 있어야 한다.

중국, 일본, 러시아, 그리고 라틴어 기반의 비문자 시스템에서 대규모 사용자 기반을 가지고 있는 다른 시장에서는 이러한 주소에 대한 상당한 수요가 있을 것으로 예상된다.

예를 들어, 최상위 도메인 외에 2011년^[34] 인도 정부는 구즈라티, 마라티, 방갈리, 타밀, 텔루구, 푼자비, 우르두 스피커가 사용할 수 있도록 7개의 다른 스크립트로^[35][36] 작성된 ".bharat" (Bahrat Gaṇarajya로부터)에 대한 승인을 받았다.인도 회사인 XgenPlus.com은 세계 최초의 EAI 사서함 제공업체라고 주장하고 있으며,^[37] 라자스탄 정부는 현재 domain्थान 도메인에서 무료 이메일 계정을 제공하고 있다.국가 국민 한 사람 한 사람 한 사람 한 사람 한 사람 ^[38]한 사람 한 사람 한 사람에게대표적인 미디어 하우스인 라자스탄 파트리아카는 IDN 도메인인 पत्रा launched를 출시했다.भारत 연락처 e-메일을 참조하십시오.

국제화 예

아래의 예시 주소는 RFC 5322 기반 서버에서 처리되지 않지만 RFC 6530에서 허용된다.이를 준수하는 서버는 다음 사항을 처리할 수 있다.

• 분음 부호가 있는 라틴 문자:Pelé@example.com
• 그리스 문자: Δοκμ μή@παρδδδδμ μαα μα.δοκιμή
• 전통 한자: :買@屋企.香港
• 일본어 문자: 二ノ宮@黒川.日本
• 키릴 문자: мее@@сааааа@ооооооооооо.рф
• 데바나가리 문자: संप@@@डाटालललल.भारत

국제화 지원

• 포스트픽스 메일러는 안정적 릴리스 3.0.0으로 2015-02-08년 이후 국제화된 메일을 지원한다.^[39]
• 구글은 국제화된 도메인으로 이메일을 보내고 받는 것을 지원하지만 ASCII가 아닌 이메일 주소의 등록은 허용하지 않는다.^[40]
• Microsoft에서 아웃룩 2016에^[41] 유사한 기능을 추가함
• DataMail은 인도에서 XgenPlus 이메일 플랫폼을 사용하여 8개 인도 언어에 대한 국제화된 이메일 지원을 시작한다.^[42]

표준 문서

• RFC 821 – Simple Mail Transfer Protocol(RFC 2821에 의해 숨겨짐)
• RFC 822 – ARPA 인터넷 문자 메시지 형식 표준(RFC 2822에 의해 설명됨)(Errata)
• RFC 1035 – 도메인 이름, 구현 및 사양(Errata)
• RFC 1123 – 인터넷 호스트, 애플리케이션 및 지원에 대한 요구 사항(RFC 2821, RFC 5321)(Errata)
• RFC 2142 – 공통 서비스, 역할 및 기능의 사서함 이름(Errata)
• RFC 2821 – 단순 메일 전송 프로토콜(Obsoletes RFC 821, 업데이트 RFC 1123, RFC 5321에 의해 사용되지 않음) (Errata)
• RFC 2822 – 인터넷 메시지 형식(Obsoletes RFC 822, RFC 5322에 의해 사용되지 않음) (Errata)
• RFC 3696 – 이름 확인 및 변환을 위한 적용 기법(Errata)
• RFC 4291 – IP 버전 6 어드레싱 아키텍처 (RFC 5952에 의해 업데이트됨) (Errata)
• RFC 5321 – 단순 메일 전송 프로토콜(Obsletes RFC 2821, 업데이트 RFC 1123)(Errata)
• RFC 5322 – 인터넷 메시지 형식(Obsoletes RFC 2822, RFC 6854에 의해 업데이트됨) (Errata)
• RFC 5952 – IPv6 주소 텍스트 표현 권장 사항(RFC 4291)(Errata)
• RFC 6530 – 국제화된 전자우편을 위한 개요 및 프레임워크 (Obsoletes RFC 4952, 5504, 5825)
• RFC 6531 – 국제화된 전자 메일을 위한 SMTP 확장(Obsoletes RFC 5336)
• RFC 6854 – "From:" 및 "Sender:" 헤더 필드(RFC 5322 업데이트)에서 그룹 구문을 허용하도록 인터넷 메시지 형식으로 업데이트

참고 항목

• 안티스팸 기술
• 이메일 클라이언트
• 이메일 박스
• 이메일 인증
• 국제 이메일

메모들

참조

외부 링크

• Wikibook에서 이메일 주소 확인
• Wikibook의 모범 사례
• Wikimedia Commons의 이메일 주소와 관련된 미디어