SMTP프로토콜에 관한 정리 RFC 281, 2821 문서를 바탕으로 정리하였습니다.

1. SMTP
RFC 821 - Simple Mail Transfer Protocol (Obsoleted)
RFC 2821 - Simple Mail Transfer Protocol
2014-03-14
김주아

2. RFC 821
(1982)
Simple M
ail Transfe
r Protocol
RFC 974
(1986)
Mail routi
ng and th
e domain
system
RFC 1869
(1995)
SMTP Ser
vice Exten
sions
RFC 2821
(2001)
Internet
Message
Format
RFC 5321
(2008)
Simple M
ail Transfe
r Protocol
History of SMTP

3. Simple Mail Transfer Protocol
SMTP의 목적
메일을 믿을 수 있고 효율적으로 전송하기 위함
순서화된 데이터 스트림만 있으면 가능
SMTP의 중요한 특징
• 네트워크상에서 메일 릴레이를 통해 전송이 가능
• 같은 네트워크 뿐만 아니라 다른 네트워크간에서도 릴레이나 게이트웨이를 이용하여
전송 가능
• 도메인 네임 시스템의 Mail eXchanger 메커니즘을 통해 다음 목적지의 주소를 파악

4. 도메인 네임 시스템의 Mail eXchanger 메커니즘
MX 레코드란?
특정 도메인에 대한 메일을 수신하는 메일 서버를 지정하는 레코드.
어떤 도메인에 mx레코드로 받을 메일 서버를 지정하면 그 도메인으로 오는 메일은 받을 메일 서버로 전달.
A레코드란?
A레코드는 사용자의 도메인 혹은 하위 도메인에 IP주소를 지정하는 기능을 수행합니다.
MX 레코드
A 레코드

5. SMTP MODEL – Terminology
Mail Objects : SMTP는 메일 객체를 전송하고, 메일 객체는 envelope와 content를 포함
• envelope : 보내는 사람의 주소, 받는 사람들의 주소, 부가적인 확장 프로토콜 관련 내용을 포함
• content : 헤더와 바디로 구성되는 메일의 내용
MTA(Mail Transfer Agents) : SMTP 서버와 클라이언트와 같이 메일 전송 서비스를 제공하는 시스템
MUA or UA(Mail User Agents) : 메일의 보내는 사람, 받는 사람이 사용하는 프로그램
Host : 인터넷 또는 개인 TCP/IP 네트워크에 연결되어 SMTP 프로토콜을 제공하는 컴퓨터 시스템
도메인 네임으로 표현되고, 숫자로 된 주소로 표현하는 것은 추천하지 않는다.
Originator : 메일을 인터넷 또는 전송 서비스 환경에 올리는 시스템이다.
Delivery : 메일을 전송 서비스 환경으로부터 받아서 MUA로 보내거나 MUA에서 접근할 수 있는 저
장소에 전달
Relay : SMTP client로부터 메일을 받아서 내용을 수정하지 않고 추적 정보만 추가하여 다른 SMTP
서버로 보냄
Gateway : 하나의 전송 환경으로부터 메일을 받아서 다른 프로토콜을 가지는 전송 환경으로 보냄
Message Content and Mail Data:
DATA 명령이 받아들여진 후로부터 데이터 끝까지의 내용.
헤더와 바디를 포함하고, 구조화된 메시지 바디는 MIME 형태를 따름
Mailbox : 메일의 저장소
Address : 메일이 보내지거나 저장될 위치를 가리키는 문자열이다. local-part@domain

6. Mail Object
MUA
Delivery
Originater
Relay

7. SMTP MODEL – Basic Structure
SMTP 클라이언트가 전송할 메시지가 있으면 SMTP 서버와 양방향 전송 채널을 형성
서버클라이언트
명령전송
응답전송 서버
서버
서버
서버의 역할
릴레이 :
메시지를 받으면 SMTP 클라이언트의 역할을 함
게이트웨이 :
SMTP가 아닌 다른 프로토콜을 통해 메시지가 전달하는 관문
Senders and Receivers
• RFC821에서는 SMTP-sender, SMTP-receiver로 표현했으나,
• 2821에서는 SMTP client, SMTP server로 표현한다.

8. SMTP MODEL – Mail Transactions
Relaying
SMTP Client SMTP Server
SMTP Client SMTP Server
Gateway

