간이 메일 전송 프로토콜

Simple Mail Transfer Protocol
「SMTP」는 여기서 리다이렉트 됩니다.전자 메일 전달 회사에 대해서는, SMTP(회사)를 참조해 주세요.Short Message Transfer Protocol 에 대해서는, GSM 03.40 을 참조해 주세요.
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

SMTP(Simple Mail Transfer Protocol)는 전자 메일 전송을 위한 인터넷 표준 통신 프로토콜입니다.메일 서버 및 기타 메시지 전송 에이전트는 SMTP를 사용하여 메일 메시지를 송수신합니다.사용자 레벨의 전자 메일클라이언트는, 통상은 SMTP 를 사용해 메일 서버에 메세지를 송신해 릴레이를 실시합니다.또, 통상, 송신 전자 메일을 포토 587 또는 465 의 메일 서버에 송신합니다. RFC8314.메시지 취득에는 IMAP(구식 POP3를 대체한 것)가 표준이지만 소유권 서버에서는 Exchange ActiveSync 등의 독자적인 프로토콜도 구현되는 경우가 많습니다.

SMTP의 기원은 1971년부터 ARPANET에 구현된 개념을 바탕으로 1980년에 시작되었다.여러 번 업데이트, 수정 및 확장되었습니다.현재 일반적으로 사용되는 프로토콜 버전은 인증, 암호화, 이진 데이터 전송 및 국제화된 전자 메일 주소를 위한 다양한 확장 기능을 갖춘 확장 가능한 구조를 가지고 있습니다.SMTP 서버는, 통상, 포토 번호 25(평문용)와 587(암호화된 통신용)로 Transmission Control Protocol 를 사용합니다.

역사

SMTP의 이전 버전

상세 정보:이메일 이력

1960년대에는 다양한 형태의 일대일 전자 메시지가 사용되었다.사용자는 특정 메인프레임 컴퓨터용으로 개발된 시스템을 사용하여 통신했습니다.특히 미국 정부의 ARPANET에서 더 많은 컴퓨터가 상호 연결됨에 따라 서로 다른 운영 체제 간에 메시지를 교환할 수 있도록 표준이 개발되었습니다.SMTP는 1970년대에 개발된 이러한 표준을 기반으로 성장했습니다.

ARPANET 상의 메일은 1971년으로 거슬러 올라갑니다.메일 박스 프로토콜은 [1]구현되지 않았지만 RFC 196에서 논의되고 있습니다.그리고 BBN의 Ray Tomlinson이 그 해에 ARPANET [2][3][4]상의 두 컴퓨터를 통해 메시지를 전송하기 위해 수정한 SNDMSG 프로그램입니다.메일 프로토콜에 대한 추가 제안은 1973년 [5]6월에 RFC 524에서 이루어졌지만,[6] 구현되지 않았다.

ARPANET에서의 "네트워크 메일"에 대한 File Transfer Protocol(FTP)의 사용은 1973년 [7]3월 RFC 469에서 제안되었다.1977년 11월에 RFC 561, RFC 680, RFC 724 및 마지막으로 RFC 733을 통해 위의 FTP 메일서버를 사용하는 "전자 메일"을 위한 표준화된 프레임워크가 [8]개발되었습니다.

오리지널 SMTP

1980년 Jon Postel과 Suzanne Sluizer는 메일용 FTP를 대체하기 위해 Mail Transfer Protocol을 제안한 RFC 772를 발표했습니다.1981년 5월 RFC 780에서는 FTP에 대한 모든 참조가 삭제되고 포트 57이 TCP 및[citation needed] UDP용으로 할당되었습니다.이 할당은 IANA에 의해 삭제되었습니다.1981년 11월, Postel은 RFC 788 "Simple Mail Transfer Protocol"을 발행했다.

SMTP 표준은 일부 [citation needed]유사점을 가진 일대다 통신 네트워크인 Usenet과 비슷한 시기에 개발되었습니다.

SMTP는 1980년대 초에 널리 사용되었습니다.그 당시에는 Unix to Unix Copy Program(UUCP)을 보완하는 것으로, 단속적으로 접속되어 있는 머신간의 E-메일 전송 처리에 최적이었습니다.한편, SMTP 는, 송신 머신과 수신 머신이 모두 네트워크에 항상 접속되어 있는 경우에 최적으로 동작합니다.둘 다 스토어 및 포워드 메커니즘을 사용했으며 푸시 기술의 예입니다.Usenet의 뉴스 그룹은 여전히 서버 [9]간에 UUCP로 전파되었지만, 메일 전송으로서의 UUCP는 메시지 라우팅 [11]헤더로 사용된 "방 경로"와 함께 사실상 사라졌다[10].

1983년에 4.1cBSD와 함께 출시된 Sendmail은 [12]SMTP를 최초로 구현한 메일 전송 에이전트 중 하나였습니다. 시간이 흐르면서 BSD Unix가 인터넷에서 가장 인기 있는 운영 체제가 되면서 Sendmail은 가장 일반적인 MTA(메일 전송 에이전트)[13]가 되었습니다.

원래 SMTP 프로토콜은 인증되지 않은 암호화되지 않은 7비트 ASCII 텍스트 통신만 지원했으며 사소한 중간자 공격, 스푸핑 및 스팸에 취약했으며 바이너리 데이터를 전송하기 전에 읽을 수 있는 텍스트로 인코딩해야 했습니다.적절한 인증 메커니즘이 없기 때문에 설계상 모든 SMTP 서버는 열린 메일 릴레이였습니다.Internet Mail Consortium(IMC; 인터넷 메일 컨소시엄)은 메일 서버의 55%가 1998년에는 [14]오픈 릴레이였지만 [15]2002년에는 1% 미만이었다고 보고했습니다.스팸 우려로 인해 대부분의 전자 메일 공급자는 차단 목록을 공개 [16]릴레이하므로 원래 SMTP는 인터넷에서 일반적으로 사용할 수 없습니다.

최신 SMTP

1995년 11월 RFC 1869에서는 기존의 모든 확장자 및 미래의 확장자를 위한 일반적인 구조를 정의했습니다.ESMTP는 ESMTP 클라이언트와 서버를 식별하고 서버를 나타낼 수 있는 일관되고 관리 가능한 수단을 정의합니다.서포트되고 있습니다.

