2009년 5월 19일 화요일

이메일 동작원리와 수신확인 (How Email works and info. about receive receipt)

우리가 현재 인터넷에서 일상적으로 사용하고 있는 이메일은 인류 역사상 매우 오랜 기간동안 사용되어 왔던 우편제도를 거의 그대로 모방하여 만들어 졌다.


우리가 편지를 보낼 때를 생각해 보면 편지지에 내용을 적고 편지봉투에 집어넣은 다음 봉투에 발신자 주소와 수신자 주소를 적는다. 그리고 우표를 붙인 다음 우체통에 집어넣으면 보내는 사람의 할 일은 더 이상 없어진다. 나머지 역할인 편지를 수신자에게까지 전달해 주는건 우체국에서 하는 일이고 언제 우체통에서 편지를 수거해 가는가, 어떤 방법으로 어느 경로를 거쳐 우리동네 우체국에서 수신자가 사는 동네의 우체국까지 편지를 옮길 것인가, 수신자네 동네 우체국에서 언제 어떻게 수신자 집으로 편지를 가져다 줄 것인가는 전적으로 우체국이 결정하는 것이지 편지를 보낸 사람이 결정할 수 있는게 아니다. 또한 수신자 집에 편지가 배달되었다고 해도 언제 그 사람이 편지를 읽는지, 아니 편지를 읽었는지 조차 알 수 있는 방법이 없다.

위의 과정이 이메일에도 거의 동일하게 적용된다.



이메일을 작성하는 경우 본문에 원하는 내용을 적고 메일 헤더에 발신자 이메일 주소, 수신자 이메일 주소를 넣어주고 이메일을 발송한다. 여기까지가 이메일을 보내는 사람이 해야 할 일이다. 나머지 역할인 이메일을 수신자 이메일 계정으로 전달해 주는건 인터넷(정확하게 말하자면 인터넷에 있는 메일서버들)이 알아서 하게 된다. 어느 메일서버를 거쳐 언제 이메일을 전달할 것인가는 전적으로 메일서버들이 결정하는거지 이메일을 보낸 사람이 결정할 수 있는게 아니다. 또한 편지와 마찮가지로 이메일이 수신자 메일함에 전달되었다 해도 그걸 읽었는지 여부나 언제 읽었는지는 알 수 있는 방법이 없다.




물론 편지에도 예전부터 본문이나 PS에 '읽었으면 읽었다고 알려달라'고 부탁을 할 수도 있지만 그건 편지를 받은 사람이 그 부탁에 응해주는 경우에만 의미가 있는 것이다. 이메일 표준에도 이와 유사하게 RFC3798등에서 메일 헤더에 메일을 읽었다는 receipt를 보내달라고 요구하는 필드가 추가되기도 했다. 하지만 이 역시 수신자가 receipt를 보낼건지 확인을 해 줘야만 receipt가 보내지는 문제도 있고 모든 이메일 클라이언트가 이 확장필드를 인식하지 못하기 때문에 널리 쓰여지지는 못했다.

그렇다면 '어 내가 쓰는 이메일에는 수신확인 기능이 있는데 이건 뭐냐?'는 사람들이 있을 것이다. 쉽게 이야기하자면 그건 특정 메일 서비스 내에서만 동작하는 일종의 편법을 이용한 방법이다. 하지만 그런 방법들은 표준화가 된 것도 아니고 편법을 이용하는 것이기 때문에 송신자, 수신자 모두 같은 이메일 서비스(예를 들어 둘 다 한메일 또는 네이버메일 등등)를 이용하는 경우에만 "가능할 수도 있는" 방법일 뿐이다.동작원리는 이메일은 위에서 말했듯이 일단 보내고 나면 송신자는 그 이메일에 대한 통제력(내용수정, 삭제 등등)을 완전히 잊어버리게 된다. 그래서 이메일을 보낼 때 메일서비스가 이메일의 본문 내용 안에 사람들에게는 보이지 않게 조그마한 이미지 주소를 임의로 넣어 보낸다. 그 이미지 파일 주소는 해당 메일 서비스 서버의 주소이다. 그렇기 때문에 수신자가 메일을 읽을 때 눈에는 보이지 않지만 숨어있는 이미지를 화면에 표시하기 위해 메일서비스 서버를 억세스 하게 된다. 그 파일이 억세스 되면 메일을 읽은 것으로 간주하고 그 시간을 메일을 읽은 시간이라고 알려주게 된다.



위쪽 그림이 정상적 이메일인 경우이다. 송신자의 메일 서버가 수신자의 메일서버로 메일을 전달하면 수신자가 메일을 읽을 때 그냥 수신자의 메일서버에서 메일을 읽을 뿐 송신자 서버에 아무 통보가 없다. 그에 비해 아래쪽의 편법을 사용하면 메일 내에 <img> 태그가 들어있고 그 태그가 송신자 메일서버에 있는 이미지 파일을 가르키고 있기 때문에 메일을 보여줄 때 그 파일을 요구하게 된다. 송신자 메일서버는 그 파일이 요구된 시간을 기록하고 그걸 수신자가 메일을 읽은 시간이라고 알려주게 된다.

그런데 최근에는 대부분의 이메일 서비스나 이메일 클라이언트들은 메일 본문에 들어있는 이미지 파일들을 기본적으로 보이지 않게 되어있는 경우가 많다. 이렇게 되어 있으면 메일을 읽더라도 그 안에 안보이게 숨어있는 이미지를 억세스 하지 않기 때문에 심지어 송신자/수신자가 같은 메일 서비스를 사용하더라도 수신자가 웹으로 억세스하지 않고 POP3/IMAP을 통해 이메일 클라이언트를 사용하면 메일을 읽었더라도 수신확인에는 읽지 않았다고 나오게 된다.

결론적으로 이메일 수신확인 서비스라는건 정확하지도 않은 편법일 뿐임으로 너무 믿지 말라는 것이다. 수신확인을 했는데 혹시 언제 읽었다고 나오면 그건 일단 읽었다고 생각해도 큰 무리는 없지만 아직 읽지 않았다고 나오는건 진짜 안 읽은건지 편법이 먹히지 않아 읽었는데 안 읽은걸로 나오는건지 확인할 방법은 전혀 없다는 것이다. 요점은 국내 웹메일들의 수신확인 서비스라는걸 너무 믿지 말라는 것이다.

댓글 3개:

  1. 마지막줄이 의미심장하군요. 네이버의 수신확인 서비스가 마지막 말씀과 강력한 연관이 어쩌면 있을 수도 있겠다는 생각이 듭니다. :D

    답글삭제
  2. 그렇죠... imap으로 읽는데... 게다가 image는 항상 block 시켜놓는데... 왜 메일 안읽고 있냐고 자꾸 뭐라 그러는 학생들이 있어서 피곤합니다 ㅜㅠ

    답글삭제
  3. 이런 이메일 확인 기술들은 스펨메일에 메일주소 유효성 확인을 위해 더 많이 쓰이죠 ^^

    답글삭제