영문 썬더버드 1.0 에서 한글로 새 메일 작

[baboojoon]

안녕하세요

현재 미국에서 영문판 썬더버드 1.0을 쓰고 있는 유저입니다.

우선... .다른 곳에서 오는 한글로 써 져있는 메일을 받으면 잘 보입니다. 대부분 EUC-KR로 인코딩 되어 있더군요.

제가 겪고 있는 문제는... 썬더버드에서 한글로 새 메일을 작성하고 (엔코딩은 물로 EUC-KR로 했습니다) 테스트 삼아 메일을 제 계정으로 보내서 읽으려고 하면, 제목 라인은 한글로 잘 나옵니다만 한글로 쓴 본문이 전혀 나오질 않는군요. 영문과 같이 본문을 작성하면 한글은 안나오고 영문만 나옵니다.

옵션에서 폰트 설정은 보내는 메일/받는 메일 모두 티폴트로 EUK-KR로 설정 했습니다.

또 엔코딩 커스텀 리스트에 EUC-KR과 UNICODE를 포함해서 대략 5~6개 정도의 한글 엔코딩도 추가해 놨구요.


한가지 더는, 제가 외국에 사는 관계로 대부분의 메일을 영문으로 작성하여 보내야 합니다. 따라서 제가 작성하는 메일은 영문 기본인 Western (ISO-8859-1)로 보내야 하는데, 혹시라도 제가 EUC-KR엔코등으로 영문으로만 편지를 작성하여 보내면, 영문 윈도우와 영문 어플리케이션을 가진 상대방에게는 어떻게 보일까요? 그것이 궁금합니다.


읽어주셔서 감사합니다. .빠른 도움이 필요합니다..

[빛알갱이]

1. ISO-8859-1이나 EUC-KR은 다 구시대의 유물이므로 버리고 모든 경우에 UTF-8로 보내세요. 단, 가끔 UTF-8을 처리하지 못 하는 메일 프로그램/웹 메일 서비스 사용자가 있을 수 있으니 주의하세요.

이렇게 하기로 하시면 아래 2번은 안 읽으셔도 됩니다.

2. EUC-KR은 ASCII 부분은 US-ASCII와 완전히 동일하므로, EUC-KR이라고 설정을 해 둔 채로 US-ASCII만을 포함하는 메일을 보내면 TB는 메일 헤더에 다음과 같이 해서 내보냅니다.