메시지 송신(RFC 2476)과 SMTP-AUTH(RFC 2554)는 모두 1998년과 1999년에 도입되어 전자 메일 전달의 새로운 경향을 나타내고 있습니다.원래 SMTP 서버는 일반적으로 조직 내부로 외부에서 조직 메일을 수신하고 조직에서 외부로 메시지를 릴레이합니다.그러나 시간이 경과함에 따라 SMTP 서버(메일 전송 에이전트)는 실제로 메일 사용자 에이전트의 메시지 전송 에이전트로 역할을 확장하고 있었으며, 그 중 일부는 이제 조직 외부에서 메일을 릴레이하고 있었습니다.(예를 들어, 회사 임원이 출장 중에 회사의 SMTP 서버를 사용하여 이메일을 보내려고 하는 경우)이 문제는, 월드 와이드 웹의 급속한 팽창과 인기의 결과, SMTP와 같은 귀찮은 이메일(스팸)의 계전 방식으로 인권 유린을 막도록 사용자 인증 메일 중계에 대한 구체적 규칙과 방법에 포함되야 했다.때문에 인기 있는 메일 서버들이 그것에 문제가 문제를 고칠 수 있게 예를 들어, 자격이 없는 주소로 도메인 이름을 추가하는 메일을 다시 쓸 것이다 메시지 제출(RFC2476)에 힘쓰다 원래 시작되었다.때 메시지가 다른 곳과 중계되고 있는 유래된 메시지를 수리하고 이 행동이 도움이 되는 초기 제출,고 해로운 위험하다.Cleanly 제출하고 계전기로 메일을 분리하는 방법과 재작성 계전기 금지 신청서 재작성을 장려하도록 허용해 줄 것으로 여겨졌다.현재 스팸 더 유행했던, 이것 또한 어떤 방식으로 메일 조직뿐만 아니라 추적 가능성에서 파견 나가는 것에 대한 권한 부여를 제공하는 것을 보였다.현대의 이메일 보안 관행을 위해 릴레이와 복종의 이 분리 거리를 금방 히트를 기초이다.

이 프로토콜은 ASCII 텍스트 기반으로 시작되었기 때문에 이진 파일이나 많은 영어 이외의 언어의 문자를 잘 다루지 못했습니다.MIME(Multipurpose Internet Mail Extensions) 등의 규격은 SMTP를 통해 전송하기 위한 바이너리 파일을 인코딩하기 위해 개발되었습니다.Sendmail 이후에 개발된 메일 전송 에이전트(MTA)도 8비트 클린으로 구현되는 경향이 있기 때문에 임의의 텍스트 데이터(8비트 ASCII와 유사한 문자)를 전송하기 위해 대체 전략을 사용할 수 있습니다.SMTP 경유). Mojibake는 벤더 간의 문자 집합 매핑이 다르기 때문에 여전히 문제가 되고 있습니다.단, 이메일주소 자체는 ASCII만 허용되지만 8비트 클린 MTA는 현재 8BITMIME 확장자를 지원하는 경향이 있으며 일부 바이너리 파일을 일반 텍스트(온라인 길이 및 Permi)와 거의 비슷하게 쉽게 전송할 수 있습니다.ted octet 값은 그대로 적용되므로 대부분의 비텍스트 데이터 및 일부 텍스트 형식에는 MIME 인코딩이 필요합니다).2012년에는SMTPUTF8확장 기능은 UTF-8 텍스트를 지원하도록 작성되었으며 국제 콘텐츠와 주소를 키릴 문자나 중국어 등의 라틴어 이외의 스크립트로 사용할 수 있습니다.

SMTP의 핵심 사양에는 Jon Postel, Eric Allman, Dave Crocker, Ned Free, Randal Gellens, John Klensin 및 Keith Moore가 기여했습니다.

메일 처리 모델

파란색 화살표는 SMTP 버전 구현을 나타냅니다.

메일 클라이언트(메일 유저 에이전트, MUA)에 의해서, TCP 포토 587 상의 SMTP 를 사용해 메일 서버(메일 송신 에이전트, MSA)에 전자 메일이 송신됩니다.대부분의 우편함 공급자는 여전히 기존 포트 25에서 전송을 허용합니다.MSA는 메일 전송 에이전트(메일 전송 에이전트, MTA)에 메일을 전달합니다.대부분의 경우 이들 2개의 에이전트는 같은 머신 상에서 다른 옵션으로 기동된 같은 소프트웨어의 인스턴스입니다.로컬 처리는 1대의 머신으로 실행할 수도 있고 여러 머신으로 분할할 수도 있습니다.한 대의 머신상의 메일에이전트 프로세스는 파일을 공유할 수도 있지만 처리가 여러 대의 머신상에 있는 경우에는 SMTP를 사용하여 서로 메시지를 전송합니다.이 경우 각 머신은 다음 머신을 스마트호스트로 사용하도록 구성됩니다.각 프로세스는 그 자체로 MTA(SMTP 서버)입니다.

경계 MTA는 DNS를 사용하여 수신자의 도메인에 대한 MX(메일 교환기) 레코드(오른쪽 전자 메일 주소의 일부)를 검색합니다.@MX 레코드에는 대상 MTA의 이름이 포함되어 있으며, 송신측 MTA는 대상 호스트 및 기타 요인에 따라 수신인 서버를 선택하여 접속하여 메일 교환을 완료합니다.

메시지 전송은 2개의 MTA 간의 단일 연결 또는 중간 시스템을 통한 일련의 홉으로 발생할 수 있습니다.수신측 SMTP 서버는, 최종 수신처, 중간 「릴레이」(메시지를 보존해 전송) 또는 「게이트웨이」(SMTP 이외의 프로토콜을 사용해 메세지를 전송 할 수 있습니다).RFC 5321 섹션 2.1에 따르면 각 홉은 메시지에 대한 책임의 정식 핸드오프입니다.이것에 의해, 수신측 서버는 메시지를 전달하거나, 그 실패를 적절히 보고할 필요가 있습니다.

최종 홉은 착신 메시지를 수신하면 로컬 전송을 위해 Mail Delivery Agent(MDA; 메일 배달 에이전트)에 메시지를 전달합니다.MDA는 메시지를 관련 우편함 형식으로 저장합니다.송신과 같이, 1대 또는 복수의 컴퓨터를 사용해 수신할 수 있지만, 상기의 그림에서는, MDA는 메일 교환기 박스 부근에 1개의 박스로 표시되어 있습니다.MDA는 SMTP(Local Mail Transfer Protocol) 또는 이를 위해 설계된 SMTP(Local Mail Transfer Protocol)와 같은 다른 프로토콜을 사용하여 메시지를 스토리지에 직접 전달하거나 네트워크를 통해 전송할 수 있습니다.

