Changwoo's Hacks

한메일Express라는 것에 당첨되었다...라고 하는 메일이 한메일에 쌓였길래, 보려고 했더니 왠일인지 똑같다. 뭔가 이상해서 환경설정에서 Express 사용여부를 설정하면서 자세히 관찰해 보니까 뭔가 다른 페이지를 들어가려고 하다가 나가는 현상이 보였다. 그 순간에 나왔다 사라지는 한마디, "IE, Firefox 1.5, ... 이상에서만 사용할 수 있습니다."

"지금 iceweasel 무시하나요?"를 머리속에 대뇌이면서 about:config 에서 user-agent 값을 firefox로 고쳐버렸다. 그러니까 무리 없이 한메일Express로 잘 전환되었다.

그런데 머리 속을 스치고 지나가는 생각. "지금까지 티스토리의 에디터가 epiphany에서만 동작하고 iceweasel에서 동작하지 않은 원인이 설마 이것일까?" 지체없이 티스토리로 로그인, 에디터를 써 본 결과 맞았다. 얄밉게 잘 동작하는 에디터...  (epiphany에서도 찾아보니까 예전에 user-agent를 고친 설정이 남아 있었다.) 한메일은 그렇다 쳐도, 태터툴즈 에디터가 user-agent를 보고 다르게 동작할 줄은 꿈에도 몰랐다.


PS. "어쩔 수가 없이 이렇게 만들었다"라고 하기엔 iceweasel이라는 user-agent로 잘 동작한 웹용 에디터들이 너무 많다.

그놈 에볼루션은 비교적 최근에 만들어진 메일 프로그램이라서 그런지 인터넷 메일의 표준에는 맞지만 현실과는 동떨어진 방식으로 동작하기도 한다. 슬프게도 한글과 관련된 부분에서 그런 모습이 많이 보인다.

예를 들어 좀 구버전의 MS-Outlook 혹은 MS-Outlook Express에는 헤더를 RFC2047 인코딩할 때 UTF-8로 인코딩하면 제대로 읽지를 못했다. 멀티바이트 인코딩은 본문 인코딩과 관계없이 대충 UTF-8로 보내는 정책을 사용했기 때문이다. 이렇게 동작하는 게 틀린 건 전혀 아니고, RFC2047을 지원하면서 UTF-8 인코딩이 지원되는 환경이므로 당연히 MS-Outlook의 잘못이고, 이 제목이 제대로 읽히도록 MS가 Outlook을 고쳐야 하는 게 맞다. 하지만 현실적으로 MS-Outlook은 사용자가 많아서 무시하기 힘든데다가 상업용 소프트웨어는 이러한 버그가 수정되려면 너무 오래 걸린다. (최근 버전에 고쳐질 때까지 2-3년은 걸린 듯)  표준을 지키는 다른 방법이 있으면서, 많이 사용하는 프로그램의 버그를 피해가는 방법이 있다면 꼭 에볼루션이 맞다고 고집할 필요는 없지 않을까? 하지만 게으른 개발자의 속성상 자기 잘못도 아닌데 귀찮게 고치기도 힘들 노릇이어서 결국 아직까지도 그렇게 동작한다. 내가 직접 본문이 EUC-KR일 때 제목이 EUC-KR 인코딩되도록 패치까지 만들었지만, 적용될 수는 없었다. (기술적인 이유도 있었다. 에볼루션의 코드의 메일 처리 라이브러리쪽에서 헤더를 독립적으로 UTF-8 인코딩해 버리는 구조였는데, 메일 설정이 넘어가도록 고치려면 상당히 귀찮은 작업이 필요하다.)

오히려 이런 문제는 MS-Outlook같은 데스크탑 프로그램보다는 각종 웹메일들에서 특히 잘 드러난다.  (아무래도 웹메일들이 데스크탑용 프로그램보다는 메일 표준을 구현한 완성도가 비교적 떨어지는 게 사실이다.)  마침 한메일이 개선사항을 모집한다고 하니 에볼루션과 한메일이 메일을 주고받을 때 생기는 버그 및 기타 리눅스 환경에서 생기는 문제를 짚어본다.

(1) Q 인코드된 제목의 디코딩

이 문제는 보고를 했는데 고객센터에서도 전달되었다고 하고, 다른 경로(?)로도 전달되었는데 우선순위가 밀렸는지 아직 버그가 남아 있는 상태이다.

위의 예에서와 같이 에볼루션에서 보내는 메일의 한글 제목은 UTF-8 인코딩하게 되는데, 그것도 Quoted Printable 인코딩이다. 그런데 에볼루션에서 메일을 이렇게 보내면,


한메일에서는 이렇게 공백이 밑줄로 나온다..


그런데 이상하게도 클릭해서 본문을 읽어보면 제대로 나와 있다.

Subject: =?UTF-8?Q?=EC=A0=9C=EB=AA=A9?=
        =?UTF-8?Q?_=ED=85=8C=EC=8A=A4=ED=8A=B8?=

"제목 테스트"라는 제목을 UTF-8 QP 인코딩하면 위와 같이 된다. RFC2047에 따르면 Quoted Printable을 디코딩할 때 밑줄(_)을 공백으로 해석해야 하는데 실수를 한 것 같다. 그런데 대체 왜? 메일 본문을 읽어보면 제대로 나오는 걸까? 메일 목록과 메일 본문의 QP 디코드 코드가 다른 걸까?


(2) 첨부파일 내용 인코딩

에볼루션이 아니라 (이제 거의 모두 UTF-8환경인) 리눅스 환경과의 호환성 문제이지만, 첨부 파일의 Content-Type의 charset 정보를 제대로 인식하지 않는다.


Content-Type의 charset 정보를 무시하고 EUC-KR로 해석하는 듯?
 

--=-ObVHrT1mp3C0HEttZi/U
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; name*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
=EC=97=90=EB=B3=BC =EB=A7=8C=EC=84=B8
 
 
--=-ObVHrT1mp3C0HEttZi/U--

(3) EUC-KR 페이지의 한계

다음이 많은 부분에서 UTF-8 페이지로 변환하고 있지만, 아직 한메일은 그렇지 못하다. 그래서 아무래도 해외 메일을 받는 용도로는 한계가 있을 수밖에 없다. 일본어 메일만 해도 많은 한자가 물음표 투성이가 된다.



(4) 보너스#1 - 빈 파일을 첨부하면

이 글을 쓰면서 발견한 건데...  사이즈가 0인 파일을 첨부한 다음에 첨부한 파일을 열려고 하면 오류가 발생한다.

--=-Jc22aP0z5j1kvSIVKmG+
Content-Description: =?UTF-8?Q?=EC=97=90=EB=B3=BC?=
    =?UTF-8?Q?_=EB=A7=8C=EC=84=B8=EC=97=AC?=
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
 
 
--=-Jc22aP0z5j1kvSIVKmG+--

(5) 보너스#2 - HTML 메일이 싫어요~

또 찾아낸 명백한 버그, 보낼때 하단에 있는 옵션을 어떻게 하든 항상 HTML 메일만 날아온다.