SMTP 설명

RFC : Request for Comments

SMTP : Simple Mail Transfer Protocol

UA || MUA : User Agent or Mail User Agent

MTA : Mail Transfer Agent

SMTP(간이 전자우편 전송 프로토콜)

전자 메시지 시스템 에서 중요한 것은 이기종 혼합 환경에서 상호 정확한 통신을 확보 하는 것 입니다. 이것이 기반이 되어야 하는 통신 중 하나인 이메일로 접근해 본다면 RFC-822(2821)에 기반한 시스템이 일반적입니다. 메일전송 시 사용하게 되는 프로토콜은 국제 인터넷 표준화기구인 IETF에서 RFC라는 형식으로 표준을 문서화 하여 공개하고 있습니다.(http://www.ietf.org/rfc.html)  이메일에 관해서는 전송을 위한 프로토콜인 RFC-821과 메시지 형식인 RFC-822가 기반이 됩니다.  표준에서는 텍스트 기반의 프로토콜인 SMTP는 요구 / 응답 메시지뿐 아니라 모든 문자가 7bit ASCII로 되어있어야 한다고 규정되어 있습니다. 이 때문에 문자 표현에 8비트 이상의 코드를 사용하는 언어나 첨부파일과 자주 사용되는 바이너리는 마임(MIME)이라고 불리는 방식으로 7bit로 변환되어 전달 됩니다.  SMTP는 서로 다른 컴퓨터의 메일 시스템들 사이에 메일 전송 서비스를 제공하며, TCP/IP환경에서 E-Mail용 애플리케이션 프로토콜을 사용합니다.(SMTP는 TIP/IP 응용 프로토콜 중 하나) 이것은 인터넷 메일을 전송하기 위한 프로토콜 입니다. 전자메일 사용자는 MUA(or UA)라 부르는 클라이언트를 이용해 메일로 작성하고 이것을 MTA로 SMTP프로토콜을 사용하여 전송 합니다. 메일을 전달받은 MTA는 사용자가 지정한 수신인을 검사하고 어느 MTA로 전송할지를 결정합니다. 대부분의 경우는 수신자의 Mailbox가 있는 MTA로 직접 전송(ex Q-MAIL) 합니다. 수신인의 Mailbox에 저장된 메일은 수신인이 전자메일 클라이언트(UA)를 이용하여 사서함을 열어 볼 때 배달하게 됩니다. 수신을 위해서는 POP3나 IMAP중 하나의 프로토콜을 사용합니다.

위 그림에서 보이듯이 SMTP는 호스트 컴퓨터의 메일 시스템에서 다른 호스트 컴퓨터의 메일 시스템으로 전송을 담당 합니다. 그리고 지역 사용자들로부터 메일을 수신하거나 수신된 메일을 메일 수신자들에게 배달하는 것은 지역 메일 시스템(POP3, IMAP)이 관리 하게 되는 것입니다.

SMTP통신의 예

메일을 보내는 UA(클라이언트 – 송신자)와 메일을 받는 MTA(서버 – 수신자)간 연결이 성립된후 이루어지는 간단한 예제 입니다.

1	telnet www.example.com 25

이 명령으로 보내는 클라이언트 에서 호스트로 SMTP연결이 시작 됩니다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

S : 220 www.example.com ESMTP Postfix C : HELO mydomain.com S : 250 Hello mydomain.com C : MAIL FROM: <sender@mydomain.com> S : 250 ok C : RCPT TO: <friend@example.com> S : 250 ok C : DATA S : 354 End data with <CR><LF>.<CR><LF> C : Subject: test message C : From: sender@mydomain.com C : To: friend@example.com C : C : Hello, C : This is a test C : Goodbye. C : . S : 250 Ok: queued as 12345 C : quit S : 221 Bye

위의 통신을 그림으로 표현하면 다음과 같습니다.

SMTP에서의 인증

이메일 클라이언트(아웃룩, 선더버드 등)를 이용해 메일을 발송 할 때 SMTP인증이 쓰입니다.
인증이란 개념이 추가된 SMTP를 ESMTP라 부르기도 합니다.(사실 ESMTP는 좀더 많은 개념이 확장된 형태입니다.) 아이디 / 패스워드를 인증하여 성공시에만 받은 메일을 발송해 줍니다. 
위에서 간략한 예 와 그림으로 메일발송절차를 간략히 살펴 보았는데, 사용한 명령어는 다음과 같습니다.

EHLO -> MAIL -> RCPT -> DATA -> QUIT

인증절차를 추가하게 되면 다음과 같은 명령어 순서를 사용하게 됩니다.

EHLO -> AUTH -> MAIL -> RCPT -> DATA -> QUIT

인증 명령어인 AUTH가 추가되었습니다. AUTH를 통신할때 사용자 아이디 / 패스워드를 어떻해 입력해서 인증을 요청하게 되는지에 따라 PLAIN,LOGIN,DIGEST-MD5,CRAM-MD5등이 이용됩니다.

첫 번째 PLAIN 인증방식의 예를 살펴보겠습니다.(센드메일의 예(아이디패스워드 동시입력))

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

C : telnet localhost 25 S : 220 www.example.com ESMTP Sendmail 8.13.8/8.13.8; Wed, 25 May 2011 10:15:59 +0900 C : EHLO daou.com S : 250-www.example.com Hello localhost.localdomain [127.0.0.1], pleased to meet you    250-ENHANCEDSTATUSCODES    250-PIPELINING    250-8BITMIME    250-SIZE    250-DSN    250-ETRN    250-AUTH GSSAPI LOGIN PLAIN // <= S : 인증방식으로 GSSAPI,LOGIN,PLAIN 제공하고 있습니다.    250-DELIVERBY    250 HELP C : AUTH PLAIN                 // <= C : PLAIN방식으로 인증하겠습니다. S : 334 C : XFVZRU9OR1x0ZXN0           // <= C : BASE64로 인코딩된 아이디와 패스워드는 다음과 같습니다. S : 235 2.0.0 OK Authenticated // <= S : 인증되었습니다^^                                // MAIL, RCPT, DATA, QUIT 순으로 메일을 발송하시면 됩니다.

두 번째 LOGIN 인증방식의 예를 살펴보겠습니다.(센드메일의 예(말그대로 아이디 패스워드 따로입력))

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

C : telnet localhost 25 S : 220 sendmail.daou.com ESMTP Sendmail 8.13.8/8.13.8; Wed, 25 May 2011 10:15:59 +0900 C : EHLO daou.com S : 250-sendmail.daou.com Hello localhost.localdomain [127.0.0.1], pleased to meet you    250-ENHANCEDSTATUSCODES    250-PIPELINING    250-8BITMIME    250-SIZE    250-DSN    250-ETRN    250-AUTH GSSAPI LOGIN PLAIN   // <= S : 인증방식으로 GSSAPI,LOGIN,PLAIN 제공하고 있습니다.    250-DELIVERBY    250 HELP C : AUTH LOGIN                   // <= C : LOGIN방식으로 인증하겠습니다. S : 334 VXNlcm5hbWU6         // <= S : username: 을 입력해주세요 C : VVlFT05H             // <= C : BASE64로 인코딩된 UYEONG 입니다. S : 334 UGFzc3dvcmQ6         // <= S : Password: 를 입력해주세요 C : dGVzdA==             // <= C : BASE64로 인코딩된 test 입니다. S : 235 2.0.0 OK Authenticated   // <= S : 인증되었습니다^^                                  //        MAIL, RCPT, DATA, QUIT 순으로 메일을 발송하시면 됩니다.

세 번째 Digest-MD5 인증방식의 예를 살펴보겠습니다.(문서 RFC2831의 예)

1 2 3 4 5 6 7 8 9 10 11 12

S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" "DIGEST-MD5" "PLAIN") C: a AUTHENTICATE "DIGEST-MD5" S: + {94} S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", algorithm=md5-sess,charset=utf-8 C: {206} C: charset=utf-8,username="chris",realm="elwood.innosoft.com",   nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",   digest-uri="acap/elwood.innosoft.com",   response=6084c6db3fede7352c551284490fd0fc,qop=auth S: a OK (SASL {40} S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE Completed"

네 번째 CRAM-MD5인증방식의 예를 살펴보겠습니다.(http://www.samlogic.net/articles/smtp-commands-reference-auth.htm 소개 된 예)

PLAIN 과 LOGIN 인증방식을 사용시 단점은 만약 누군가가 SMTP 프로토콜 통신시 대화를 감시한다면 사용자명과 패스워드가 꽤 쉽게 해독된다는 것입니다. 더 높은 보안 수준을 확보하기 위해서 사용하는 방법 중 하나가 CRAM-MD5 인증방식 입니다. CRAM-MD5는 MD5(MessageDigest5)알고리즘 암호 해독법을 이용해 중요한 정보를 부호화하여 교환하기 위한 대화형 인증 방법과 결합 했습니다.

클라이언트로부터 서버로 AUTH CRAM MD5명령이 전송된 이후, 서버는 BASE64로 암호화된 "challenge"시간을 클라이언트에게 재전송 합니다.

클라이언트는 BASE64로 암호화된 16진법 요약 문자열을 서버로 보냄으로써 반응합니다. 그리고 회신하게 되는데 그 회신 문자열 안의 요약은 패스워드의 암호키와, SMTP서버의 본래 "challenge" 메시지와 같은 HMAC계산의 산출입니다. 이어서 SMTP서버는 고유한 사용자패스워드의 고유개념을 요약해 계산하고, 만약 그 클라이언트의 요약과 서버의 요약이 맞다면 인증은 성공이 되고 235 회신코드로써 인증성공을 클라이언트에게 알립니다. CRAM-MD5인정 방법은 BASE64로 암호화된 클라이언트 회신 패스워드를 해독할 때 검색될 수 없기 때문에 먼저 언급된 다른 두 인증방식보다 더욱 안전합니다.

패스워드는 HMAC를 계산하는데 열쇠와 같이 사용되나, 패스워드는 응답 중 어느 곳에도 저장되지 않습니다. 클라이언트 응답은 서버로부터 보내진 "challenge"(종종 현재 시간이 동봉된) 때문에 한차례의 이상의 인증시엔 무효합니다. 따라서 SMTP통신을 감독하는 누군가에 의해 다시 사용될수 없습니다.

아래의 예는 SMTP서버에 로그인시 어떻해 AUTH CRAM MD5로 대화가 이루어지는지 보여줍니다.

1 2 3 4 5 6 7 8 9

S: 220 smtp.server.com Simple Mail Transfer Service Ready C: EHLO client.example.com S: 250-smtp.server.com Hello client.example.com S: 250-SIZE 1000000 S: 250 AUTH LOGIN PLAIN CRAM-MD5 C: AUTH CRAM-MD5 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVkdT4=  [1] C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==  [2] S: 235 2.7.0 Authentication successful

사용자 인증절차는 SASL메커니즘을 이용한 인증기구가 SMTP-AUTH(SMTP Authentication)으로 표준화 하였습니다.

메일관련 RFC모음(http://www.letf.org/rfc.html)

1. RFC772.txt (Mail Transfer Protocol)

2. RFC821.txt (Simple Mail Transport Protocol)

    센드메일이 TCP/IP네트웤을 통해 한 호스트에서 다른 호스트로 메일을 전달할 때 사용할 프로토콜을 Simple Mail Transport Porotocol이라고 합니다. 이 SMTP에 관한 규정을 RFC821에서 단고 있습니다.

3. RFC822.txt (Mail Format)

    메일 메시지는 헤더, 본문등으로 나뉘게 되는데 메일이 가져야 할 형식에 대해 규정하고 있습니다.
    RFC822의 제목은 원래 Standard for the format of ARPA internet Text Messages입니다.

4. RFC1123.txt (internet Host Requirements)

    RVC1123은 RFC821과 RFC822의 확장버전입니다. 기존의 모호했던 부분을 수정하고 몇가지 기능을 확장시켰습니다.

5. RFC1521.txt (MIME)

    마임은 텍스트가 아닌 그림, 소리, 영상과 같은 파일들을 텍스트로 변환시켜 메일로 전송하는 방법에 대해 규정하고 있습니다.

6. RFC1557.txt (한글메일 교환)

7. RFC1651.txt (SMTP Service Extensions)

    비영어권 문화에서 8비트 데이터를 메일로 통해 전송하는 것이 중요해짐에 따라 기존의 SMTP를 확장하게 되었습니다. 이를 ESTMP라고 합니다.

8. RFC1891 (SMTP Delivery Status Notifications_

    제목은 SMTP Service Extension for Delivery Status Notifications(DNS)이며 메일이 전달되었는지 확일할수 있는 기능이 RCPT 명령에 추가 되었습니다. RCPT에 추가로 들어간 명령어로 NOTIFY, RET, ORCPT, ENVID가 있습니다.

9. RFC1892 (Multipart/Report)

    이 버전에서는 DSN에서 요구하는 헤더 Content-Type: 에 대해 규정하고 있습니다.

10. RFC1892 (Mail System Status Codes)

11. RFC1894 (Delivery Status Notifications)

12. RFC1985 (SMTP Service Extensions for Remote Message Queue Starting)