로컬 메일 서버로 배달된 메일은 MUA(인증된 메일 클라이언트)에 의해 일괄 검색되도록 저장됩니다.메일은 메일 접근을 용이하게 하고 저장된 메일을 관리하는 프로토콜인 IMAP(Internet Message Access Protocol) 또는 일반적으로 mbox 메일 파일 형식 또는 Microsoft Exchange/Outlook 또는 Lotus No와 같은 자체 시스템을 사용하는 POP(Post Office Protocol)를 사용하여 전자 메일 클라이언트라고 불리는 최종 사용자 애플리케이션에 의해 검색됩니다.테스/도미노웹 메일 클라이언트는 두 가지 방법을 모두 사용할 수 있지만, 검색 프로토콜은 종종 공식적인 표준이 아닙니다.

SMTP는 메시지 내용이 아닌 메시지 전송을 정의합니다.따라서 메일 봉투 및 봉투 발송인 등의 매개 변수를 정의하지만 헤더(트레이스 정보 제외)나 메시지 본문 자체는 정의하지 않습니다.STD 10 및 RFC 5321은 SMTP(엔벨로프)를 정의하고 STD 11 및 RFC 5322는 메시지(헤더 및 본문)를 정의합니다.이 메시지는 정식으로 인터넷메시지 형식이라고 불립니다.

프로토콜 개요

SMTP는 메일 발송인이 신뢰할 수 있는 순서 데이터 스트림 채널(일반적으로 Transmission Control Protocol(TCP) 연결)을 통해 명령 문자열을 발행하고 필요한 데이터를 제공함으로써 메일 수신자와 통신하는 연결 지향 텍스트 기반 프로토콜입니다.SMTP 세션은 SMTP 클라이언트(발신측 에이전트, 송신측 또는 송신측)가 발신한 명령어와 SMTP 서버(리슨 에이전트 또는 수신측)로부터의 대응 응답으로 구성되어 세션파라미터가 교환됩니다.세션에는 0개 이상의 SMTP 트랜잭션을 포함할 수 있습니다.SMTP 트랜잭션은 다음 3개의 명령어/응답 시퀀스로 구성됩니다.

  1. MAIL 명령: 리턴 주소를 확립하기 위한 명령어로 리턴 패스,[17] 리버스 패스,[18] 바운스 주소, mfrom 또는 엔벨로프 송신이라고도 불립니다.
  2. 메시지 수신인을 확립하기 위한 RCPT 명령어.이 명령어는 수신자마다 하나씩 여러 번 실행할 수 있습니다.이러한 주소도 봉투의 일부입니다.
  3. 메시지 텍스트의 시작을 알리는 DATA.메시지 내용은 봉투가 아닙니다.메시지 헤더와 메시지 본문은 빈 행으로 구분되어 있습니다.DATA는 실제로 명령어 그룹입니다.서버는 DATA 명령어 자체에 대해 1회 응답하여 텍스트를 수신할 준비가 되었음을 확인하고 두 번째 응답은 데이터 종료 시퀀스에 이어 메시지 전체를 받아들이거나 거부합니다.

DATA에 대한 중간 응답 외에 각 서버의 응답은 긍정(2xx 응답 코드) 또는 부정(2xx 응답 코드) 중 하나입니다.부정 응답은 영속적(5xx 코드) 또는 일시적(4xx 코드)입니다.거부는 영구적인 장애이므로 클라이언트는 거부 메시지를 받은 서버로 바운스 메시지를 보내야 합니다.드롭은 긍정적인 응답이며, 그 후 전달이 아닌 메시지 폐기입니다.

개시 호스트인 SMTP 클라이언트는 최종 사용자의 전자 메일클라이언트(기능적으로 Mail User Agent(MUA; 메일 사용자 에이전트)로 식별됨) 또는 릴레이 서버의 메일 전송 에이전트(MTA; 메일 전송 에이전트) 중 하나이며, 관련 세션에서 SMTP 클라이언트로서 기능하는 SMTP 서버로서 메일을 릴레이하기 위한 것입니다.완전한 기능을 갖춘 SMTP 서버는 일시적인 장애를 초래한 메시지 전송을 재시도하기 위한 메시지 큐를 유지합니다.

MUA 는, 발신 메일 SMTP 서버를 설정으로부터 인식합니다.릴레이 서버는 일반적으로 각 수신인의 도메인 이름에 대한 MX(Mail eXchange) DNS 리소스 레코드를 검색하여 연결할 서버를 결정합니다.MX 레코드를 찾을 수 없는 경우 적합 릴레이 서버(모든 릴레이 서버가 아닌)가 대신 A 레코드를 검색합니다.릴레이 서버는 스마트호스트를 사용하도록 설정할 수도 있습니다.중계 서버는, SMTP 포토 25 또는 MSA 포토 587 에의 접속을 위해서, 「웰-known port」상의 서버에 TCP 접속을 개시한다.MTA와 MSA의 주요 차이점은 MSA에 접속하려면 SMTP 인증이 필요하다는 것입니다.

SMTP와 메일 검색

SMTP는 전송 프로토콜일 뿐입니다.일반적으로 메일은 도착 시 대상 메일 서버(또는 넥스트 홉 메일 서버)에 "푸시"됩니다.메일은 주소가 지정된 개별 사용자가 아닌 대상 서버에 따라 라우트됩니다.POP(Post Office Protocol) 및 IMAP(Internet Message Access Protocol)와 같은 다른 프로토콜은 메시지를 검색하고 우편함을 관리하는 개별 사용자가 사용하도록 특별히 설계되었습니다.간헐적으로 연결된 메일 서버가 요청 시 원격 서버에서 메시지를 가져올 수 있도록 SMTP에는 원격 서버에서 메일 대기열 처리를 시작하는 기능이 있습니다(아래 원격 메시지 대기열 시작 참조).POP 및 IMAP은 간헐적으로 연결된 기계에 의한 메일 릴레이에 적합하지 않은 프로토콜입니다. 메일 릴레이의 올바른 작동에 중요한 정보("메일 봉투")가 제거되었을 때 최종 전달 후에 작동하도록 설계되었습니다.

원격 메시지 큐 시작

원격 메시지 대기열 시작을 사용하면 원격 호스트가 서버상의 메일 대기열 처리를 시작할 수 있으므로 해당 명령을 전송하여 해당 서버 앞으로 메시지를 수신할 수 있습니다.오리지널TURN 명령어는 안전하지 않다고 간주되어 RFC1985에서 확장되었습니다.ETRN이 명령어는 도메인네임 시스템 [19]정보에 근거한 인증 방식을 사용하여 보다 안전하게 동작합니다.

송신 메일 SMTP 서버

