수신확인(Message Disposition Notifications)

Message Disposition Notifications, 줄여서 MDN이라는 기능은 메일을 처리한 방법을 발신자에게 알려주는 기능입니다. 즉, MDN 자체는 상대방이 수신을 했는지(메일을 열어봤는지) 여부만을 알려주는 것이 아니라, 제대로 발송되었다, 메일이 상대방 INBOX에 들어가긴 했는데 상대방이 읽지 않고 삭제했다 등등 여러가지 처리된 결과를 알려주는 종합적인 알림이지요. RFC 2298에서 3.2.6.2 Disposition Types을 보면 생각보다 많은 타입들이 규정되어있습니다.

  • displayed : 정상적으로 배달되어 메일 유저 에이전트(메일 인터페이스)에서 해당 메일이 개봉되었다.
  • dispatched : 수신자의 확인 여부와 관계없이 해당 메일에 특정한 액션(프린트, 포워드, 팩스 등)이 가해져 어디론가 보내졌다. 원 수신자는 해당 메일을 확인할 수도, 확인하지 못할 수도 있다.
  • processed : 해당 메일이 원 수신자에게 보여지지 않고 어떠한 액션(자동분류 등)이 취해졌다. 원 수신자는 해당 메일을 확인할 수도, 확인하지 못할 수도 있으며, 심지어 수신자가 사람이 아닐 수도 있다.
  • deleted : 해당 메일이 지워졌다. 원 수신자는 해당 메일을 확인할 수도, 확인하지 못할 수도 있으며, undelete 커맨드를 실행시켜 메세지를 복구 후 확인할 수도 있다.
  • denied : 원 수신자가 처리 상태를 알려주는 것을 거부했다. 물론 이 상황에서는 메일 유저 에이전트가 메일 처리상태 안내요청(Message Disposition Requests)를 무시했을 수도 있다.
  • failed : 적합한 MDN 생성에 실패했다.

뭐 대충 이 정도이지만, 보통 수신확인하면 가장 첫번째, displayed를 생각하게 되고, 또 가장 많이 쓰기도 합니다. 나머지 것들은 거의 사용하지 않지요. 적어도 우리가 쓰고 있는 메일 서비스에는 말입니다.

한국내 포털에서 이용하고 있는 수신확인 방법은 위에 얘기한 RFC 2298 MDN을 사용하지 않습니다. 예전에 오르지오가 특허를 낸 사항인데, 지금이야 다들 쓰고 있지요. 쉽게 설명하자면 바로 메일 내에 안 보이는 이미지, 1 by 1 또는 0 by 0 픽셀의 투명이미지를 img src 태그로 삽입합니다.


* 두 경우 모두 key값은 임의 문자로 대체했습니다.

이러한 방식들의 문제라 하면, 만약 메일 유저 에이전트가 이미지 로딩을 차단할 경우, 수신 확인 기능 자체가 먹통이 된다는 것입니다. 아웃룩 익스프레스와 아웃룩, 모질라 썬더버드 등의 데스크탑 애플리케이션은 물론, Gmail도 기본적으로 허용하기 전까지는 모든 이메일의 이미지 로딩을 막고 있습니다. 결국, 수신자가 위에 말한 데스크탑 메일 애플리케이션을 쓰는 경우나, Gmail을 쓰는 경우 국내 포털 식의 수신 확인은 작동하는 경우가 거의 없다시피 한겁니다. 그래서 “수신자가 메일을 봤다는데 수신확인이 안되어있어요” 류의 컴플레인이 메일 서비스 CS 쪽으로 접수되는 거구요.

썬더버드에서 이미지 로딩을 허용하는 경우 아래와 같이 나오던 것이,

차단하면 아래처럼 변합니다.

이미지 로딩시에는 해피빈 콩알 아이콘과 네이버 로고만 나오지만, 이미지 로딩을 차단해보면 그 아래 이미지가 또 하나 자리잡고 있는게 보이는 것이죠. 그리고 이 숨겨진 이미지의 경로는 위에 언급한 그 수신확인용 경로입니다.

이렇다보니 아웃룩, 썬더버드 등에서 이미지 로딩을 차단하지 않을 때, 그리고 Gmail이 등장하기 전에, 즉 Phising이나 Scam 문제가 심각하게 다루어지지 않을 때는, 아무리 수신 확인을 해주고 싶지 않아도 울며 겨자먹기로 체크를 해줘야만(자의와는 관계없이) 했던 메일 수신자가 메일 수신 여부를 확인해줄 수 있는 권한이 자동으로 부여되었습니다. MDN에서는 원래 되었던 것인데, 이제야 된다고 할까나요.

사실 수신확인을 실물 우편에 대입해보면 등기우편이라 볼 수 있습니다. 배달 잘 했다~ 라는 거잖아요. 실생활에서 우리가 단순한 편지를 보낼 때 등기로 보내지 않는다는 걸 생각해보면, 과연 모든 메일에 수신 확인을 붙이고, 수신 확인이 되지 않는다면 받는 사람이 메일을 봤는지 안 봤는지를 몰라 의문을 품는다는 행동양태가 바람직한가에 대해서는, 글쎄요, 부정적이라고 밖에 생각이 들질 않는군요. 서로 믿지 않는 온라인에서의 습성이 가장 잘 드러나는 곳이 메일의 수신확인 기능이라고 보면 무리일까요?

사족인데, 메일 담당을 꽤나 오랫동안 하니 점점 실물우편의 매력이 느껴진다는 것이 재밌네요. ⓣ

9 댓글

  1. 아웃룩에 있는 추적 기능이 RFC 2298 MDN을 이용한 것 같네요. 다른 서비스들도 저 기능을 이용하면 좋을 것 같은데요.

    1. 네. 아웃룩의 추적 기능이 MDN을 이용한겁니다.
      저희꺼는 MDN 이용해서 추적을 해주진 않아도 리퀘스트 들어오면 처리는 해줍니다. ㅎ_ㅎ

  2. RFC 3798 obsoletes RFC 2298 ㄳ

    누가 RFC 아니랄까봐 1/4도 안읽었는데 잠이온다아 후덜덜

    1. RFC 조낸 졸림…. ㅠㅠ

      3798이 2298을 대체하긴 하는데에… 어차피 2298을 기반으로 하는 RFC라 현존하는 기능들을 굳이 3798 을 기반으로 해서 뜯어고칠 필요까진 없음. -_-)a 2298 준수하는 곳도 손에 꼽는디 뭐.. -_-;

  3. 덕분에 gmail이 RFC 2298을 지키는지를 뒤지다가 엉뚱하게 systemwebmail.com이라는 됴흔 사이트를 찾았음……
    그냥 횽한테 감사할께염 (ㄳㄳ)

    ps. 그런데 유독 “이 페이지” 레이아웃은 파폭에서 박살남…

    1. Gmail이 RFC2298에 처리를 해주던가..? 안해주던거 같은데. 그건 한번 테스트해봐야할 듯 하고… systemwebmail.com은 ASP니 나랑은 관계없음 낄낄

      그리고 이 페이지 레이아웃은.. 저기 드림위즈 수신확인 URI가 개행이 안되서-_- 이미지로 대체해넣었3

  4. 지메일로 업무처리를 하고 있는데, 수신확인이 안된다는 원성이 사무쳐서 공지사항에 이 포스트를 링크시켰습니다. 그래도 되겠지요?

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.