Page 1 of 1

[수정예정] 메일 - RFC 2231 지원

Posted: 2006 02 06 18:33 26
by 빛알갱이
네이버에 메일 계정이 없지만, 이 문제가 있으리라고 짐작하고 씁니다. gmail, Yahoo mail, hanmail, hotmail 등도 모두 가지고 있는 버그입니다. gmail은 현재 수정 요청을 했고, 고치겠다고 했습니다. MS Outlook, OE도 현재 문제가 있지만, MS의 내부 버그 리스트에 올라와 있고, 고칠 예정이라고 합니다.

Thunderbird, mutt, Pine 등 메일 표준에 충실한 메일 프로그램은 첨부 파일 이름의 길이가 길거나 이름에 ASCII 영역 밖의 글자가 있으면 RFC 2231 표준에 따라 파일 이름을 '변환'(물론, 수신측에서 완벽하게 복구 가능합니다)해서 보냅니다. 하지만, 대부분의 웹 메일 서비스가 RFC 2231을 송신 시에 지원하지 않음은 물론이고 수신 시에도 제대로 처리하지 못 합니다. 송신 시에 지원하는 것은 일단 보류하더라도 수신 메일에서는 이를 제대로 인식하고 처리해 주어야 할 것입니다.

관련 모질라 "버그" (RFC 2231 방식을 송신 시에 사용하지 않도록 해 달라는 요구)는

https://bugzilla.mozilla.org/show_bug.cgi?id=309566

입니다.

Posted: 2006 02 17 14:45 48
by NAVER
mimepp 수정사항이 시일이 걸리는 관계로 현재로선 바로 적용하기 힘든 상황입니다.
버그로서의 인식은 하였으므로 일정을 잡아 처리하도록 하겠습니다.

지적 감사합니다.

Posted: 2006 02 18 07:18 00
by 빛알갱이
NAVER wrote:mimepp 수정사항이 시일이 걸리는 관계로 현재로선 바로 적용하기 힘든 상황입니다.
버그로서의 인식은 하였으므로 일정을 잡아 처리하도록 하겠습니다.
답변 감사합니다. 조속한 시일 안에 수정해 주셨으면 좋겠습니다. 참고로 gmail, 한메일, MS Outlook/Outlook Express도 곧 수정할 예정입니다.

viewtopic.php?p=21202#21202
도 참고하시기 바랍니다. 또, 모질라는 첨부 파일이나 다른 MIME header field의 해석에 4가지 방법을 씁니다.

1. RFC 2231 방식으로 해석
2. 1이 실패하면 RFC 2047 방식으로 해석
3. 2도 실패하면, 본문의 charset으로 해석
4. 3도 실패하면 UTF-8로 해석

(3과 4의 순서는 제가 약간 헛갈리는군요.)