전자 메일 클라이언트는, 초기 SMTP 서버의 IP 주소를 알고 있을 필요가 있습니다.이 주소는, 설정의 일부로서 지정할 필요가 있습니다(통상은 DNS 이름으로 지정됩니다).이 서버는 사용자 대신 발신 메시지를 배달합니다.

발신 메일 서버 액세스 제한

서버 관리자는 서버를 사용할 수 있는 클라이언트를 제어할 필요가 있습니다.이를 통해 스팸과 같은 남용에 대처할 수 있습니다.두 가지 솔루션이 공통적으로 사용되고 있습니다.

  • 과거에는 많은 시스템이 클라이언트의 위치에 따라 사용 제한을 가하고 서버 관리자가 제어하는 IP 주소를 가진 클라이언트의 사용만 허용했습니다.다른 클라이언트 IP 주소로부터의 사용은 허가되지 않습니다.
  • 최신 SMTP 서버에서는 일반적으로 액세스를 허용하기 전에 자격 증명에 의한 클라이언트 인증을 필요로 하는 대체 시스템이 제공됩니다.

위치별 접근 제한

이 시스템에서는 ISP의 SMTP 서버는 ISP의 네트워크 외부에 있는 사용자의 접근을 허용하지 않습니다.보다 정확하게 말하면, 서버는 ISP가 제공하는IP 주소를 가지는 유저에게만 액세스를 허가하는 경우가 있습니다.이것은, 같은 ISP를 사용해 인터넷에 접속할 필요가 있는 것과 같습니다.모바일 사용자는 통상의 ISP 이외의 네트워크에 접속하고 있는 경우가 많아, 설정이 끝난 SMTP 서버에 액세스 할 수 없게 되어, 전자 메일의 송신이 실패하는 것을 알게 됩니다.

이 시스템에는 몇 가지 종류가 있습니다.예를 들어 조직의 SMTP 서버는 같은 네트워크상의 사용자에게만 서비스를 제공할 수 있으며, 이를 위해 방화벽을 설정하여 광범위한 인터넷상의 사용자의 접근을 차단합니다.또는 서버는 클라이언트의 IP 주소에 대해 범위 체크를 실행할 수 있습니다.이러한 방법은, 통상, 조직내에서 사내용으로만 발신 메일용으로 SMTP 서버를 제공하는 기업이나 기관(대학등)에 의해서 사용되고 있습니다.그러나, 이러한 본문의 대부분은, 이하와 같이 클라이언트 인증 방식을 사용하고 있습니다.

유저가 모바일이며, 다른 ISP 를 사용해 인터넷에 접속할 가능성이 있는 경우, 이러한 종류의 사용 제한은 큰 부담이 됩니다.또, 설정되어 있는 발신 전자 메일 SMTP 서버 주소를 변경하는 것은 비현실적입니다.변경할 필요가 없는 전자 메일클라이언트 설정 정보를 사용할 수 있는 것이 매우 바람직합니다.

클라이언트 인증

현대의 SMTP 서버에서는, 통상, 앞에서 설명한 것처럼 로케이션 마다 액세스를 제한하는 것이 아니고, 액세스를 허가하기 전에 credential에 의한 클라이언트의 인증이 필요합니다.이 유연성이 뛰어난 시스템은 모바일 사용자에게 편리하며 설정된 아웃바운드 SMTP 서버를 자유롭게 선택할 수 있습니다.SMTP 인증(SMTP AUTH)은, 인증 메카니즘을 사용해 로그인하기 위한 SMTP 의 확장입니다.

포트

메일 서버간의 통신에는, 일반적으로 SMTP용으로 지정된 표준 TCP 포토 25 가 사용됩니다.

그러나 메일 클라이언트는 일반적으로 이 포트를 사용하지 않고 특정 "제출" 포트를 사용합니다.메일 서비스는 일반적으로 다음 중 하나에 대한 클라이언트의 전자 메일 제출을 받아들입니다.

포트 2525 등은 일부 개별 공급자에 의해 사용될 수 있지만 공식적으로 지원되는 적은 없습니다.

현재 많은 인터넷서비스 공급자가 고객으로부터의 모든 발신 포트 25 트래픽을 차단하고 있습니다.주로 스팸 대책으로서 [20]뿐만 아니라, 개봉을 요구하는 소수의 고객으로부터 더 많은 요금을 청구함으로써 개봉 시 발생하는 높은 비용을 해소하기 위해서도 사용됩니다.

SMTP 전송 예시

SMTP 경유로 같은 메일 도메인(example.com)에 있는2 개의 메일 박스(메시지 및 보스)에 메시지를 송신하는 일반적인 예는, 다음의 세션 교환으로 재현됩니다.(이 예에서는 컨버세이션 부분에는 서버와 클라이언트의 각각 S:와 C:가 붙습니다.이러한 라벨은 교환의 일부가 아닙니다).

메시지 송신자(SMTP 클라이언트)가 메시지 수신자(SMTP 서버)에 대한 신뢰성이 높은 통신 채널을 확립하면, 세션은 서버에 의해서 개시됩니다.보통, 이 경우는 Fully Qualified Domain Name(FQDN; 완전 수식 도메인명)이 격납되어 있습니다.smtp.example.com클라이언트는 다음과 같이 응답함으로써 대화상자를 시작합니다.HELO명령어 파라미터에서 [21]FQDN(또는 사용할 수 없는 경우 주소 리터럴)과 함께 자신을 식별하는 명령어. 

S: 220 smtp.example.com ESMTP Postfix C: HELLO bob@example.org S: 250 Hello relay.example.org, 만나서 반갑습니다.C: MAIL FROM: <alice@example.com> S: 250 OK C: RCPT TO: <theboss@example.com> S: 250 OK C: RCPT TO: <theboss@example.com C: 250 OK C: RCPT>LF>. <CR> <LF> C: 발신인: "Bob Example" <bob@example.org> C: 수신인: "Alice Example" <alice@example.com> C: 참조인: theboss@example.com C: 날짜:2008년 1월 15일 (화) 16:02:43 - 0500 C : 제목 :테스트 메시지 C: C: Hello Alice.C: 메시지 본문에 5개의 헤더필드와 4개의 행이 있는 테스트메시지입니다C: 친구 C: 밥 C: . S: 250 OK: 12345 C: 큐트 S: 221 Bye {서버가 연결을 닫습니다}

