- 회원들이 추천해주신 좋은 글들을 따로 모아놓는 공간입니다.
- 추천글은 매주 자문단의 투표로 선정됩니다.
Date 19/01/18 19:47:01수정됨
Name   ikuk
Subject   컴퓨터는 메일을 어떻게 주고 받을까?
안녕하세요? ikuk입니다.

이메일 서비스 다들 많이 쓰시죠?
혹시나 원리를 궁금해하는 분이 있으실까하여 적어봅니다.

예전 이메일 서비스를 공부할 때 ‘현실의 어떤 부분’을 복사해 구현했을까? 에 대한 힌트가 있으면 이해가 쉽더라고요.

이메일 서비스는 간단하게 말하면 학창시절 주고 받던 쪽지와 같은 기능입니다. 학종이 뒷면이나 작은 편지 종이, 혹은 공책 귀퉁이를 찢어서 메시지를 적은 다음 친구에게 전하는 게 전부입니다.

그러나 그 편지가 상대방에게 도달하기 위해선 전달을 도와줄 친구들이 있어야 합니다. 별 문제가 없다면 수십초 내에 도달하겠지만, 그 과정에서 중간에 훔쳐보는 경우도 있을 것이고, 가끔 도착하지 못한 편지도 있을 테지요. 선생님께 압수당하거나요...

이를 방어하기 위해 수신자와 발신자만 이해할 수 있는 암호로 적기도 하고, 아예 위치를 정해 신발장이나 책상 밑, 혹은 직접 집의 우편함에 넣어두는 경우도 있었을 겁니다. 이런 많은 경우의 수들을 고려해 만든 서비스가 바로 이메일입니다.

제가 글재간이 없어, 거두절미하고 육하원칙에 따라 차근차근 원리를 분리해서 설명해볼게요.

누가?

누가 기원인가에 대해선 여러가지 말들이 있지만, 70년대 미국 고등연구국 DARPA에서 제작한 ARPANET이 현재의 이메일에 가장 가까운 정보 송수신 프로토콜을 만들고 사용했습니다. ‘사용자이름@서버주소’ 형태로 이루어진 고유의 주소로 송수신자를 식별하는 방식인데요, ‘4분단 맨 뒤에 김철수한테 전달해줘’와 같은 역할이라고 생각하시면 됩니다.


누가 메일을 받는 지 알기 위해서는 편지와 마찬가지로 상대방의 ‘이름’과 ‘주소’가 반드시  필요합니다. 한 반에 철수가 두 명인 경우에는 주소가 없으면 엉뚱한 사람에게 편지가 전달될 수 있습니다. ‘철수@4분단 맨 뒤’로 전달하게되면, 다른 위치에 있는 철수는 피할 수 있으니까요. 만약 두 철수가 같은 책상에 앉아있더라도, ‘철수@4분단 맨 뒤 책상 왼쪽’ 등을 지시해 고유한 주소로 만들 수 있다면 전달하는 입장에서 확실히 누군지 알 수 있을 것입니다. 이는 ‘큰철수@4분단 맨 뒤’ 처럼 이름을 고유하게 명시하는 방법도 있겠습니다.


‘누가 보낸거야?’라는 질문에 어깨를 으쓱한 경험이 있으신지요? 손을 여러번 탄 쪽지는 가끔 발신자를 잃고 무기명의 쪽지가 되버립니다. 그래서 보통 편지 말미, 혹은 봉투에 보내는 사람을 기입해 누가 보낸 것인지 알려주고는 합니다. 이 때 ‘영희@2분단세번째’와 같이 동일한 형태의 주소를 사용하면 답장을 보낼 때 문제가 없을 겁니다.


혹시 ‘noreply@서버주소’와 같은 메일을 받아보신 적이 있나요? noreply는 말 그대로 ‘답변없음’의 메일 주소로, 메일 발송 외의 커뮤니케이션을 지원하지 않을 때 사용합니다. 물론 실제로 수신을 거부하는 경우도 있지만, 사실 메일을 수신할 수 있는 noreply 주소도 상당히 많습니다. 메일은 받지만 내규 상 대응하지 않겠다 정도인 곳도 많거든요. 이처럼 메일주소의 이름은 사람 이름 뿐만 아니라, 부서, 팀, 직책, 혹은 특정 목적의 키워드를 사용해서, 수신자에게 ‘누가 보냈는지’를 알려주는 기능도 수행합니다.