9. Relaying
일반적으로 도메인 네임 시스템의 Mail eXchanger 레코드를 사용하면 명시적인 source route를 사용할 필
요가 없다.
메일의 중계를 받아들이면 서버는 SMTP 클라이언트가 되고, DNS에 지정된 다음 SMTP 서버와 전송 채널
을 형성한 후 메일을 보낸다.
SMTP 서버가 메일 중계의 책임을 수락한 후에 나중에 목적지가 잘못되었거나 다른 이유로 인하여 메일
을 배달할 수 없는 경우가 있는데, 이 경우 반드시 배달할 수 없는 메일이라는 알림 메시지를 메일의 첫 발
신자에게 전송해야 한다.
에러 보고에서 루프를 막기 위한 한 가지 방법은 알림 메시지의 MAIL 명령어에 reverse-path를 널로 설정
하는 것이다.
MAIL FROM:<>
목적지 서버로 메일을 전달하기 위해 여러 메일 서버를 거쳐서 전달하는 것.
SMTP Client SMTP Server
SMTP Client SMTP Server

10. Step 1 -- Source Host to Relay Host•
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
EXAMLE - Relayed Mail Scenario (명시적 source route)
Step 2 -- Relay Host to Destination Host•
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
forward-path에서 reverse-path의 처음으로 옮긴다.
JQP@bar.com 에서 Foo.com을 거쳐 Jones@xyz.com 로 전송

11. Mail Gatewaying
Header Fields in Gatewaying
• 메시지가 메일 환경의 경계를 가로지를 때 헤더 필드가 새로 작성될 수 있음
• 보통 RFC822 헤더를 사용하지만, 몇몇 메일 시스템은 SMTP envelope에 해당하는 내용이 없는
경우도 있기 때문에 메시지가 인터넷 환경을 떠날 때 메시지 헤더에 SMTP envelope 정보를 넣
는 경우도 있음
Received Lines in Gatewaying
• 메시지를 인터넷 환경 내부 또는 외부로 전달하는 경우 게이트웨이는 반드시 "Received:" 라인
을 삽입해야 하지만 이미 헤더에 있는 "Received:" 라인을 변경하면 안 된다.
Envelopes in Gatewaying
• 다른 환경에서 인터넷으로 메일을 전송할 때 게이트웨이는 에러 메시지를 전달할 return path
를 설정해야 한다.
• 외부 환경에 비슷한 개념이 없는 경우 게이트웨이는 메시지 최초 발신자의 주소를 기본값으로
사용하여 최적의 근사값을 선택해야 한다.
SMTP 서버가 다른 전송 서비스로 메일을 전송 할 때 두 개의 전송 시스템 환경 사이에서 메일을
포맷에 맞게 변환해야 하는 시스템

12. SMTP MODEL – Procedure
Session Initiation
SMTP 세션은 클라이언트가 서버에 연결하고 서버가 오프닝 메시지를 응답으로 보낼 때 초
기화된다.
Client Initiation
서버가 환영 메시지를 보내고 클라이언트가 그것을 받으면, 클라이언트는 EHLO 명령을 서버에 보냄
EHLO 명령은 세션을 열면서 클라이언트가 서비스 확장을 사용할 수 있는지를 서버에게 알려 주고 서버에
게 지원 가능한 확장 목록을 요청
EHLO을 지원하지 않는 경우 HELO 명령을 사용해야 하고 서버 또한 HELO 응답을 해야 한다.

13. SMTP MODEL – Mail Transactions
MAIL
RCPT
DATA
보내는 사람의 정보를 제공
메일의 내용을 제공하고 "end of mail" 식별자
<CRLF>.<CRLF> 로 트랜잭션을 끝냄
받는 사람의 정보를 제공
수신자가 여러명인 경 우 해당 명령어를 반복하여 수행
MAIL FROM:<reverse-path> [ SP <mail-parameters> ] <CRLF>
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
* reverse-path: 메일을 보내는 사람의 정보, source routing을 사용하지 않음
* forward-path: 메일을 받는 사람의 정보, source routing을 사용하지 않음

14. SMTP Session상태

15. SMTP 전송과정