클라이언트는 수신자에게 메시지의 발신기지 전자 메일주소를 통지합니다.MAIL FROM명령어를 입력합니다.이 주소는 메시지를 배달할 수 없는 경우의 반송 또는 바운스 주소이기도 합니다.이 예에서는 전자 메일메시지가 같은 SMTP 서버상의2 개의 메일 박스에 송신됩니다.하나는, 에 기재되어 있는 각 수신자에게 송신됩니다.To:그리고.Cc:헤더 필드대응하는 SMTP 명령어는 다음과 같습니다.RCPT TO명령어 수신 및 실행에 성공할 때마다 서버는 결과 코드와 응답 메시지(예:250 Ok).

메일 메시지 본문 전송은 다음 명령어로 시작됩니다.DATA이 명령어는 한 줄 한 줄 전송되며 데이터 종료 시퀀스로 종료됩니다.이 시퀀스는 새로운 행(<CR><LF>, 1회 풀스톱 ( ).) 뒤에 다른 행이 표시됩니다( ).<CR><LF>). 메시지 본문에 마침표만 있는 행을 텍스트의 일부로 포함할 수 있으므로 클라이언트는 마침표로 시작하는 행마다 2개의 마침표를 보냅니다.따라서 서버는 행의 선두에 있는 2개의 마침표의 모든 시퀀스를 1개의 마침표로 바꿉니다.이러한 탈출 방법을 도트 스터핑이라고 합니다.

예시와 같이 서버의 데이터 종료에 대한 긍정적인 응답은 서버가 메시지 전달을 책임지고 있음을 의미합니다.이 때, 예를 들면 전력 부족에 의해 통신 장해가 발생했을 경우, 메세지는 2배로 할 수 있습니다.송신자가 그것을 받을 때까지250 Ok메시지가 전달되지 않은 것으로 가정해야 합니다.한편, 수신자는 메시지를 받아들이기로 결정한 후 메시지가 전달되었다고 가정해야 합니다.따라서 이 기간 동안 두 에이전트 모두 [22]전달하려고 하는 메시지의 활성 복사본을 가집니다.이 단계에서 정확히 통신 장애가 발생할 확률은 서버가 메시지 본문에서 실행하는 필터링 양에 정비례합니다.대부분의 경우 안티스팸을 목적으로 합니다.제한 타임아웃은 10분으로 [23]지정되어 있습니다.

그QUIT명령어를 실행하면 세션이 종료됩니다.이메일에 다른 수신자가 있는 경우 클라이언트는QUIT현재 수신처가 큐잉된 후 후속 수신인을 위해 적절한 SMTP 서버에 연결합니다.클라이언트가 에 송신하는 정보HELO그리고.MAIL FROM명령어는 수신 서버에 의해 메시지에 추가 헤더필드로 추가됩니다(예시 코드에서는 표시되지 않습니다).가 추가된다.Received그리고.Return-Pathheader 필드입니다.

일부 클라이언트는 메시지가 수신된 후 연결을 종료하도록 구현됩니다(250 Ok: queued as 12345마지막 2행은 생략할 수 있습니다.이것에 의해, 송신시에 서버에 에러가 발생합니다.221 Bye답글.

SMTP 확장

확장 디스커버리 메커니즘

클라이언트는 다음을 사용하여 서버의 지원되는 옵션을 학습합니다.EHLO아래 예시와 같이 원본 대신 인사말HELO클라이언트는 다음 단계로 넘어갑니다.HELO서버가 지원하지 않는 경우에만EHLO인사말입니다.[24]

최신 클라이언트에서는 ESMTP 확장 키워드를 사용할 수 있습니다.SIZE서버에 허용할 최대 메시지 크기를 쿼리합니다.오래된 클라이언트 및 서버는 네트워크 리소스를 소비한 후 거부되는 과도한 크기의 메시지를 전송하려고 할 수 있습니다.여기에는 [25]분 단위로 지불되는 네트워크 링크에 접속하는 시간도 포함됩니다.

사용자는 ESMTP 서버에서 허용되는 최대 크기를 수동으로 미리 결정할 수 있습니다.클라이언트에 의해,HELO을 지휘하다EHLO명령어를 입력합니다. 

S: 220 ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-Size 14680064 S: 250-PIPELING S: 250 도움말

따라서 smtp2.example.com은 14,680,064 옥텟(8비트바이트) 이하의 고정 최대 메시지사이즈를 받아들일 수 있다고 선언합니다.

가장 간단한 경우 ESMTP 서버가 최대값을 선언합니다.SIZE받은 직후에EHLO 단, RFC 1870에 따르면 RFC 1870의 수치 파라미터는SIZE내선번호EHLO응답은 옵션입니다.클라이언트는, 대신에, 다음의 명령어를 발행할 때,MAIL FROM서버가 너무 큰 메시지의 수신을 거부할 수 있도록 전송 중인 메시지의 크기를 수치로 추정합니다.

바이너리 데이터 전송

원래의 SMTP 는 ASCII 텍스트의 단일 본문만을 서포트하고 있기 때문에, 바이너리 데이터는, 전송 전에 메시지의 본문에 텍스트로서 부호화해, 수신자가 디코딩 할 필요가 있습니다.일반적으로 uuencode 및 BinHex와 같은 바이너리-to-text 인코딩이 사용되었습니다.

이 문제를 해결하기 위해 8BITMIME 명령어가 개발되었습니다.1994년에 RFC 1652로[26] 표준화되었습니다.7비트 ASCII 문자 세트 이외의 옥텟을 포함한 전자 메일메시지를 통상 Base64로 부호화된 MIME 콘텐츠 부품으로 부호화함으로써 투과적인 교환을 용이하게 합니다.

메일 배달 메커니즘 확장자

주문형 메일 릴레이

주요 기사:주문형 메일 릴레이

On-Demand Mail Relay(ODMR; 온디맨드 메일 릴레이)는 RFC 2645에서 표준화된SMTP 확장입니다이 확장에서는 간헐적으로 접속된SMTP 서버가 접속 시 큐에 있는 전자 메일을 수신할 수 있습니다.

국제화 확장

주요 기사:국제 이메일

원래 SMTP는 ASCII 문자로만 구성된 이메일 주소를 지원하므로 네이티브스크립트가 라틴어 기반이 아니거나 ASCII 문자 집합이 아닌 분음 부호를 사용하는 사용자에게 불편합니다.이 제한은, 주소명으로 UTF-8 를 유효하게 하는 내선 번호에 의해서 완화되었습니다.RFC5336에서 도입된[25] 시험판 UTF8SMTP 명령어 이후가 RFC6531로 대체되었습니다.SMTPUTF8명령어를 입력합니다.이러한 확장은 멀티바이트 및 비ASC를 지원합니다.분음 부호가 있는 문자 등 전자 메일 주소의 II 문자 및 그리스어 및 [27]중국어 등의 기타 언어 문자.

현재 지원은 한정되어 있지만, 라틴어(ASCII)가 외국어 스크립트인 대규모 사용자 기반을 가진 중국 등지에서 RFC 6531 및 관련 RFC를 폭넓게 채택하는 것에 대한 관심이 높아지고 있습니다.

내선번호

SMTP와 마찬가지로 ESMTP는 인터넷 메일을 전송하는 데 사용되는 프로토콜입니다.서버 간 전송 프로토콜과 (제한된 동작이 적용된) 메일 제출 프로토콜로 사용됩니다.

ESMTP 클라이언트의 주요 식별 기능은 명령어를 사용하여 전송을 여는 것입니다.EHLO(확장 HELLO),HELO (Hello, 원래의 RFC821 규격).서버는 설정에 따라 성공(코드 250), 실패(코드 550) 또는 오류(코드 500, 501, 502, 504 또는 421)로 응답합니다.ESMTP 서버는 도메인 및 지원되는 내선번호를 나타내는 키워드 목록과 함께 코드 250 OK를 여러 줄 응답으로 반환합니다.RFC 821 준거 서버는 에러 코드 500을 반환하므로 ESMTP 클라이언트는 다음 중 하나를 시도할 수 있습니다.HELO또는QUIT.

각 서비스 내선번호는 후속 RFC에서 승인된 형식으로 정의되며 Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호 기관)에 등록됩니다.첫 번째 정의는 RFC 821 옵션서비스입니다SEND,SOML(송신 또는 우편),SAML(발송 및 우편),EXPN,HELP,그리고.TURN추가 SMTP 동사의 형식이 설정되었고, 새로운 파라미터에 대해서는MAIL그리고.RCPT.