언제?

언제 이메일이 만들어졌냐고 물으신다면, 답하기가 쉽지 않습니다. ARPANET가 71년, @를 이용한 주소의 송수신을 사용했지만, ARPANET이 등장하기 전부터 메시지를 서로 송수신하는 방법은 무궁무진했습니다.


다만 그 방법이 제각각인지라, 각 반별로 쪽지 전달하는 방법이 다른 것과 비슷했습니다. 저는 보통 ‘툭툭’ 두번 건드리고, 쪽지를 준 다음 ‘4분단 철수’ 라고 말하거나, 아예 접은 종이 위에 이름을 적었던 것 같은데, 다른 반에선 ‘주먹을 쥐어서 전달해주는 종이는 쪽지다’라는 걸 듣고 ‘와 신기하네’라고 생각했던 적이 있네요. 즉 메시지 송수신 기능은 앞서 설명한 표준 프로토콜 이전부터 존재했기 때문에, 명확히 언제부터 시작했다고 말씀드리기는 어려워도, 60년대에도 아마 있었을 겁니다.


그러나 표준이 제정된 해는 SMTP(https://tools.ietf.org/html/rfc821 )가 공표된 1982년입니다. 머릿말에도 ‘SMTP의 장점은 데이터 송수신 환경들에서 동작함’이라고 작성되어 있는데요, 당시 SMTP는 IPCE(프로세스 간 통신 환경, Interprocess Communication Environment)를 지원해 1대1 통신 외 1대다, 다대다 통신을 지원할 수 있다고 명시합니다. IPCE는 당장 중요한게 아니니 잊으셔도 됩니다.


이는 쉽게 말하면 ‘옆 반에 있는 친구 한명, 혹은 친구 다섯명, 혹은 전체 분단에게도 쪽지 전달이 가능한 방법’이라고 생각해도 무방합니다. 전달해줄 수 있는 사람이 있는 환경이라면 이 프로토콜은 해당 기능을 지원하는 것이죠. 우리가 손쉽게 여러명의 수신자, 참조, 혹은 숨은 참조를 넣는 기능은 과거 수십번의 같은 메일을 보내야 했던 사람들의 필요성에 의해 탄생했다고 보면 됩니다.


지금도 상기 URL에서 해당 프로토콜을 확인하실 수 있는데, 아래와 같은 그림이 매우 인상적입니다. 마치 오늘날의 쪽지 전달과 비슷한 모양을 가지고 있어요:



프로토콜은 해당 메일 프로그램이 위와 같은 대화를 할 수 있도록 하는 규격입니다. 발신자와 수신자는 보통 SMPT로 대화하기 위해 25번 포트로 접속을 하는데, 해당 포트로 접속했을 경우 수신자의 SMPT 담당자가 자동으로 연결됩니다. 일종의 내선번호 25번과 같은 셈이죠. (가운데 화살표가 그 대화라고 보면 됩니다.) 그러면 메일은 언제 도착할까요? 메일을 보내는 서버의 프로그램 (sendmail, postfix 등)이 위의 대화를 마치는 즉시 메일이 수신 완료됩니다.


죄송합니다... 제 말이 어렵죠? 위 내용의 두 메일 프로그램(sendmail)이 SMTP의 프로토콜로 대화하는 모습을 시뮬레이션해보겠습니다.


발신자에 해당하는 Sender-SMTP는 줄여서 클라이언트의 약자인 C로, 수신자에 해당하는 Receiver-SMTP는 서버의 약자인 S로 표현하겠습니다. 양 측 서버에서 “sendmail”이라는 프로그램을 사용해 SMTP로 대화하는 것입니다.


S: 220 smtp.server.com Simple Mail Transfer Service Ready

   (서비스 준비 완료 / 서버주소: smtp.server.com / 프로토콜: SMTP)


C: HELO client.example.com

   (안녕? 나는 client.example.com이야.)


S: 250 Hello client.example.com

   (메일 작성 요청 접수 완료 / client.example.com, 안녕?)


C: MAIL FROM:jerry@example.com

   (메일 발신자는 jerry@example.com야.)


S: 250 OK

   (메일 작성 요청 진행중 / OK )


C: RCPT TO:john@test.com

   (메일 수신자는 john@test.com야.)


S: 250 OK

   (메일 작성 요청 진행중 / OK )


C: DATA
    (이제 본문을 좀 적고 싶은데.)


S: 354 Send message content; end with CRLF.CRLF
    (본문 작성 요청 완료 / OK. 이제부터 작성해. 끝났으면 줄바꿈 엔터+ 마침표 +줄바꿈엔터를 써줘. )


C: From: "Jerry Example" <jerry@example.com>

C: To: "John Example" <alice@example.com>

C: Cc: theboss@example.com

C: Date: Tue, 15 January 2008 16:02:43 -0500

C: Subject: Test message

     (메일의 헤더 영역을 적어줍니다)

C:

C: 안녕?

C: 한글로 작성하는 메일로 잘 도착할까?

C: 문자코드 설정이 어떻게 되어있는지 잘 모르겠는걸.

C: 일단 알아서 해독해봐 제리.

     (메일 본문을 작성합니다.)

C: .

      (는 Carriage Return, Line Feed의 약자로, rn에 해당합니다. 이를 두번 입력(+마침표)하면 데이터 송신이 종료됩니다.)


S: 250 Ok: queued as 12345

     (메일 접수 완료. OK. 12345번으로 접수되었어.)


C: QUIT

     (종료할게)


S: 221 Bye

     (종료 요청 접수 완료. 잘 가)


{The server closes the connection}

     (서버가 접속을 종료했습니다.)



축하합니다! 당신은 SMTP 프로토콜로 직접 메일을 보냈습니다. 상대방이 당신의 메일 본문 중 한글을 읽을 수 있는 지는 잘 모르겠지만요.


물론 오늘날 SMTP는 보안, 편리성 등의 많은 현실적 문제에 부딪히며, 2008년 ESMTP(Extended SMTP)로 갱신되었고, 그 의외에도 많은 확장 프로그램이 추가되어 안정적이고 믿을 수 있는 서비스로 개선되었습니다. 덕분에 각 국가, 지역 관공서 등에서도 공식 문서로 사용할 수 있을 정도니까요.


예를 들어 POP3 혹은 IMAP은 메일 서버에 도착한 이메일을 웹 저장소 혹은 아웃룩과 같은 메일프로그램 저장소에 별도로 저장하는 기능을 지원합니다. 즉 내 메일 서버의 메일들을 파일화해서 자신의 PC에 저장하는 겁니다. 메일 서버 용량에 한도가 있는 경우에는 원본을 삭제하는 설정도 가능합니다. 학창 시절 친구들에게 받았던 쪽지는 대부분 잃어버린 지 오래지만, 20여년전 처음 이메일을 만들었을 때 친구들에게 받은 테스트 이메일은 아직 간직하고 있는 걸 보면, 새삼 대단하다고 느낍니다.


어디?

오늘날 웹사이트 URL은 도메인이라고 하는 훌륭한 서비스로 편리해졌습니다. 기나긴 ip를 외우지 않아도 ‘redtea.kr’만 입력하면, 전세계 어디에서도 홍차넷에 접속할 수 있으니까요. 당연히 메일 서버에게도 이 인터넷 세계는 매우 매력적인 곳이었습니다.


과거 천리안, 하이텔 등의 PC통신을 기억하시는 분들도 있겠지만, 그 당시의 PC 통신 메일 서버는 양사간의 통신이 불가능했습니다. 서로 분리된 망 위에 물리 서버가 존재했기 때문에, 하이텔에서 ‘유저ID@천리안주소’로 메일을 보내봤자, SMTP 통신이 불가능했던 겁니다. (요 부분은 자세한 내막은 모르지만 아마도 그럴겁니다. 어찌됐든 서로 통신이 불가능했던 것이죠.)


이를 해결하기 위해 도메인 서비스에 ‘MX레코드’라는 것이 생깁니다. 도메인 서비스에는 A레코드라고 하는 정보를 저장할 수 있는데, 해당 서버의 IP를 입력하면 해당 도메인의 알파벳의 URL을 웹브라우저에서 접속할 경우 A레코드로 돌려주는 전화국같은 기능을 합니다. (‘어? 크롬에서 접속했네? 그러면 넌 A레코드에 적힌 IP 주소에 HTTP 포트인 80번으로 가서 웹페이지를 받아와.’ 라고 안내해주는 거죠.) 그러면 SMTP는 어디로 가야할까요?


속는 셈 치고 인터넷 익스플로러를 여시고 자신의 이메일 주소를 주소창에 입력해봅시다. 검색창 연결이 되어있지 않다면, ‘해당 주소는 찾을 수 없습니다.’라고 뜹니다. 크롬의 경우는 검색엔진으로 자동 이동해버립니다. 주소 접근 자체를 막아버린거죠. 도메인에도 위에 언급한 RFC821(SMTP)같은 프로토콜이 있는데, 아마 ‘@’는 허용하지 않았을 것입니다. 이미 이메일 체계에서 선점했으니까요! 그렇기 때문에 인터넷 브라우저 자체적으로 ‘이상한 주소’라고 판단하고 에러를 출력하거나, 다른 페이지로 연결해버린 겁니다.


메일 프로그램이 ‘어디로 가야하오’를 공허하게 외치지 않도록, 도메인 서비스는 MX레코드를 추가하여 내선 번호가 25인 SMTP 포트로 연결해줍니다. 제 메일 프로그램은 도메인 서비스의 문을 내선 25번으로 두드리고, 도메인 서비스 담당자는 25번임을 알고 SMTP 담당자를 불러 서로 통신할 수 있도록 도와줍니다. 그리하여 ‘test@gmail.com’와 같은 주소와도  통신을 할 수 있게 되었습니다. 저의 빵(메일)셔틀인 메일 프로그램 sendmail은 오늘도 무사히 메일을 전달했습니다.


이런 MX 레코드 역시 역시 DARPA에서 ARPANET을 개발하면서 필요해 만든 것들 중 하나입니다. 결국 SMTP를 더욱 잘 사용하기 위해 주소 체계를 적립하는 과정이었다고 보면 되겠습니다. 해당 RFC 문서를 참조하여(https://tools.ietf.org/html/rfc974 ) RFC 상의 표준 MX 레코드를 통해 ‘어디’에 대한 정보를 어떻게 관리하는지 살짝 확인해보죠:

      A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
      A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP

      B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
      B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP


이게 무엇인지 모르셔도 상관 없습니다. A.EXAMPLE.ORG과 MX, 그리고 10.0.0.1과 같은 익숙한 텍스트를 보시고 대충 의미를 유추하시면 됩니다. 그리고 이제 도메인 서비스가 많이 친절해져서, 이제 도메인 레코드들은 이런 문법을 쓰지않고 훨씬 간단하게 관리할 수 있거든요. (내용은 90% 똑같지만요.) 


무엇을?

MIME이라고 
들어보셨습니까? 안들어 보셨어도 여기까지 읽으셨다면 어쩔 수 없습니다… 입 벌리세요. 바로 심화 들어갑니다아아아


초창기의 컴퓨터는 바이너리 데이터(1001 0100, 혹은 16진수의 0a3b 3dff 등등)로 연산을 처리했지만, 인간의 커뮤니케이션을 위해 금방 문자열을 표기하는 방법을 만들었습니다.



아스키 문자(ASCII)라고 들어보신적 있으신가요? 7비트로 이뤄진 문자표기 방법으로, 알파벳 정도는 간단하게 표현합니다. 예를들어서 아스키의 a는 110 0001입니다. b는 110 0010이 됩니다. 위의 테이블의 규칙을 따라 이진법 1이 증가할 때마다 위와 같은 순서로 문자를 표시할 수 있습니다. SMTP는 원래 아스키만을 지원했습니다. 주고받는 문자열이 아스키 문자에 맞는 바이너리 데이터로 송수신되고, 받는 쪽에서는 그 바이너리를 아스키로 번역해 출력하는 방식입니다.


그러나 우리 한글은 7비트로 표현하기에는 애로사항이 꽃핍니다. 7개의 0과 1로는 가짓수가 너무 적기 때문입니다. 아예 불가능하죠. 이미지나 동영상은 어떨까요? 뭐든 막상 뚜껑을 열어보면 수많은 0과 1, 혹은 16진법의 숫자들일텐데, 이를 읽고 표기할 규칙이 없다면 그냥 더미 파일이 되버릴 것입니다. 이런 규칙을 말 그대로 ‘포맷’이라고 하고, 그 포맷명을 확장자에 담아서 파일화하여 관리합니다.


다시 메일로 돌아갑시다. 위에 작성한 SMTP 프로토콜의 대화가 채팅같지 않나요? 맞습니다. SMTP는 대화형 프로토콜이고, 서버의 응답을 지속적으로 받습니다. 본문에 수신자나 발신자 정보등의 헤더, 제목과 본문등을 입력한 뒤 2번으로 메일을 마무리 짓습니다. 그런데 만약 본문에 제가 확장자 정보와 이미지의 바이너리 데이터를 텍스트로 입력하여 전송하면 어떻게 될까요?


방금 전 우리가 보낸 메일은 안타깝게도 절대 읽을 수 있는 형태로 수신되지 못했을 겁니다. 제가 입력할 때 사용한 문자는 한글 유니코드에 맞는 바이너리를 생성했을 텐데, ASCII에게는 외계어로 보였을 거거든요. 이미지의 바이너리코드도 아마 이상한 텍스트가 되었을 겁니다.


MIME은 Multipurpose Internet Mail Extensions의 약자로, ‘다용도 인터넷 메일 확장방식’ 정도로 번역됩니다. 96년 발표된 이 녀석은(https://tools.ietf.org/html/rfc2045 ) 웹 환경에서도 훌륭히 동작합니다. 아마 웹을 조금이라도 아시는 분들은 이 MIME 타입의 선언을 어디선가 보셨을 겁니다. 


간단하게 표현하면 앞서 말한 파일의 ‘확장자’역할을 해줍니다. 아스키 문자가 아닌 다른 문자 코드의 인코딩이 필요한 경우, MIME을 사용하면 보낼 수 있습니다. MIME으로 Content-Type : x 를 선언한뒤 방대한 양의 데이터를 전송하면 수신자는 ‘아, 이거 ASCII가 아니고 MIME이구나’라고 판단한 뒤, MIME에 선언한 확장자에 맞춰 파일을 변환합니다. 그렇게 이메일은 텍스트 뿐만아니라, 다른 종류의 파일도 품을 수 있는 플랫폼으로 진화한 것 입니다. (실제 현재의 이메일 서비스의 90%는 MIME으로 통신하고 있을 겁니다.)


학창 시절 친구와 쪽지로 영상을 나눠본 적이 없어서, 예시를 들기가 참 어렵습니다. 혹시 좋은 예시가 있다면 알려주세요...


어떻게?

예전에는 메일 서버를 구축하는 일이 결코 쉬운 일이 아니었습니다. 이후 수많은 웹 서비스와 플랫폼이 생기고, 특히 웹 서버를 구축할 수 있게 해주는 기술이 보편화되면서 메일 서비스도 덩달아 편해졌습니다.


이메일 시스템이 어떻게 돌아가는 지를 설명했으니, 이제 실습편입니다. 현재 홍차넷이 굴러가고 있는 제로보드가 사용하고 있는 스크립트 언어 php가, 어떻게 이메일을 처리하고 있는 지 살펴봅시다.


저는 php를 참 좋아합니다. 매우 쉽기 때문입니다. 컴퓨팅 파워가 강력해질 수록 언어는 더욱 인간의 언어처럼 좀 더 쉬운 소통을 위해 진화하고 있습니다. PHP는 탄생한 지 제법된 언어임에도, 끊임없는 업데이트와 강력한 프레임워크의 탄생으로 수명이 연장되고 있습니다.


php에는 mail()이라는 함수가 있습니다. 기능 설명도 무척 심플한데, ‘send mail.’ 이라고만 적혀 있습니다… (http://php.net/manual/en/function.mail.php ) 간단하게 말해 php가 위에 잔뜩 설명한 SMTP 통신을 직접 처리하는 것입니다. 그러나 말이 쉽지, 스크립트 언어인 php가 앞서 설명한 메일 프로그램의 처리를 혼자서 다 해내는 것을 쉽지 않습니다. 그래서 php는 설치된 OS나 환경에 따라 아래와 같이 처리를 해버립니다:


코드에 따르면(https://github.com/php/php-src/blob/php-7.0.0beta3/ext/standard/mail.c#L338 ): 
1. senmail의 바이너리가 설정되어 있지 않고, OS가 Windows 환경, 혹은 Netware 환경이라면 SMTP 프로토콜로 직접 이메일을 전송한다.
2. senmail의 바이너리가 설정되어 있지 않고, OS가 Windows 환경, 혹은 Netware 환경이 아니라면 실패로 처리한다.
3. sendmail의 바이너리가 설정되어 있다면, sendmail을 사용한다.


뭔 말인지 잘 모르시겠으면, 조건을 역으로 읽어 최선의 조건을 먼저 파악하는게 좋습니다. 즉 메일 프로그램인 sendmail이 설정되어 있으면, sendmail을 이용해 상대 서버의 25번 포트로 접속해 SMTP로 대화를 합니다. 만약 sendmail이 없고, 내 OS가 unix계열이라면 smtp 통신용 프로그램이 아예 없으므로 실패 처리를 합니다. (이 때, php측에 실패 로그를 남길 겁니다!) 그리고 내 OS가 윈도 계열이라면 smtp 통신을 직접 할 수 있으니 php 측에서 처리한다. 로 해석하면 됩니다.


홍차넷에는 메일 전송 php를 사용하는 곳이 있습니다. 비밀번호 찾기인데요, 해당 버튼을 클릭한 뒤 이메일 주소를 입력하면 자동으로 메일을 전송합니다. 이제 우리가 여태까지 본 내용을 가지고 순서도를 써봅시다:


1. php: 해당 이메일 주소를 가진 ID와 변경된 비밀번호를 데이터베이스에서 찾음.
2. php: 해당 ID의 비밀번호를 임의의 텍스트로 변경한 뒤 암호화하여 데이터베이스에 저장합니다.
3. php: mail()함수를 사용하여 해당 이메일 주소에 id와 변경된 비밀번호를 전송 요청합니다.
4. sendmail: php에서 온 요청을 받고 수신자의 메일주소를 분석합니다.
5. sendmail: @test.com에 내선번호 25번의 문을 똑똑 두드립니다. 계십니까~
6. sendmail: 문이 열리네요~ 열심히 텍스트로 뚜구닥닥 MIME으로 한글화한 메일 본문을 적어 알려줍니다.
7. sendmail: 상대방이 250 OK! 땡큐! 큐 12345번! 하고 알려주는 걸 확인합니다.
8. sendmail: @test.com과의 접속을 종료. 메일 송신 성공 처리를 php로 토스합니다.
9. php: mail()의 성공여부를 확인한 뒤 남은 코드를 수행합니다.


대충 이런 방식으로 php의 mail()은 굴러갑니다. 그리고 모든 코드가 완벽하게 수행됐다면 php는 페이지 찰나에 ‘메일 송신이 완료되었습니다’라는 js 알림창을 띄우는 웹페이지를 열심히 만들어 웹서버에 돌려주고, 우리 브라우저에 띄울 겁니다.


이 과정에서 만약 오류가 나면 어떨까요? php는 의외로 허술해보이지만, 디버깅 하나만큼은 매우 잘해줍니다. 세미 콜론 하나, 콤마 하나의 오타로 코드는 동작하지 않으며, 중간에 응답이 없거나 느린 상대를 만나면 두부에러가 뜰때까지 끈질기게 기다려 줍니다. 만약 위 동작 중에 어느 하나 문제가 있었다면, php는 반드시 자신의 에러 로그 화면에 무슨 일이 있었는지를 기록합니다. 거기서 뜯어 볼수가 있죠.


sendmail도 smtp를 사용하기 때문에, 상대방의 ‘OK! 땡큐!’ 싸인이 나오지 않은 경우에는 자신의 에러 로그에 기록을 합니다. 그리고 php에게 메일을 보내지 못했음을 알려줍니다만, php 입장에선 성공도 실패도 ‘응답을 받았다’로 퉁칠 수 있기 때문에, 코드의 실행에는 문제가 발생하지 않습니다. 즉 성공 실패 여부에 대한 처리 방법을 우리 쪽에서 손수 짜줘야 합니다.


이제 메일을 어떻게 서로 주고받는지, 그 원리와 심화, 그리고 실습까지 살펴봤습니다. 부족한 부분도, 설명이 나쁜 부분도 피드백 주시면 감사하게 받겠습니다. 최대한 읽기 편한 글을 쓰고자 노력했지만 제 미천한 능력 탓에 너무 고통받지 않으셨으면 좋겠습니다...


왜?

이 모든 글을 쓰게  된 이유는, 회원가입 10시간만에 비밀번호를 잊어버려, 비밀번호 요청 메일을 보냈으나, 메일을 수신받지 못한 한 바보 회원이 있기 때문입니다 ㅠㅠ 운영자님께서 손수 바꿔주신 비밀번호로 로그인한 뒤, 어떤 글을 쓰면 재밌을까… 하고 고민하다 불금 퇴근 한시간 전 열심히 불태워봤습니다.


아, 그리고 한글도 미숙합니다… 오타나 비문이 있으면 꼭 지적해주세요… 달게받겠습니다.


감사합니다.
ikuk 올림


* 토비님에 의해서 티타임 게시판으로부터 게시물 복사되었습니다 (2019-02-01 15:46)
* 관리사유 : 추천게시판으로 복사합니다



17
  • 콤퓨타 싸이언스(?)는 추천!


목록
번호 제목 이름 날짜 조회 추천
752 문화/예술동양의 디즈니를 꿈꾼 일본 애니메이션 백사전의 피 1 레이즈나 19/01/05 5940 11
755 일상/생각노가대의 생존영어 이야기 25 CONTAXS2 19/01/06 6633 25
756 일상/생각대체 파업을 해도 되는 직업은 무엇일까? 35 레지엔 19/01/11 7319 33
757 철학/종교율법주의 : 최후의 유혹 34 구밀복검 19/01/11 8637 28
761 문학서평 - 「나는 나를 파괴할 권리가 있다」 - 김영하 3 메아리 19/01/13 6082 11
758 문화/예술지정문화재와 등록문화재의 간단 정리 13 메존일각 19/01/16 6598 8
760 정치/사회국가유공자등록거부처분취소 소송의 경험 3 제로스 19/01/18 5516 19
759 IT/컴퓨터컴퓨터는 메일을 어떻게 주고 받을까? 13 ikuk 19/01/18 7741 17
762 기타2018 웰컴티파티 후기 16 토비 19/01/22 7151 67
763 여행그저그런의 일본항공 일등석 탑승 후기 (1) 46 그저그런 19/01/24 8726 26
765 일상/생각돈이 없는 것보다 더 부끄러운 것 10 The xian 19/01/31 7457 24
764 체육/스포츠슈퍼볼 53(Super Bowl LIII) 프리뷰 (약스압) 5 Fate(Profit) 19/02/02 6698 11
767 일상/생각혼밥, 그 자유로움에 대해서 13 Xayide 19/02/03 5966 29
766 기타2019 설 예능 리뷰 13 헬리제의우울 19/02/07 5917 16
768 역사삼국통일전쟁 - 11. 백제, 멸망 8 눈시 19/02/10 5004 19
769 정치/사회북한은 어떻게 될까 - 어느 영국인의 관점 85 기아트윈스 19/02/12 9188 79
770 체육/스포츠[사이클] 랜스 암스트롱 (1) - It's not about the bike. 12 AGuyWithGlasses 19/02/17 6170 9
772 일상/생각누가 시킨 것도 아닌데 말이죠 (without even being asked) 10 기아트윈스 19/02/19 5683 64
771 요리/음식영국 음식이 맛이 없는 과학적인 이유 119 문학소녀 19/02/22 11620 106
773 문화/예술우리가 머물다 온 곳 9 사탕무밭 19/02/27 5984 13
774 문학번역본에는 문체라는 개념을 쓰면 안되는가 19 알료사 19/03/01 6606 8
777 일상/생각영국은 섬...섬... 섬이란 무엇인가? 38 기아트윈스 19/03/04 6328 26
776 일상/생각가난한 마음은 늘 가성비를 찾았다 18 멍청똑똑이 19/03/04 6828 46
775 과학수학적 엄밀함에 대한 잡설 29 주문파괴자 19/03/05 9208 18
780 일상/생각'그럼에도'와 '불구하고'의 사이 8 임아란 19/03/12 6166 64
목록

+ : 최근 6시간내에 달린 댓글
+ : 최근 12시간내에 달린 댓글

댓글