컴퓨터망
20. Email SMTP
이 장에서는 먼저 사용자 에이전트, 메시지 전송 에이전트 및 메시지 액세스 에이전트의 세 가지 주요 구성 요소를 포함하는 이메일 시스템의 일반 아키텍처를 본다
그런 다음 이러한 구성 요소를 구현하는 프로토콜을 본다
Architecture
email의 구조를 설명하기 위해 네 가지 시나리오를 제시한다
가장 단순한 상황에서 시작하여 복잡성을 추가한다
네 번째 시나리오는 가장 일반적인 email 구조다
First Scenario
- 이메일의 발신자와 수신자는 동일한 메일 서버의 사용자이다
- 공유 메일 서버에 직접 연결된다
- 관리자는 수신된 메시지가 저장되는 각 사용자에 대해 하나의 메일박스를 만들었다
- 메일박스는 권한 제한이 있는 특수 파일인 로컬 하드 드라이브의 일부이다
- 메일박스 소유자만 액세스할 수 있다
이메일을 보내는 사람과 받는 사람이 같은 메일 서버에 있을 때 두 개의 사용자 에이전트만 있으면 된다
Second Scenario
- 이메일의 발신자와 수신자는 서로 다른 두 메일 서버의 사용자이다
- 메시지는 인터넷을 통해 보내야 한다
- 그림과 같이 사용자 에이전트(UA)와 메시지 전송 에이전트(MTA)가 필요하다
이메일의 발신자와 수신자가 다른 메일 서버에 있는 경우 두 개의 UA와 한 쌍의 MTA(클라이언트 및 서버)가 필요하다
Alice는 사용자 에이전트 프로그램을 사용하여 자신의 메일 서버로 메시지를 보내야 한다
그녀의 사이트에 있는 메일 서버는 대기열(스풀)을 사용하여 전송 대기 중인 메시지를 저장합니다
Bob은 또한 자신의 사이트에 있는 시스템의 사서함에 저장된 메시지를 검색하기 위해 사용자 에이전트 프로그램이 필요하다
그러나 메시지는 Alice의 사이트에서 Bob의 사이트로 인터넷을 통해 전송되어야 한다
여기에 두 개의 메시지 전송 에이전트가 필요하다
하나는 클라이언트이고 다른 하나는 서버다
두 개의 메시지 전송 에이전트가 필요하다
하나는 클라이언트이고 다른 하나는 서버이다
인터넷에 있는 대부분의 클라이언트-서버 프로그램과 마찬가지로 서버는 클라이언트가 언제 연결을 요청할지 모르기 때문에 항상 실행해야 한다
반면에 클라이언트는 보낼 대기열에 메시지가 있을 때 시스템에 의해 트리거될 수 있다
Third Scenario
두 번째 시나리오에서와 같이 Bob은 메일 서버에 직접 연결되어 있다
그러나 Alice는 메일 서버와 분리되어 있다
Alice는 여전히 그녀의 메시지를 위해 사용자 에이전트가 필요하다
그런 다음 LAN 또는 WAN을 통해 메시지를 보내야 한다
이것은 한 쌍의 메시지 전송 에이전트MTA(클라이언트 및 서버)를 통해 수행할 수 있다
Alice는 보낼 메시지가 있을 때마다 사용자 에이전트를 호출하고 MTA 클라이언트를 호출한다
MTA 클라이언트는 항상 실행 중인 시스템의 MTA 서버와 연결을 설정한다
Alice의 사이트에 있는 시스템은 수신된 모든 메시지를 대기열에 넣는다
그런 다음 MTA 클라이언트를 사용하여 Bob의 사이트에 있는 시스템으로 메시지를 보낸다
시스템은 메시지를 수신하고 Bob의 메일박스에 저장한다
Bob은 사용자 에이전트를 사용하여 메시지를 검색하고 읽는다
두 쌍의 MTA 클라이언트-서버 프로그램이 필요하다
발신자가 LAN 또는 WAN을 통해 메일 서버에 연결되면 두 개의 UA와 두 쌍의 MTA(클라이언트 및 서버)가 필요하다
Fourth Scenario
Bob은 WAN 또는 LAN을 통해 메일 서버에 연결된다
메시지가 Bob의 메일 서버에 도착한 후 Bob은 메시지를 검색해야 한다
여기서 메시지 액세스 에이전트(MAA)라고 하는 또 다른 클라이언트-서버 에이전트 세트가 필요하다
Bob은 MAA 클라이언트를 사용하여 메시지를 검색한다
클라이언트는 상시 실행 중인 MAA 서버에 요청을 보내고 메시지 전송을 요청한다
Bob은 클라이언트-서버 프로그램인 메시지 액세스 프로그램이 필요하다
MTA 클라이언트-서버 프로그램이 푸시 프로그램이기 때문이다
클라이언트는 메시지를 서버에 푸시한다
밥은 PULL 프로그램이 필요하다
클라이언트는 서버에서 메시지를 가져와야 한다
이게 MAA이다
발신자와 수신자가 모두 LAN 또는 WAN을 통해 메일 서버에 연결되어 있으면 두 개의 UA, 두 쌍의 MTA(클라이언트 및 서버) 및 한 쌍의 MAA(클라이언트 및 서버)가 필요하다
- 클라이언트가 메시지를 보낸다
-
메시지를 가져온다
-
즉 사용자가 메일을 읽으려면 에이전트가 필요하고
-
떨어진 곳에 메일을 전달하려면 MTA를 사용해 전달해야한다
-
MTA는 푸쉬 프로그램이다
-
이때 클라가 연결요청을 하고 서버가 받아야한다
-
-
그리고 메일 박스를 읽으려면 MAA를 이용해 읽는다
- 사용자가 서버에 요청해서 슉 읽을 수 있다 이때 사용자 에이전트에 메일을 준다
User Agent
이메일 시스템의 첫 번째 구성 요소는 사용자 에이전트(UA)이다
사용자에게 메시지를 보내고 받는 과정을 보다 쉽게 만들어주는 서비스를 제공한다
Agent type
command driven user 에이전트의 몇 가지 예는 mail, pine 및 elm이다
GUI 기반 사용자 에이전트의 몇 가지 예는 Eudora, Outlook 및 Netscape이다
- 현대 유저 에이전트는 GUI 기반이다
- 사용자가 키보드와 마우스를 모두 사용하여 소프트웨어와 상호 작용할 수 있도록 하는 GUI(그래픽 사용자 인터페이스) 구성 요소가 포함되어 있다
- 서비스에 쉽게 액세스할 수 있도록 하는 아이콘, 메뉴 표시줄 및 창과 같은 그래픽 구성 요소가 있다
email format
Email Address
메일을 delivery하려면 addressing 시스템을 사용해야 한다
인터넷에서 주소는 @ 기호로 구분되는 로컬 부분과 도메인 이름의 두 부분으로 구성된다
Local part
로컬 부분은 사용자 메일함이라고 하는 특수 파일의 이름을 정의한다
Domain part
주소의 두 번째 부분은 도메인 네임이다
Message Transfer Agent : SMTP
실제 메일 전송은 MTA(메시지 전송 에이전트)를 통해 수행된다
메일을 보내려면 시스템에 클라이언트 MTA가 있어야 하고 메일을 받으려면 시스템에 서버 MTA가 있어야 한다
인터넷에서 MTA 클라이언트와 서버를 정의하는 공식 프로토콜을 SMTP(Simple Mail Transfer Protocol)라고 하다
앞에서 말했듯이 두 쌍의 MTA 클라이언트-서버 프로그램이 가장 일반적인 상황(네 번째 시나리오)에서 사용된다
그림은 이 시나리오에서 SMTP 프로토콜의 범위를 보여준다
SMTP는 보낸 사람과 보낸 사람의 메일 서버 간, 두 메일 서버 간 두 번 사용된다
SMTP는 단순히 명령과 응답을 주고받는 방법을 정의한다
Commands and Responses
SMTP는 command과 response을 사용하여 MTA 클라이언트와 MTA 서버 간에 메시지를 전송한다
Command
Response
Mail Transfer 단계
메일 메시지 전송 과정은 연결 설정, 메일 전송, 연결 종료로 진행
Connection establishment
클라이언트가 포트 25에 TCP 연결을 만든 후 SMTP 서버는 연결 단계를 시작한다
이 단계에는 그림에 나와 있는 다음 세 단계가 포함된다
- 서버는 메일을 받을 준비가 되었음을 클라이언트에게 알리기 위해 코드 220(서비스 준비)을 보냅니다. 서버가 준비되지 않은 경우 코드 421(서비스를 사용할 수 없음)을 보냅니다.
- 클라이언트는 도메인 이름 주소를 사용하여 자신을 식별하기 위해 HELO 메시지를 보냅니다. 이 단계는 클라이언트의 도메인 이름을 서버에 알리는 데 필요합니다. TCP 연결을 설정하는 동안 발신자와 수신자는 IP 주소를 통해 서로를 알고 있습니다.
- 서버는 상황에 따라 코드 250(요청 명령 완료) 또는 다른 코드로 응답합니다.
Data Transfer
SMTP 클라이언트와 서버 간에 연결이 설정되면 보낸 사람과 한 명 이상의 받는 사람 간에 단일 메시지를 교환할 수 있습니다. 이 단계에는 8단계가 포함됩니다. 수신자가 두 명 이상인 경우 3단계와 4단계가 반복됩니다(그림 23.11 참조).
Connection termination
메시지가 성공적으로 전송된 후 클라이언트는 연결을 종료
이 단계에는 두 단계가 포함
- 클라이언트가 QUIT 명령을 보냅니다.
- 서버는 코드 221 또는 기타 적절한 코드로 응답
연결 종료 단계 이후에는 TCP 연결을 닫아야 한다
Message Access Agent: POP and IMAP
메일 배달의 첫 번째 및 두 번째 단계는 SMTP를 사용한다
그러나 SMTP는 푸시 프로토콜이므로 세 번째 단계에는 SMTP가 포함되지 않는다
클라이언트에서 서버로 메시지를 푸시한다
즉, 메시지의 방향은 클라이언트에서 서버이다
반면에 세 번째 단계에는 Pull 프로토콜이 필요하다
클라이언트는 서버에서 메시지를 가져와야 한다
메시지의 방향은 서버에서 클라이언트로이다
세 번째 단계는 메시지 액세스 에이전트를 사용한다
POP3 IMAP4
현재 두 가지 메시지 액세스 프로토콜을 사용할 수 있다
Post Office Protocol 버전 3(POP3)과 Internet Mail Access Protocol 버전 4(IMAP4)이다
그림은 가장 일반적인 상황(네 번째 시나리오)에서 이 두 프로토콜의 위치를 보여준다
Post Office Protocol, 버전 3(POP3)은 단순하고 기능이 제한적입니다. 클라이언트 POP3 소프트웨어는 수신자 컴퓨터에 설치됩니다. 서버 POP3 소프트웨어가 메일 서버에 설치됩니다.
IMAP4는 POP3와 유사하지만 더 많은 기능이 있습니다. IMAP4는 더 강력하고 더 복잡합니다.
MIME
이메일은 간단한 구조를 가지고 있다
그러나 단순함에는 대가가 따른다
NVT 7비트 ASCII 형식으로만 메시지를 보낼 수 있다
즉, 몇 가지 제한 사항이 있다
MIME(Multipurpose Internet Mail Extensions)는 비ASCII 데이터를 이메일을 통해 보낼 수 있도록 하는 보조 프로토콜이다
MIME은 발신자 사이트의 비 ASCII 데이터를 NVT ASCII 데이터로 변환하고 이를 클라이언트 MTA에 전달하여 인터넷을 통해 전송한다
수신 사이트의 메시지는 원래 데이터로 다시 변환된다
Web based mail
이메일은 오늘날 일반적인 응용 프로그램이다
세 가지 일반적인 사이트는 Hotmail, Yahoo 및 Google이다
아이디어는 매우 간단합니다. 두 가지 경우를 살펴보겠습니다.
Case 1
첫 번째 경우 발신자인 Alice는 전통적인 메일 서버를 사용한다
수신자인 Bob은 웹 기반 서버에 계정을 가지고 있다
Alice의 브라우저에서 그녀의 메일 서버로의 메일 전송은 SMTP를 통해 이루어진다 보내는 메일 서버에서 받는 메일 서버로의 메시지 전송은 여전히 SMTP를 통해 이루어진다
그러나 수신 서버(웹 서버)에서 Bob의 브라우저로 보내는 메시지는 HTTP를 통해 이루어진다
즉, POP3나 IMAP4 대신 HTTP를 사용하는 것이 일반적이다
Bob은 이메일을 검색해야 할 때 요청 HTTP 메시지를 웹사이트로 보낸다
Bob은 수신한 이메일을 검색한 다음 더 많은 HTTP 트랜잭션을 사용하여 이메일을 하나씩 받을 수 있다
Case 2
두 번째 경우 Alice와 Bob은 모두 웹 서버를 사용하지만 같은 서버는 아니다
Alice는 HTTP 트랜잭션을 사용하여 웹 서버에 메시지를 보낸다
Alice는 Bob의 메일박스 이름과 주소를 URL로 사용하여 HTTP 요청 메시지를 웹 서버에 보낸다
Alice 사이트의 서버는 메시지를 SMTP 클라이언트로 전달하고 SMTP 프로토콜을 사용하여 Bob 사이트의 서버로 보낸다
Bob은 HTTP 트랜잭션을 사용하여 메시지를 수신한다
그러나 Alice 사이트의 서버에서 Bob 사이트의 서버로의 메시지는 여전히 SMTP 프로토콜을 사용하여 발생한다
Email security
이 장에서 논의된 프로토콜은 보안을 제공하지 않는다
그러나 전자 메일 시스템용으로 특별히 설계된 두 가지 응용 프로그램 계층 보안을 사용하여 전자 메일 교환을 보호할 수 있다
이러한 프로토콜 중 두 가지인 PGP(Pretty Good Privacy)와 SMIME(Secure MIME)은 기본 네트워크 보안에 대해 논의한 후 마지막에서 논의합니다.