현재 사용되는 비교적 일반적인 키워드(모든 키워드가 명령어에 대응하는 것은 아닙니다)는 다음과 같습니다.

ESMTP 형식은 RFC2821(RFC 821을 대체)에 다시 기술되어 2008년에 RFC5321의 최신 정의로 갱신되었습니다.에 대한 지원EHLO서버의 명령어가 필수화되었습니다.HELO필수 폴백을 지정했습니다.

비표준, 미등록 서비스 내선번호는 쌍무계약으로 사용할 수 있습니다.이러한 서비스는,EHLO"X"로 시작하는 메시지 키워드 및 이와 유사한 추가 매개 변수 또는 동사를 표시합니다.

SMTP 명령어는 대소문자를 구분하지 않습니다.여기서는 강조하기 위해서만 대문자로 표시됩니다.특정 대문자의 방식이 필요한 SMTP 서버는 표준 위반입니다.[citation needed]

8비트 타임

적어도 다음 서버는 8BITMIME 확장을 어드버타이즈합니다.

다음 서버는 8BITMIME을 애드버타이즈하도록 구성할 수 있지만 8B 이외의 서버에 접속할 때는 8비트 데이터를 7비트로 변환하지 마십시오.ITMIME 릴레이:

  • 8비트 데이터를 비8B로 릴레이하려고 할 때 Exim과 qmail은 8비트 메시지를 7비트로 변환하지 않습니다.ITMIME 피어([31]RFC가 요구하는 대로).거의 모든 최신 메일 릴레이가 8비트 [32]클린 상태이기 때문에 실제로 문제가 발생하지 않습니다.
  • Microsoft Exchange Server 2003은 디폴트로 8BITMIME을 애드버타이즈하지만, 8B 이외의 것으로 릴레이 합니다.ITMIME 피어 결과 바운스가 발생합니다.이것은 RFC 6152 섹션3에서 허용됩니다.

SMTP-AUTH

주요 기사: SMTP 인증

SMTP-AUTH 확장은 액세스컨트롤 메커니즘을 제공합니다.이것은 클라이언트가 메일을 발송하는 동안 메일 서버에 효과적으로 로그인하는 인증 단계로 구성됩니다.SMTP-AUTH 를 서포트하는 서버는, 통상은, 클라이언트에 이 내선 번호를 사용하도록 설정할 수 있기 때문에, 송신자의 진정한 ID 가 인식되고 있습니다.SMTP-AUTH 확장은 RFC 4954에 정의되어 있습니다.

SMTP-AUTH 를 사용하면, 정규 유저가 스팸 송신자등의 부정 유저에 대한 릴레이 서비스를 거부하면서, 메일을 릴레이 할 수 있습니다.SMTP 엔벨로프 송신원 또는 RFC 2822 「From:」헤더의 신뢰성을 보증할 필요는 없습니다.예를 들어, SMTP-AUTH 에서는, 1 개의 송신자가 다른 유저로 위장하는 스푸핑은, 송신원주소를 이 AUTHed 유저에게 허가된 주소로 제한하도록 서버가 설정되어 있지 않는 한 가능합니다.

또, SMTP-AUTH 확장을 사용하면, 메일 릴레이시에 송신자가 인증되고 있는 것을 메일 서버에 통지할 수 있습니다.일반적으로는, 수신측 서버가 송신측 서버를 신뢰할 필요가 있습니다.즉,[citation needed] SMTP-AUTH 의 이 측면은 인터넷상에서 거의 사용되지 않습니다.

SMTPUTF8

지원되는 서버는 다음과 같습니다.

보안 확장

메일 배달은 일반 텍스트와 암호화된 연결을 통해 모두 수행될 수 있지만, 통신 당사자는 다른 당사자가 보안 채널을 사용할 수 있는지 미리 알지 못할 수 있습니다.

STARTTLS 또는 "Opportunistic TLS"

주요 기사:기회주의적인 TLS 및 이메일 암호화

STARTTLS 확장을 사용하면 SMTP 서버가 TLS 암호화 통신을 지원함을 접속하고 있는 클라이언트에 통지할 수 있습니다.또, STARTTLS 커맨드를 송신하는 것으로, 클라이언트는 접속을 업그레이드할 수 있습니다.TLS 암호화 세션으로의 업그레이드는 접속 클라이언트가 이 옵션을 실행하는 것에 의존하기 때문에 확장을 지원하는 서버는 그 자체로는 보안상의 이점을 얻을 수 없습니다.따라서 TLS라는 용어를 사용합니다.

