수신확인(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에서는 원래 되었던 것인데, 이제야 된다고 할까나요.
사실 수신확인을 실물 우편에 대입해보면 등기우편이라 볼 수 있습니다. 배달 잘 했다~ 라는 거잖아요. 실생활에서 우리가 단순한 편지를 보낼 때 등기로 보내지 않는다는 걸 생각해보면, 과연 모든 메일에 수신 확인을 붙이고, 수신 확인이 되지 않는다면 받는 사람이 메일을 봤는지 안 봤는지를 몰라 의문을 품는다는 행동양태가 바람직한가에 대해서는, 글쎄요, 부정적이라고 밖에 생각이 들질 않는군요. 서로 믿지 않는 온라인에서의 습성이 가장 잘 드러나는 곳이 메일의 수신확인 기능이라고 보면 무리일까요?
사족인데, 메일 담당을 꽤나 오랫동안 하니 점점 실물우편의 매력이 느껴진다는 것이 재밌네요.
출처 : http://widelake.net/5
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에서는 원래 되었던 것인데, 이제야 된다고 할까나요.
사실 수신확인을 실물 우편에 대입해보면 등기우편이라 볼 수 있습니다. 배달 잘 했다~ 라는 거잖아요. 실생활에서 우리가 단순한 편지를 보낼 때 등기로 보내지 않는다는 걸 생각해보면, 과연 모든 메일에 수신 확인을 붙이고, 수신 확인이 되지 않는다면 받는 사람이 메일을 봤는지 안 봤는지를 몰라 의문을 품는다는 행동양태가 바람직한가에 대해서는, 글쎄요, 부정적이라고 밖에 생각이 들질 않는군요. 서로 믿지 않는 온라인에서의 습성이 가장 잘 드러나는 곳이 메일의 수신확인 기능이라고 보면 무리일까요?
사족인데, 메일 담당을 꽤나 오랫동안 하니 점점 실물우편의 매력이 느껴진다는 것이 재밌네요.
출처 : http://widelake.net/5
반응형
'server-side > mail' 카테고리의 다른 글
| apt-get install sendmail (0) | 2010.08.07 |
|---|