16. SMTP SPECIFICATIONS – SMTP command
• 명령어는 문자열이고 <CRLF>에 의해 끝난다.
• 인자를 받게 되는 경우 <SP> 후에 인자를 받고 <CRLF>로 끝난다.
Extended HELLO (EHLO) or HELLO (HELO)
ehlo = "EHLO" SP Domain CRLF•
• Argument : 클라이언트의 FQDN
• 250 OK 응답 : 클라이언트와 서버가 진행중인 트랜잭션이 없고
모든 상태 테이블과 버퍼가 지워진 초기 상태임을 알림
MAIL (MAIL)
"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF•
• 메일 전송을 위한 트랜잭션을 시작하는 명령
• Argument : reverse-path(보내는 사람을 나타냄)
• reverse-path에 source route를 지정하는 방식은 현재 사용하지 않음
RECIPIENT (RCPT)
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
[SP Rcpt-parameters] CRLF
•
• 한 명의 메일 수신자 정보를 알려주기 위한 명령
• Argument : forward-path(받는 사람을 나타냄)
• forward-path에 source route를 지정하는 방식은 현재 사용하지 않음
• 보내는 시스템은 source route를 사용하지 말아야 하고, 받는 시스템은 source route를 이해는 할 수 있어
야 하지만, 무시하고 도메인 네임 시스템을 사용해야 함

17. SMTP SPECIFICATIONS – SMTP command
DATA (DATA)
"DATA" CRLF
• 메일 데이터를 전송하기 위한 명령
• Receiver는 DATA 명령에 대해 일반적으로 354 응답을 보내고 그 뒤의 라인들을 sender가 보내는 메일
데이터로 취급, 메일 데이터 끝은 <CRLF>.<CRLF>
• SMTP server가 메시지를 받으면 서버는 메일 데이터의 맨 위에 추적 정보(time stamp line 또는 received
line)를 삽입, 릴레이 되는 경우 여러 줄이 추가됨.
• 메일 데이터는 128 ASCII 문자를 포함
VERIFY (VRFY)
"VRFY" SP String CRLF
인자로 입력한 유저의 유저 이름과 메일 박스를 리턴
EXPAND (EXPN)
"EXPN" SP String CRLF
인자로 입력한 메일링 리스트에 해당하는 리스트 내의 유저 이름과 메일 박스를 리턴
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

18. SMTP SPECIFICATIONS – SMTP command
HELP (HELP)
"HELP" [ SP String ] CRLF
서버에게 도움이 될 만한 정보를 보내도록 요청
NOOP (NOOP)
"NOOP" [ SP String] CRLF
이전에 입력된 명령이나 인자들에 대해 영향을 주지 않고 receiver도 다른 액션을 취하지 않고 OK응답
QUIT (QUIT)
"QUIT" CRLF•
이 명령어 대해 서버는 반드시 OK응답을 보내야 하고 그 후에 전송채널을 닫아야 함.
RESET (RSET)
"RSET" CRLF
현재 트랜잭션을 중단, 저장되어 있는 모든 버퍼와 상태 테이블을 삭제

19. SMTP SPECIFICATIONS – SMTP Replies
• 메일 전송 과정에서의 요청과 액션의 동기화를 보장하기 위해서 사용
• 클라이언트가 항상 서버의 상태를 알 수 있게 함
• 모든 명령에 대해서 정확히 하나의 응답을 생성
• SMTP 응답은 세 자리의 숫자와 뒤에 붙는 텍스트로 구성
• 클라이언트는 텍스트 내용을 몰라도 세 자리의 숫자를 통해 state를 알 수 있고, 텍스트는 유저를 위해 제공
1.X.X 명령어가 받아 들여졌지만 명령어의 처리를 계속할 것인가 그만 둘 것인가를 위
해 다음 명령어가 필요
2.X.X 성공적으로 명령어가 완료
3.X.X 명령어가 받아 들였지만 또 다른 입력이 필요
4.X.X 일시적인 에러 조건
5.X.X 에러 발생
First Digit
Second Digits
X.0.Z Other or Undefined Status (부가적인 subject 정보를 제공할 것이 없는 경우)
X.1.Z Addressing Status (작성자나 목적지의 주소 문제로 인해 발생)
X.2.Z Mailbox Status (메일박스의 문제로 인해 발생하고 수신자의 책임일 수 있음)
X.3.Z Mail System Status (수신될 메일 시스템의 문제로 발생)
X.4.Z Network and Routing Status (전송 시스템 자체의 문제로 발생)
X.5.Z Mail Delivery Protocol Status (메시지 전송 프로토콜의 문제로 발생)
X.6.Z Message Content or Media Status (메시지 내용의 문제로 발생)
X.7.Z Security or Policy Status (보안이나 정책 관련 문제로 발생)
RFC 3463 Enhanced Mail System Status Codes