Content-Type: text/*; charset=US-ASCII
Content-Transfer-Encoding: 7bit

따라서, 문제 없습니다. 아참, MS OE가 이렇게 온 메일에 대해 답장할 때 헛갈려 하는 문제가 있어서 TB 1.0에서는 그 경우에도 'EUC-KR'이라고 tag을 붙이도록 고쳐 놓았군요. (US-ASCII만 들어간 메일을 EUC-KR, ISO-8859-1, UTF-8, US-ASCII 등 가운데 어느 것으로 인코드되었다고 불러도 다 맞는 말입니다. 왜냐하면 이들 모두는 US-ASCII 부분을 공통으로 커버하니까요.).

영어 메일을 많이 보내시면 - 1번을 강력히 추천하지만- 원하신다면 기본을 ISO-8859-1로 해 놓고 쓰셔도 됩니다. 이런 상태에서 한글 메일을 보낼 경우에 TB가 경고를 합니다. 현재 설정한 인코딩이 메일 본문 속의 글자를 커버하지 못 하니까 UTF-8로 바꿔서 보내든가, 아니면 되돌아가서 다른 인코딩을 선택하라고요.

[빛알갱이]

제가 겪고 있는 문제는... 썬더버드에서 한글로 새 메일을 작성하고 (엔코딩은 물로 EUC-KR로 했습니다) 테스트 삼아 메일을 제 계정으로 보내서 읽으려고 하면, 제목 라인은 한글로 잘 나옵니다만 한글로 쓴 본문이 전혀 나오질 않는군요. 영문과 같이 본문을 작성하면 한글은 안나오고 영문만 나옵니다.

이것은 TB 문제가 아니라, 님이 사용하는 ISP의 SMTP server 문제 같군요. (엄밀하게 말하면, RFC 1630?을 따르지 않은 TB의 문제입니다. 8BITMIME ESMTP 확장을 지원하지 않는 SMTP 써버를 통해 메일을 보낼 경우에는 자동으로 Base64/QP를 써야 하는데, 그렇게 하지 않은 셈이니까요. ) 받은 메일의 소스 보기를 해서 소스를 그대로 긁어서 여기에 올려 보세요. (메일 주소 등은 원하시면 제거하시고요)

해결책은 TB 확장 가운데 'about config' 확장을 구해서, 'about:config'를 여신 다음에 'mail.strictly_mime'을 true로 바꾸고 보내세요.

[baboojoon]

답변 감사합니다.

제가 지금 방금 UTF-8 엔코딩으로 시험을 해 봤습니다. SMTP서버는 Gmail 서버이구요, 똑같은 계정으로 (받는 사람도 같은 메일주소) 같은 메일을 두 번 보내봤습니다.

제목라인과 본문 모두다 한글과 영어를 포함하고 있구요

처음 보냈을때 한글이 제대로 나오더군요. 헤더를 열어보니:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

이것을 확인 한 후 같은 내용을 다시 한번 보냈습니다. 그런데, 이번에는 한글과 영문이 모두 깨져 나오더군요. 헤더의 내용은 다음과 같습니다.
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding; base64


흠... 왜 같은 서버로, 같은 내용과, 같은 인코딩으로 보냈는데, 두 메세지의 헤더가 차이가 날까요? 처음 한글/영문이 제대로 나온 메일 헤더에는 "format=flowed'"가 있고 , 그렇지 않은 메일에는 그것이 없더군요. 또한, 한글/영문이 제대로 나온 메일 헤더에는 Content-Transfer-Encoding이 8bit으로 나오는데, 그렇지 않은 메일의 경우에는 base64로 나오더군요. 이것참...

혹시 다른 Gmail SMTP서버를 사용하시는 분도 같은 현상이 일어나는지요.

[baboojoon]

방금 저 위에서 알려주신대로 about config 세팅을 바꾸어 보았습니다. 하지만 결과는 실패. 이번에는 본문을 한글과 영문으로 "세팅 about config"라고 적어서 보냈더니, 도착한 메일에는 본문이 "7IS47YyFIGFib3V0IGNvbmZpZyB0cnVlDQo=" 이렇게 표시되더군요. Content-Type: text/plain; charset=UTF-8 이구요, Content-Transfer-Encoding 라인은 찾을 수 없더군요.

[baboojoon]

죄송합니다. 한가지 더 질문하겠습니다.

저의 짧은 지식으로 볼때에는 Content-Transfer-Encoding이 8bit으로 되어 있을때에만 한글/영문이 제대로 깨지지 않고 나오는 것 같군요. 이것을 강제로 8bit에 맞추도록 하는 방법은 없나요? 새 메일을 보낼때 대부분 base64로 되더군요, 아까 위에서 어쩌다 한번 8bit으로 되고는 그 후부터는 계속 base64입니다... 글씨도 역시 깨지고 있구요.

도움이 필요합니다.

[마잇]

gmail smtp로 UTF-8, EUC-KR로 각각 보냈을때 받아본 메일 두가지의 헤더를 올려 보겠습니다. 썬더버드 옵션중에 보기 -> 문자 인코딩 -> 자동 선택 -> 한국어 이 부분이 활성화 되어 있어야 각각의 인코딩으로 온 메일이 제대로 보이더군요. 자동 선택을 끄면 두 메시지 전부 깨져 보입니다.

UTF-8로 보낸 메시지

Code: Select all

Subject: test =?UTF-8?B?7YWM7Iqk7Yq4?=
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

test 테스트

EUC-KR 로 보낸 메시지

Code: Select all

Subject: =?EUC-KR?B?xde9usauIHR0ZXN0?=
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit

ttest 테스트

Base64인코딩으로 바뀌는 문제는 about:config로 설정하신것과 관련이 있지 않을까 생각됩니다.

# 근데 전 gmil -> gmail로 보내면 그 메시지는 pop로 받아지지가 않던데(본인이 본인한테 보낸 메시지) 어떻게 받을수 있는지 궁금하네요. 위 메시지들은 pop지원되는 다른계정으로 보내서 확인했습니다.

[빛알갱이]

gmail smtp로 UTF-8, EUC-KR로 각각 보냈을때 받아본 메일 두가지의 헤더를 올려 보겠습니다. 썬더버드 옵션중에 보기 -> 문자 인코딩 -> 자동 선택 -> 한국어 이 부분이 활성화 되어 있어야 각각의 인코딩으로 온 메일이 제대로 보이더군요. 자동 선택을 끄면 두 메시지 전부 깨져 보입니다.

이것은 매우 신기한 일이군요. 명시적으로 charset이 지정된 메시지라면 자동 선택 옵션을 켜야 할 이유가 전혀 없습니다. 그 옵션은 MIME 표준을 지키지 않고, charset을 지정하지 않고 보내는 메시지를 다루기 위해서만 필요한 것인데, 요새는 그런 메일이 거의 없기 때문에 쓸 일이 없습니다. (메일의 경우는. 웹 페이지는 다릅니다.) 혹시, 'Apply default encoding to all mressages (ignore individual character encoding setting)'을 켜 놓으신 것 아닙니까?

Base64인코딩으로 바뀌는 문제는 about:config로 설정하신것과 관련이 있지 않을까 생각됩니다.

라틴 글자와 숫자만 제대로 보이고, 한글이 깨져 보인다고 하셔서, SMTP server가 8BITMIME extension을 지원하지 않는, 즉 8bit octet의 MSB(최상위 비트)를 다 날려 버리는 녀석인 줄 알고 base64로 보내도록 강제하기 위해서 그 옵션을 true로 고치라고 말씀 드린 것입니다. 그런데, base64로 보냈을 ㅤㄸㅒㅤ 오히려 안 보인다고 하시니, 신기한 노릇이군요.

안 보이는 메시지의 소스 전체(머리와 몸체 모두 다 포함해서)를 올려 주시겠습니까?

혹시, Enigmail 확장을 사용하고 계십니까? 위에 올린 메일 헤더를 보니 Enigmail이 붙인 헤더가 있네요. TB 자체의 문제가 아니라 Enigmail이 MIME을 다루는데 버그가 있나 봅니다. Enigmail을 제거하시거나 기능을 끄시고 다시 해 보시는 게 좋겠습니다.

[마잇]

이것은 전혀 이해할 수 없는데요. 명시적으로 charset이 지정된 메시지라면 자동 선택 옵션을 켜야 할 이유가 전혀 없습니다. 그 옵션은 MIME 표준을 지키지 않고, charset을 지정하지 않고 보내는 메시지를 다루기 위해서만 필요한 것인데, 요새는 그런 메일이 거의 없기 때문에 쓸 일이 없습니다. (메일의 경우는. 웹 페이지는 다릅니다.) 혹시, 'Apply default encoding to all mressages (ignore individual character encoding setting)'을 켜 놓으신 것 아닙니까?

이건 제가 큰실수를 했네요 이미 제대로 보고 있던 상태에서 자동 선택을 사용 안함으로 바꿀경우 메시지 본문에 메일 원문 헤더가 주루룩 나오는데 이걸 제가 얼핏 보고 깨진다고 생각했습니다. 이상태에서도 끄트머리에 본문내용은 제대로 나오고 다른 메시지들을 클릭했다 다시 클릭해주면 평소 보던대로 본문만 제대로 나오네요. 자동 선택과는 무관한 문제가 맞습니다.

baboojoon님이 말씀하신 Base64 문제는
편집 -> 설정 -> 작성 -> 8비트 문자로 메시지를 보내려면 'quoted-printable' MIME형식으로 보내야 하며, 아래 옵션을 선택하지 않음
저런 옵션이 있길래, 저걸 체크 하고 메일 보내 보니까 이렇게 가더군요.

Subject: tst =?UTF-8?B?44WM7Yuw7Yuw7Yuw?=
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

64uI64uI7JWEdHRzZHNnICAK <-- 본문(기본 보기 상태에서는 한글로 잘 보입니다)

참고하셔서 설정 잘 되시길 바랍니다

#

해결책은 TB 확장 가운데 'about config' 확장을 구해서, 'about:config'를 여신 다음에 'mail.strictly_mime'을 true로 바꾸고 보내세요.

이 부분이 위에 옵션하고 관련 있지 않나 생각되네요

[MEIN]

처음 보냈을때 한글이 제대로 나오더군요. 헤더를 열어보니:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
...
혹시 다른 Gmail SMTP서버를 사용하시는 분도 같은 현상이 일어나는지요.

Gmail SMTP 로 메일을 여러번 보내 보았습니다.
UTF-8 이든 EUC-KR 이든 전혀 문제 없이 정상적으로 작동합니다.

똑같이 TB 1.0 영문판을 사용하고 있습니다만..
빛알갱이님 말씀처럼 우선 enigmail이나 기타 확장을 제거해 보시면서 테스트하시는 게 좋지 않을까 싶습니다.

[baboojoon]

여기 문제의 한글이 깨지는 메일 헤더 내용입니다.

From - Mon Jan 17 23:46:46 2005
X-Account-Key: account4
X-UIDL: 0f573c36bc91a7d2b90385dcbf54572b
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Apparently-To: ID@yahoo.com via 206.190.39.135; Mon, 17 Jan 2005 20:46:08 -0800
Authentication-Results: mta241.mail.scd.yahoo.com
from=gmail.com; domainkeys=fail (bad sig)
X-Originating-IP: [64.233.184.196]
Return-Path: <ID@gmail.com>
Received: from 64.233.184.196 (EHLO wproxy.gmail.com) (64.233.184.196)
by mta241.mail.scd.yahoo.com with SMTP; Mon, 17 Jan 2005 20:44:13 -0800
Received: by wproxy.gmail.com with SMTP id 37so140468wra
for <ID@yahoo.com>; Mon, 17 Jan 2005 20:44:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-iduser-agent:x-accept-language:mime-version:content-type:to:subject:from;
b=YGwimGTkxSGjZ4ElhFOq4gnQ9faZu2DPDsisu5NFTE/xKjy8FaevVDfvAxRKF836UgZxY4s82ij/0fbqNHkdFvpDJb/8zn+Cbr43xCnAMqD6PwKL1nwLK2j01R3fNSIk3TxCYAHq30j7KmavkdANK7TAm9HkxfwpPC4qHHoTuCA=
Received: by 10.54.49.6 with SMTP id w6mr274749wrw;
Mon, 17 Jan 2005 20:44:10 -0800 (PST)
Return-Path: <ID@gmail.com>
Received: from ?192.168.11.3? ([68.100.11.196])
by smtp.gmail.com with ESMTP id 34sm7289wra.2005.01.17.20.44.10;
Mon, 17 Jan 2005 20:44:10 -0800 (PST)
Message-ID: <41EC940C.6040701@yahoo.com>
Date: Mon, 17 Jan 2005 23:43:56 -0500
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
To: ID@yahoo.com
Subject: =?UTF-8?B?7ZWc6riA?=
From: NAME <ID@gmail.com>

7ZWc6riAIO2FjOyKpO2KuA0KDQo=


바로 위의 라인은 본문에서 "한글 테스트" 라는 글자가 깨져 있는 모습입니다.

[baboojoon]

그리고 이것이 딱 한번 제대로 한글이 표시된 메일의 헤더 입니다.


From - Mon Jan 17 12:04:02 2005
X-Account-Key: account4
X-UIDL: 480f14002005675b575a05682af222d8
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Apparently-To:ID@yahoo.com via 206.190.39.124; Mon, 17 Jan 2005 09:04:09 -0800
Authentication-Results: mta240.mail.scd.yahoo.com
from=gmail.com; domainkeys=fail (bad sig)
X-Originating-IP: [64.233.184.202]
Return-Path: <ID@gmail.com>
Received: from 64.233.184.202 (EHLO wproxy.gmail.com) (64.233.184.202)
by mta240.mail.scd.yahoo.com with SMTP; Mon, 17 Jan 2005 09:04:09 -0800
Received: by wproxy.gmail.com with SMTP id 68so1138280wra
for <ID@yahoo.com>; Mon, 17 Jan 2005 09:04:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-idfrom:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding;
b=QCxKDqAy4x93fus7Ir2Z/55obfWgWEIx/m+wa5P9JIHL6n26U6RoRqA5Whjqnx/+c5uKrIgXM94KX4nvs3r4G9aW3e8KMsmb1DJ3n9kFptSIyze/GscSnMbFAt6Kc99VAvYRYqzEp8L312DSwOc9DzXNrYc4lmrN3nRX6w55Y9Q=
Received: by 10.54.39.41 with SMTP id m41mr215438wrm;
Mon, 17 Jan 2005 09:04:04 -0800 (PST)
Return-Path: <ID@gmail.com>
Received: from ?192.168.11.3? ([68.100.11.196])
by smtp.gmail.com with ESMTP id 43sm1741wri.2005.01.17.09.04.03;
Mon, 17 Jan 2005 09:04:04 -0800 (PST)
Message-ID: <41EBEFF9.10400@gmail.com>
Date: Mon, 17 Jan 2005 12:03:53 -0500
From: NAME <ID@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ID@yahoo.com
Subject: =?UTF-8?B?7ZWc6riAIO2FjOyKpO2KuCDslbztm4Qg7ZWc6riA7YWM7Iqk7Yq4IEs=?=
=?UTF-8?B?b3JlYW4=?=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

한글 야후 테스트 UNICODE



이 메세지에선 보시다시피 한글과 영문이 잘 표시되어져 나오는군요. 하지만 딱 한번밖에 이렇게 제대로 깨지지않고 메일이 보내졌습니다. 이제는 더 이상 한글이 표시되지 않는군요. 이상한 일입니다.

[빛알갱이]

여기 문제의 한글이 깨지는 메일 헤더 내용입니다.


Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
To: ID@yahoo.com
Subject: =?UTF-8?B?7ZWc6riA?=
From: NAME <ID@gmail.com>

7ZWc6riAIO2FjOyKpO2KuA0KDQo=

위 메일의 문제는 본문이 base64이므로 'Content-Transfer-Encoding'이 base64라는 것이 메일 헤더에 명시되어야 하는데, 어떤 이유에서인지 그 줄이 빠져 버렸습니다. 그러니, 그냥 8bit/7bit로 인식되어서 base64 decoding이 일어나지 않고 그대로 보여준 것입니다. 왜 그 줄이 빠졌는지는 알 수가 없군요. 저는 지금까지 그런 일을 겪은 적이 한 번도 없습니다.

참, TB의 경우 Mozilla suite에 있는 UI 가운데 빠진 것이 많아서 QP/Base64 관련 설정도 빠진 줄 알고 about:config를 통해 고치라고 했습니다. 그런데, UI가 있네요. 그렇다면 '8bit 글자가 들었을 ㅤㄸㅒㅤ Quoted-printable로 보내기' 옵션을 끄고 다시 시도해 보십시오. 그렇다면 항상 C-T-E가 8bit로 나가야 정상입니다. 물론, 그렇게 해도 배달 과정에 중간의 MTA 중 어느 하나가 이것을 base64로 바꿔 버릴 수도 있습니다. 바꾸고 나서 'Content-Transfer-Encoding: base64'를 붙여 주어야 하는데, 만일 붙이지 않는다면, 그것은 그 MTA(Mail Transport Agent)의 버그이므로, 그 버그를 고쳐 달라고 하는 수 밖에 없습니다.

모질라 측에서 8bit로 내보냈는지 여부는 보낸 편지함의 소스 보기를 통해서 확인하실 수 있습니다.

[baboojoon]

위 메일의 문제는 본문이 base64이므로 'Content-Transfer-Encoding'이 base64라는 것이 메일 헤더에 명시되어야 하는데, 어떤 이유에서인지 그 줄이 빠져 버렸습니다. 그러니, 그냥 8bit/7bit로 인식되어서 base64 decoding이 일어나지 않고 그대로 보여준 것입니다. 왜 그 줄이 빠졌는지는 알 수가 없군요. 저는 지금까지 그런 일을 겪은 적이 한 번도 없습니다.

참, TB의 경우 Mozilla suite에 있는 UI 가운데 빠진 것이 많아서 QP/Base64 관련 설정도 빠진 줄 알고 about:config를 통해 고치라고 했습니다. 그런데, UI가 있네요. 그렇다면 '8bit 글자가 들었을 ㅤㄸㅒㅤ Quoted-printable로 보내기' 옵션을 끄고 다시 시도해 보십시오. 그렇다면 항상 C-T-E가 8bit로 나가야 정상입니다. 물론, 그렇게 해도 배달 과정에 중간의 MTA 중 어느 하나가 이것을 base64로 바꿔 버릴 수도 있습니다. 바꾸고 나서 'Content-Transfer-Encoding: base64'를 붙여 주어야 하는데, 만일 붙이지 않는다면, 그것은 그 MTA(Mail Transport Agent)의 버그이므로, 그 버그를 고쳐 달라고 하는 수 밖에 없습니다.

모질라 측에서 8bit로 내보냈는지 여부는 보낸 편지함의 소스 보기를 통해서 확인하실 수 있습니다.

답변 감사합니다.

우선 제 선더버드는 항상 "8bit 글자가 들었을 때 Quoted-printable로 보내기" 옵션은 항상 꺼 져있는 상태였습니다. "보낸 편지함" 에서 제 컴퓨터에서 나간 메일 소스들을 확인해보니 "C-T-E"가 8bit으로 되어 있더군요. 허나, 도착한 메일들은 모두 "base64"로 되어 있습니다. 제가 위에도 밝혔듯이 제가 겪은 바로는 메일이 "8bit"로 보냄/받음이 되야 제대로 표시되는데, 받을때 "base64"로 들어온다면, 아마도 중간에 어느 메일 트랜스퍼 에이전트가 바꾸는 모양이군요. 그렇다면 다른 방법이 없겠습니까?

[빛알갱이]

우선 제 선더버드는 항상 "8bit 글자가 들었을 때 Quoted-printable로 보내기" 옵션은 항상 꺼 져있는 상태였습니다. "보낸 편지함" 에서 제 컴퓨터에서 나간 메일 소스들을 확인해보니 "C-T-E"가 8bit으로 되어 있더군요. 허나, 도착한 메일들은 모두 "base64"로 되어 있습니다. 제가 위에도 밝혔듯이 제가 겪은 바로는 메일이 "8bit"로 보냄/받음이 되야 제대로 표시되는데,

base64라도 제대로 표시되어야 합니다. (만일, 제대로 표시하지 못 한다면 대단히 중대한 버그입니다.) 다만, 위에서 보기로 올려 주신 경우와 같이 실제로 base64임에도 불구하고 메일 헤더에 'Content-Transfer-Encoding: base64'라는 줄이 빠져 있는 경우에는 잘 안 보이는 것이 당연합니다. 따라서, 그 중간의 버그 있는 MTA를 잡아 내는 것이 최상의 방법입니다.

똑같은 방식으로 보낸 메일을 모질라로 확인하기 전에 다른 메일 프로그램으로 확인할 경우에는 어떤가요? 그 경우에도 메일 헤더에 'C-T-E: base64'라는 줄이 빠져 있습니까? 그럴 가능성은 매우 낮지만, 혹시나 모질라가 메일을 집어 올 때 어떤 경우에 (저는 한 번도 경험한 적이 없지만), 알 수 없는 이유로 'C-T-E' 줄을 빠뜨리는지 여부를 확인하기 위해서입니다.

받을때 "base64"로 들어온다면, 아마도 중간에 어느 메일 트랜스퍼 에이전트가 바꾸는 모양이군요. 그렇다면 다른 방법이 없겠습니까?

바꾸는 것은 상관 없는데, 'C-T-E'를 안 붙이는 것이 문제입니다. 도대체, 어떤 녀석이 그런 희한한 짓을 하는지 모르겠군요.....
만일, 받는 메일 서버가 유닉스 계열 OS(리눅스, 맥 포함)를 쓰고, 그 유닉스에 쉘 계정이 있다면 비교적 간단하게 문제를 해결할 방법이 있습니다. 그렇지 않은 경우에도 방법이 전혀 없는 것은 아니겠지만, 꽤나 복잡할 것 같습니다.

[마잇]

잘 보이는 메일들

Code: Select all

Content-Type: text/plain; charset=UTF-8; format=flowed

깨져 보이는 메일들

Code: Select all

Content-Type: text/plain; charset=UTF-8

format=flowed 저 부분이 공통적이 차이점 같아 보이는데요. 의미는 잘 모르겠지만...
제가 테스트 해본 경우 중에 "8비트 문자로 메시지를 보내려면 'quoted-printable' MIME형식으로 보내야 하며, 아래 옵션을 선택하지 않음" 옵션을 키고 보낸 경우가 아래와 같은데

Code: Select all

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

64uI64uI7JWEdHRzZHNnICAK <-- 본문 부분

이 경우에도 소스보기 하면 위처럼 한글이 깨져 보이지만 일반 보기 창에서는 한글이 제대로 보였었습니다. C-T-E와는 상관없이 format=flowed 부분이 뭔가 차이를 만들지 않나 생각됩니다.

# 수정 : 후.. 어림짐작으로 이상한 리플만 자꾸 다네요 -_- format=flowed 는 인코딩과는 전혀 무관한것 같습니다.
관련링크입니다. http://www.joeclark.org/ffaq.html

[빛알갱이]

Code: Select all

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

64uI64uI7JWEdHRzZHNnICAK <-- 본문 부분

이 경우에도 소스보기 하면 위처럼 한글이 깨져 보이지만 일반 보기 창에서는 한글이 제대로 보였었습니다.

소스 보기에서 그렇게 보이는 것이야 너무나 당연한 얘기고요. 메일 소스에 있는 그대로 보여 주기가 바로 소스 보기의 존재 이유입니다.

# 수정 : 후.. 어림짐작으로 이상한 리플만 자꾸 다네요 -_- format=flowed 는 인코딩과는 전혀 무관한것 같습니다.
관련링크입니다. http://www.joeclark.org/ffaq.html

예, flowed는 줄바꿈을 어떻게 처리할 것이냐에 대한 것을 변경할 뿐, C-T-E와는 아무런 상관이 없습니다. RFC 3676에서 자세히 다루고 있습니다. (물론, 모질라에 버그가 있어서 둘이 이상하게 얽혀 있다면 얘기가 달라집니다.)

[12]

여기 문제의 한글이 깨지는 메일 헤더 내용입니다.


Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
To: ID@yahoo.com
Subject: =?UTF-8?B?7ZWc6riA?=
From: NAME <ID>

7ZWc6riAIO2FjOyKpO2KuA0KDQo=

위 메일의 문제는 본문이 base64이므로 'Content-Transfer-Encoding'이 base64라는 것이 메일 헤더에 명시되어야 하는데, 어떤 이유에서인지 그 줄이 빠져 버렸습니다. 그러니, 그냥 8bit/7bit로 인식되어서 base64 decoding이 일어나지 않고 그대로 보여준 것입니다. 왜 그 줄이 빠졌는지는 알 수가 없군요. 저는 지금까지 그런 일을 겪은 적이 한 번도 없습니다.

참, TB의 경우 Mozilla suite에 있는 UI 가운데 빠진 것이 많아서 QP/Base64 관련 설정도 빠진 줄 알고 about:config를 통해 고치라고 했습니다. 그런데, UI가 있네요. 그렇다면 '8bit 글자가 들었을 ㅤㄸㅒㅤ Quoted-printable로 보내기' 옵션을 끄고 다시 시도해 보십시오. 그렇다면 항상 C-T-E가 8bit로 나가야 정상입니다. 물론, 그렇게 해도 배달 과정에 중간의 MTA 중 어느 하나가 이것을 base64로 바꿔 버릴 수도 있습니다. 바꾸고 나서 'Content-Transfer-Encoding: base64'를 붙여 주어야 하는데, 만일 붙이지 않는다면, 그것은 그 MTA(Mail Transport Agent)의 버그이므로, 그 버그를 고쳐 달라고 하는 수 밖에 없습니다.

모질라 측에서 8bit로 내보냈는지 여부는 보낸 편지함의 소스 보기를 통해서 확인하실 수 있습니다.