korea.kr 도메인에 메일을 보내면 첨부물이 변형되는 문제
글쓴이: 아주가끔은 / 작성시간: 금, 2009/03/20 - 4:18오후
공공기관 직원에게 메일을 보내려면 korea.kr 에 보내야 하죠.
참고 : http://kldp.org/node/98396
korea.kr 도메인에 에볼루션을 이용(smtp 는 네이버)하여 메일을 보냈는데 받는쪽에서는 첨부물이 ~~~.tmp 로 변형된다고 합니다.
뭐부터 짚어 보면 될까요? 에볼루션의 문제? 네이버의 문제? korea.kr 의 문제? 개발자분들 중 korea.kr 에 아는 분 있으면 얘기좀.. 굽신굽신..
Forums:
네이버 SMTP에서
네이버 SMTP에서 korea.kr로 보내는 건가요? 방금 네이버메일에서 PDF문서를 보내봤는데 원래 파일명 그대로 발송이 되는 것을 확인하였습니다.
포탈의 웹페이지를
포탈의 웹페이지를 통한 방법인가요?
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, RomIO, ESP 1010, Triton pro, K2600x, JV-80, Yamaha O3D, Tascam DA-30MKII, Roland SC-55... etc
http://blog.obbli.net
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, JV-80, Yamaha O3D, DA-30MKII, US-122MKII, Roland SC-55
http://blog.obbli.net
맞습니다. mail.naver.com
맞습니다.
mail.naver.com에서 메일쓰기를 이용해서 발송한 것입니다.
에볼루션에 문제가
에볼루션에 문제가 있는 것 같기도 합니다. 제목을 test-테스트.xls 라고 해서 에볼루션에서 제 네이버 메일 주소로 보내보니 파일명이 ATT00006.xls 로 변경되어 있습니다. 파일 내용은 그대로 입니다. 메일 클라이언트 기능에 알 수 없는 파일명(한글)은 변경해서 보내는 방법이라도 있는걸 까요?
가정 :
에볼루션 에서 1차적으로 test-테스트.xls 를 보내는데 "테스트"란 이름을 인식 할 수 없어서 파일이름을 ATT00006.xls 로 변경해서 보냈다. 포탈의 smtp 는 그대로 korea.kr 에 전달했으나 korea.kr 의 강력한 필터링으로 인해 파일명이 의심되는 메일의 첨부물을 변형 시켰다.
하지만 메일 필터링을 한다면 메일을 차단하는게 우선이지 변형해서 보여줄 필요까진 없을텐데... 라는게 남는군요.
미궁으로 빠지는건가?
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, RomIO, ESP 1010, Triton pro, K2600x, JV-80, Yamaha O3D, Tascam DA-30MKII, Roland SC-55... etc
http://blog.obbli.net
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, JV-80, Yamaha O3D, DA-30MKII, US-122MKII, Roland SC-55
http://blog.obbli.net
메일을 차단하면
메일을 차단하면 안되죠... 적어도 누가 메일을 보낸지는 알아야, 전화를 해서 다른 방법으로라도 첨부파일을 받죠
요즘 첨부파일은 조금만 의심되면, 서버단에서 winmail.dat 이런식으로도 바꾸고, 그럽니다.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
에볼루션에서
에볼루션에서 한글이름으로 된 첨부물을 보내면 네이버에서 NamelessFile_ReNameByNaver. 로 변형되지만, 이것을 에볼루션으로 다시 받아보면 정상적인 한글이름으로 받아내는군요.
한글이름으로 받는다는건 네이버에서 UTF8 파일이름을 받지 못한다던가 하는 문제가 있어 보입니다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, RomIO, ESP 1010, Triton pro, K2600x, JV-80, Yamaha O3D, Tascam DA-30MKII, Roland SC-55... etc
http://blog.obbli.net
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, JV-80, Yamaha O3D, DA-30MKII, US-122MKII, Roland SC-55
http://blog.obbli.net
제대로 하고 있는
제대로 하고 있는 쪽은 에볼루션이지만, 사실상 표준에 맞지 않는 방법이 더 널리 쓰입니다.
첨부 파일이름의 인코딩은 원래 표준대로라면 RFC2231을 따라야 하는데 이 표준을 똑바로 지원하는 경우가 거의 없고, RFC2047로 잘못 인코딩을 하는 경우가 더 많습니다. 표준에 맞게 인코딩하는 경우는 에볼루션 외에는 보지 못했고, 이렇게 인코딩한 파일 이름을 제대로 디코딩하는 경우도 gmail 빼고는 못 본 것 같습니다. 네이버 다음도 모두 마찬가지로 문제가 있고요. (이 외에 수많은 문제가 있어서 리포트했지만 고객센터는 절대 버그를 전달해 주지 않더군요..)
하여간 결론은, 문제의 공공 웹메일이 RFC2231 디코딩을 못하는 게 원인일 겁니다.
에볼루션 2.26이라면 gconf-editor로 살펴보면 일부러 잘못 인코딩하게 만드는 설정이 있습니다.
오~ 이런 문제가
오~ 이런 문제가 있었네요. 대략 가정한게 맞아 떨어지네요. 조직 전체의 구조를 바꾸는건 쉬운일이 아닐테니.. 쉽게 표준으로 가기 힘들테죠. 이런곳에서 오픈소스의 문제점과 만나다니.. 에볼루션 사용자로서 굉장히 유감입니다.
그래서 오픈소스의 선택은 어떻게 하는게 바람직할까요?
네이버만 바꾼다고 일사천리로 진행 되는건 아닐것 같은데...
그냥 그대로 고집?
같이 융화?
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, RomIO, ESP 1010, Triton pro, K2600x, JV-80, Yamaha O3D, Tascam DA-30MKII, Roland SC-55... etc
http://blog.obbli.net
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, JV-80, Yamaha O3D, DA-30MKII, US-122MKII, Roland SC-55
http://blog.obbli.net
말씀드렸듯이
말씀드렸듯이 2.26에는 일부러 잘못 인코딩하는 설정이 있습니다.
옳고 그름을 따지자면 오픈소스가 문제는 아니죠. 인코딩할 때 표준을 따랐다는 사실이 문제점일까요? 아웃룩이나 웹메일 등 다른 클라이언트들을 바꾸는 게 우선입니다. RFC2231을 나홀로 사용하기는 현실적으로 힘들지만 최소한 디코딩은 할 수 있어야죠.