20. Third Digits
SMTP SPECIFICATIONS – SMTP Replies
X.1.0 Other address status X.5.0 Other or undefined protocol status
X.1.1 Bad destination mailbox address X.5.1 Invalid command
X.1.2 Bad destination system address X.5.2 Syntax error
X.1.3 Bad destination mailbox address syntax X.5.3 Too many recipients
X.1.4 Destination mailbox address ambiguous X.5.4 Invalid command arguments
X.1.5 Destination mailbox address valid X.5.5 Wrong protocol version
X.1.6 Mailbox has moved X.6.0 Other or undefined media error
X.1.7 Bad sender's mailbox address syntax X.6.1 Media not supported
X.1.8 Bad sender's system address X.6.2 Conversion required and prohibited
X.2.0 Other or undefined mailbox status X.6.3 Conversion required but not supported
X.2.1 Mailbox disabled, not accepting messages X.6.4 Conversion with loss performed
X.2.2 Mailbox full X.6.5 Conversion failed
X.2.3 Message length exceeds administrative limit X.7.0 Other or undefined security status
X.2.4 Mailing list expansion problem X.7.1 Delivery not authorized, message refused
X.3.0 Other or undefined mail system status X.7.2 Mailing list expansion prohibited
X.3.1 Mail system full X.7.3 Security conversion required but not possible
X.3.2 System not accepting network messages X.7.4 Security features not supported
X.3.3 System not capable of selected features X.7.5 Cryptographic failure
X.3.4 Message too big for system X.7.6 Cryptographic algorithm not supported
X.4.0 Other or undefined network or routing status X.7.7 Message integrity failure
X.4.1 No answer from host
X.4.2 Bad connection
X.4.3 Routing server failure
X.4.4 Unable to route
X.4.5 Network congestion
X.4.6 Routing loop detected
X.4.7 Delivery time expired

21. SMTP SPECIFICATIONS – SMTP Replies
주요 응답
500 문법 에러, 알려지지 않은 명령어(명령어 라인이 너무 긴 경우를 포함할 수 있음)
501 인자에 대한 문법 에러
502 명령이 구현되지 않았음
503 명령의 순서가 잘못됨
504 명령의 인자가 구현되지 않았음
211 시스템의 상태에 대한 응답
214 Help 메시지이고 사람에게만 유용함
220 <domain> 서비스 준비
221 <domain> 서비스를 닫고 전송 채널을 종료
421 <domain> 서비스가 현재 사용 불가능하므로 전송 채널을 닫음
250 요청한 메일 동작이 성공적으로 완료되었음
251 유저가 로컬에 없고 <forward-path>로 연결될 것임
450 요청한 메일 동작이 메일박스를 일시적으로 사용할 수 없기 때문에 수행되지 않았음
550 메일박스를 사용할 수 없기 때문에 발생하는 에러
451 요청한 메일 동작 처리 중에 로컬 에러가 발생하여 동작이 취소됨
551 유저가 로컬에 없고 <forward-path>로 다시 시도해야 한다는 것을 알려줌
452 요청한 메일 동작이 시스템 저장 공간이 부족하여 처리되지 않음
552 할당된 저장 공간을 초과하여서 발생하는 에러
553 메일박스 이름이 허가되지 않아서 발생하는 에러
354 메일 입력 시작; <CRLF>.<CRLF>로 끝남
554 트랜잭션 실패

22. CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221
SMTP SPECIFICATIONS – SMTP Replies
각각의 명령은 가질 수 있는 응답들의 리스트가 있다.
I : Intermediate, S : Success, E : Error

23. SMTP SPECIFICATIONS – Trace Information
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
메일의 전송 및 중계 상황에서 문제가 발생했을 경우에 사용할 정보
SMTP 서버가 메시지를 받으면 “time stamp” 또는 “Return-Path”(추적 필드)를 메시지 시작 부분에 삽입
• 서버는 Received 라인을 맨 위에 추가만 해야 하고
기존에 있던 “Received:”라인을 바꾸거나 다른 위치에 추가 하면 안됨
메시지를 최종 수신자에게 배달하는 경우 메일 데이터의 시작 부분에 Return-Path
라인을 삽입한다.
최신순