STARTTLS 네고시에이션은 플레인텍스트로 이루어지기 때문에 STARTTLS는 패시브 관찰 공격에 대해서만 유효합니다.액티브 공격자는 STARTTLS 명령을 삭제할 수 있습니다.이러한 유형의 man-in-the-middle 공격은 STRIPTLS라고 불리기도 합니다.이 공격에서는 한쪽 끝에서 송신되는 암호화 네고시에이션 정보가 다른 쪽 끝에는 도달하지 않습니다.이 시나리오에서는 양쪽 당사자가 무효 또는 예기치 않은 응답을 상대방이 STARTTLS를 제대로 지원하지 않고 기본적으로 기존의 일반 텍스트 메일 [41]전송으로 간주합니다.STARTTLS는 다른 RFC에서도 IMAP 및 POP3용으로 정의되어 있습니다만, 이러한 프로토콜의 목적은 다릅니다.SMTP는 메시지 전송 에이전트 간의 통신에 사용되며 IMAP 및 POP3는 엔드 클라이언트 및 메시지 전송 에이전트용입니다.

2014년에 Electronic Frontier Foundation은 "HTTPS Everywhere" 목록과 유사하게 "STARTTLS Everywhere" 프로젝트를 시작했습니다. 이 프로젝트는 "HTTPS Everywhere" 목록과 마찬가지로 신뢰할 수 있는 당사자가 사전 커뮤니케이션 없이 안전한 통신을 지원하는 다른 당사자를 발견할 수 있도록 지원합니다.프로젝트는 2021년 4월 29일에 제출 접수를 중지하였으며, EFF는 피어 TLS [42]지원에 대한 정보를 찾기 위해 DANE 및 MTA-STS로 전환할 것을 권장하였다.

RFC 8314는 플레인텍스트가 폐지되었다고 공식적으로 선언하고 항상 TLS를 사용하여 암묵적인 TLS를 가진 포트를 추가할 것을 권장합니다.

SMTP MTA의 엄격한 트랜스포트랜스포트 보안

새로운 2018년 RFC 8461 "SMTP MTA Strict Transport Security (MTA-STS)"는 메일 서버가 서버 및 특정 DNS TXT 레코드의 특정 파일에 보안 채널을 사용할 수 있음을 선언하는 프로토콜을 정의함으로써 활성 적대국 문제에 대처하는 것을 목표로 합니다.의존 당사자는 정기적으로 이러한 레코드의 존재를 체크하고 레코드에 지정된 시간 동안 캐시하며 레코드가 [41]만료될 때까지 안전하지 않은 채널을 통해 통신하지 않습니다.MTA-STS 레코드는 메일 서버 간의 SMTP 트래픽에만 적용되지만 사용자의 클라이언트와 메일 서버 간의 통신은 조직 또는 기술 정책과 함께 SMTP/MSA, IMAP, POP3 또는 HTTPS를 사용하여 트랜스포트 계층 보안에 의해 보호됩니다.기본적으로 MTA-STS는 이러한 정책을 제3자에게 확장하는 수단입니다.

2019년 4월 구글 메일은 MTA-STS [43]지원을 발표했습니다.

SMTP TLS 리포트

메시지를 안전하게 전달하도록 설계된 프로토콜은 잘못된 구성이나 의도적인 활성 간섭으로 인해 실패하여 메시지가 전달되지 않거나 암호화되지 않거나 인증되지 않은 채널을 통해 전달될 수 있습니다.RFC 8460 "SMTP TLS Reporting"에서는 통계정보 및 잠재적인 장애에 대한 특정 정보를 수신자 도메인과 공유하기 위한 보고서 메커니즘 및 형식에 대해 설명합니다.수신자 도메인은 이 정보를 사용하여 잠재적인 공격을 검출하고 의도하지 않은 잘못된 설정을 진단할 수 있습니다.

2019년 4월 Google Mail은 SMTP TLS [43]Reporting 지원을 발표했습니다.

스푸핑 및 스팸 처리

주요 기사:안티스팸 기술 및 이메일 인증

SMTP 의 원래 설계에는, 송신자를 인증하는 기능이나, 송신자를 대신해 송신하도록 서버가 허가되고 있는 것을 확인할 수 있는 기능이 없었습니다.그 결과, 전자 메일 스푸핑이 가능해져, 전자 메일 스팸이나 피싱에 일반적으로 사용됩니다.

SMTP 를 광범위하게 변경하거나 완전하게 치환하는 제안이 가끔 있습니다.예를 들어 Internet Mail 2000은 기존 SMTP의 대규모 설치 기반에 따른 네트워크 효과로 인해 큰 진전을 이루지 못했습니다.

대신 메일 서버는 RFC 5322,[44][45] DomainKeys Identified Mail, Sender Policy Framework 및 DMARC, DNSBL 등의 표준을 보다 엄격하게 적용하고 의심스러운 전자 [46]메일을 거부 또는 검역하는 그레이리스트 등 다양한 기술을 사용합니다.

실장

주요 기사:메일 서버 소프트웨어 목록 및 메일 서버 비교

관련 코멘트 요청

  • RFC 1123 – 인터넷호스트 요건 - 응용 프로그램 및 지원 (STD 3)
  • RFC 1870 – 메시지사이즈 선언용 SMTP 서비스 확장 (© bsolees: RFC 1653)
  • RFC 2505 - SMTP MTA의 안티스팸 권장사항(BCP 30)
  • RFC 2821 – Simple Mail Transfer Protocol (심플 메일 전송 프로토콜)
  • RFC 2920 - 명령 파이프라인용 SMTP 서비스 확장(STD 60)
  • RFC 3030 – 대용량 및 바이너리 MIME 메시지 전송을 위한 SMTP 서비스 확장
  • RFC 3207 - 시큐어 SMTP over Transport Layer Security를 위한 SMTP 서비스 확장(RFC 2487 폐지)
  • RFC 3461 - 전달 상태 알림을 위한 SMTP 서비스 확장(RFC 1891의 보고)
  • RFC 3463 - SMTP 확장 상태 코드(RFC 1893 발표, RFC 5248에 의해 갱신)
  • RFC 3464 – 전달 상태 알림용 확장 가능한 메시지 형식(RFC 1894 발표)
  • RFC 3798 – 메시지 발송 통지(RFC 3461 업데이트)
  • RFC 3834 – 전자 메일에 대한 자동 응답에 관한 권장 사항
  • RFC 3974 - IPv4/v6 혼재 환경에서의 SMTP 운용 경험
  • RFC 4952 – 국제화 이메일의 개요와 프레임워크 (RFC 5336에 의해 갱신)
  • RFC 4954 - 인증을 위한 SMTP 서비스 확장(RFC 2554, RFC 3463 업데이트, RFC 5248 업데이트)
  • RFC 5068 – 이메일 전송 작업:접근 및 설명의 요건(BCP 134)
  • RFC 5248 – SMTP 확장 메일시스템 상태 코드 레지스트리(BCP 138) (RFC 3463 업데이트)
  • RFC 5321 – Simple Mail Transfer Protocol (RFC 821 일명 STD 10, RFC 974, RFC 1869, RFC 2821, RFC 1123 업데이트)
  • RFC 5322 - 인터넷메시지 포맷 (RFC 822, 일명 STD 11 및 RFC 2822를 폐지)
  • RFC 5504 - 이메일주소 국제화를 위한 다운그레이드 메커니즘
  • RFC 6409 – Message Submission for Mail (STD 72) (RFC 4409, RFC 2476 폐지)
  • RFC 6522 - 메일시스템 관리 메시지 보고서용 멀티파트/리포트 콘텐츠유형(RFC 3462 및 RFC 1892에 준거)
  • RFC 6531 - 국제화 이메일주소의 SMTP 확장(RFC 2821, RFC 2822, RFC 4952, 및 RFC 536)
  • RFC 8314 – 구식으로 간주되는 클리어 텍스트:전자 메일 전송 및 액세스를 위한 TLS(Transport Layer Security) 사용