24. bar.com 호스트의 Smith가 foo.com 호스트의 Jones, Green, Brown에게 메일을 보낸다.
두 호스트는 직접 연결되어 있고, Green은 foo.com 호스트에 메일박스가 없다
EXAMPLE - A Typical SMTP Transaction Scenario
서버에서 지원하는 확장 명령어들
응답 대기
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

25. SMTP SPECIFICATIONS – Additional Implementation Issues
Minimum Implementation
최소 EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, VRFY 명령의 구현 필요
중계나 배달을 지원하는 서버는 대소문자를 구별하지 않는 "postmaster" 메일박스를 반드시 지원
Transparency
유저의 모든 텍스트를 투명성있게 전송하기 위한 노력
• 메일 텍스트의 라인을 보내기 전에 SMTP 클라이언트는 라인의 첫 글자를 체크한다. 마침표
면 라인의 처음에 마침표 하나를 추가한다.
• SMTP 서버에서 메일 텍스트를 받으면서 라인을 체크할 때, 마침표 하나만 있으면 end of mail
식별자로 처리되고, 라인의 첫글자가 마침표이고 라인에 다른 글자들이 있으면 첫번째 문자
는 삭제된다.
Sizes
text line :
1000 라인
reply line : 512 문자
local-part : 64 문자
domain : 255 문자
local-part@domaincommand line :
512 문자
path : 256 문자

26. 메일을 보낼 도메인은 해석을 위한 DNS 조회 수행이 필요
1. 도메인 네임과 관련된 MX레코드를 검색
2. CNAME 레코드(별칭)가 있는 경우 사용 가능
3. MX 레코드는 찾지 못하고 A 레코드를 찾은 경우
A 레코드는 우선순위가 0인 MX RR인 것처럼 처리되고 해당 호스트를 가리킴
4. MX 레코드가 있는데 사용 가능한 일이 없는 경우 에러를 보고해야 함
ADDRESS RESOLUTION AND MAIL HANDLING
우선순위가 같으므로 랜덤으로 대상을 선택

27. Security Considerations
Information Disclosure in Announcements
환영 응답이나 HELP 명령에 대한 응답으로 공격 시 유용한 정보를 제공할 수 있음
VRYF, EXPN, and Security
보안 상의 이유로 VRFY, EXPN 명령을 사용하지 않게 할 수 있음
Information Disclosure in Trace Fields
Received 필드에 정보를 남길 때에는 호스트에 대한 노출과 숨은 참조자에 대한 노출을 고려해야 함
Information Disclosure in Message Forwarding
251, 551 응답 코드(forwarding)로 대체 주소를 알려주는 경우 정보가 노출 될 수 있음
보통 250 OK 응답을 하고 Silent Forwarding을 한다.

28. Deprecated Features of RFC 821
TURN
sender 와 receiver 을 바꾸는 명령
메일을 올바른 대상에서 다른 곳으로 전환시키는 데 쉽게 사용할 수 있으므로 보안 문제로 인해 이 기능은 폐지
SMTP 시스템은 서버가 클라이언트를 인증할 수 있는 경우가 아니면 이 기능을 사용하지 않는다.
Source Routing
도메인 네임 시스템의 MX 레코드가 도입되면서 소스 라우트의 필요성이 사라졌다.
서버는 반드시 소스 라우트 문법을 허용해야 한다.
서버는 라우트를 무시하고 타겟 도메인만을 사용할 수 있으며, 메시지는 주소에 표시된 첫 도메인으로 전송되어
야 한다.
클라이언트는 일반적인 상황에서 소스 라우팅을 사용하지 않는다.
HELO
서버가 EHLO를 허용할 수 있는 경우 HELO보다 EHLO 명령을 추천한다.
서버는 반드시 오래 된 클라이언트를 지원하기 위해 HELO 명령을 허용할 수 있어야 한다.
#-literals
#가 붙은 십진수의 정수를 인터넷 주소로 사용할 수 있었지만 TCP/IP의 소개 이후 이 형태는 사용되지 않고 폐지
되었다.
Dates and Years
클라이언트나 서버에 의해 날짜가 삽입되는 경우(예: 추적 필드) 연도는 반드시 네 자리 숫자로 사용되어야 한다.
두 자리 년도의 사용은 폐지되었고 세 자리 년도의 사용은 허가되지 않는다.
Sending versus Mailing
사용자의 터미널 화면에 메시지를 직접 전달하기 위한 SEND, SAML, SOML 명령어는 워크스테이션 기술의 발달
과 다른 프로토콜들의 도입으로 인해 폐지

29. 끝