「 」를 참조해 주세요.

메모들

  1. ^ 전자 메일의 역사, Tom Van Vleck: "이 프로토콜이 구현된 적이 없습니다."
  2. ^ 첫 번째 네트워크 이메일, Ray Tomlinson, BBN
  3. ^ PDP-10 Dan Murphy의 "The First Email Computer" 그림
  4. ^ 2007년 11월 18일 Wayback Machine에서 아카이브된 Dan Murphy의 TENEX 및 TOPS-20 문서
  5. ^ RFC 524 – 제안된 메일 프로토콜
  6. ^ Crocker, David H. (December 1977). "Framework and Functions of the "MS" Personal Message System" (PDF). The RAND Corporation.
  7. ^ RFC 469 - 네트워크 메일 회의의 개요
  8. ^ RFC 733, 1977년 11월 21일, ARPA 네트워크 텍스트 메시지 포맷 표준
  9. ^ "Tldp.org".
  10. ^ "draft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project".
  11. ^ 송신원 개서에 관한 문서에는, RFC 1123 이전의 초기 SMTP 이력 및 송신원라우팅에 관한 기술적인 배경 정보가 기재되어 있습니다.
  12. ^ Eric Allman (1983), Sendmail – An Internetwork Mail Router (PDF), BSD UNIX documentation set, Berkeley: University of California, retrieved June 29, 2012
  13. ^ Craig Partridge (2008), The Technical Development of Internet Email (PDF), IEEE Annals of the History of Computing, vol. 30, IEEE Computer Society, pp. 3–29, doi:10.1109/MAHC.2008.32, S2CID 206442868, archived from the original (PDF) on May 12, 2011
  14. ^ Paul Hoffman (February 1, 1998). "Allowing Relaying in SMTP: A Survey". Internet Mail Consortium. Retrieved May 30, 2010.
  15. ^ Paul Hoffman (August 2002). "Allowing Relaying in SMTP: A Series of Surveys". Internet Mail Consortium. Archived from the original on January 18, 2007. Retrieved May 30, 2010.
  16. ^ "In Unix, what is an open mail relay? - Knowledge Base". June 17, 2007. Archived from the original on June 17, 2007. Retrieved March 15, 2021.
  17. ^ "MAIL, RCPT 및 DATA 동사", [D. J. Bernstein]
  18. ^ RFC 5321 섹션-7.2
  19. ^ Systems, Message. "Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities". www.prnewswire.com. Retrieved July 19, 2020.
  20. ^ Cara Garretson (2005). "ISPs Pitch In to Stop Spam". PC World. Retrieved January 18, 2016. Last month, the Anti-Spam Technical Alliance, formed last year by Yahoo, America Online, EarthLink, and Microsoft, issued a list of antispam recommendations that includes filtering Port 25.
  21. ^ RFC 5321, Simple Mail Transfer Protocol, J. Klensin, The Internet Society (2008년 10월)
  22. ^ RFC 1047
  23. ^ "rfc5321#section-4.5.3.2.6".
  24. ^ John Klensin; Ned Freed; Marshall T. Rose; Einar A. Stefferud; Dave Crocker (November 1995). SMTP Service Extensions. IETF. doi:10.17487/RFC1869. RFC 1869.
  25. ^ a b "MAIL Parameters". IANA. February 14, 2020.
  26. ^ 2011년에 RFC 6152에 의해 폐지되어 당시 새로운 STD 71에 대응하고 있습니다.
  27. ^ Jiankang Yao (December 19, 2014). "Chinese email address". EAI (Mailing list). IETF. Retrieved May 24, 2016.
  28. ^ "SMTP Service Extension Parameters". IANA. Retrieved November 5, 2013.
  29. ^ 제임스 서버 - Change Log.James.apache.org 를 참조해 주세요.2013-07-17에 회수.
  30. ^ 8BITMIME 서비스가 gmail-smtp-in.l.google.com 포트 25에서 EHLO에 응답하여 애드버타이즈되었습니다(2011년 11월 23일 체크).
  31. ^ Qmail 버그와 위시리스트Home.pages.de 를 참조해 주세요.2013-07-17에 회수.
  32. ^ 8BITMIME 확장자Cr.yp.to 를 참조해 주세요.2013-07-17에 회수.
  33. ^ "Postfix SMTPUTF8 지원은 기본적으로 실행됩니다.", 2015년 2월 8일, postfix.org
  34. ^ "Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities" (Press release).
  35. ^ "Version 6.2 Revision History". CommuniGate.com.
  36. ^ Sam Varshavchik (September 18, 2018). "New releases of Courier packages". courier-announce (Mailing list).
  37. ^ "Halon MTA changelog". GitHub. November 9, 2021. v4.0: New SMTPUTF8 support 새 버전에 맞게 업데이트됨
  38. ^ "MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions". July 24, 2018.
  39. ^ "EAI Readiness in TLDs" (PDF). February 12, 2019.
  40. ^ "Communications Messaging Server Release Notes". oracle.com. October 2017.
  41. ^ a b "Introducing MTA Strict Transport Security (MTA-STS) Hardenize Blog". www.hardenize.com. Retrieved April 25, 2019.
  42. ^ "STARTTLS Everywhere". EFF. Retrieved December 4, 2021.
  43. ^ a b Cimpanu, Catalin. "Gmail becomes first major email provider to support MTA-STS and TLS Reporting". ZDNet. Retrieved April 25, 2019.
  44. ^ "Message Non Compliant with RFC 5322".
  45. ^ "Message could not be delivered. Please ensure the message is RFC 5322 compliant".
  46. ^ "Why are the emails sent to Microsoft Account rejected for policy reasons?".

레퍼런스

외부 링크