메일발송과 문자셋 문제

예전 PHPSCHOOL에 적은 글을 이삼구글에 질문을 하시는 분이 계셔서 참고로 올립니다. 메일과 인코딩에 대한 정리입니다. 개발자 커뮤니티에 올린 글이니만큼 개발자가 아닌 분들에게는 다소 어지러워 보일 수도 있습니다.

아래의 내용은 메일 발송시 참고해야 할 사항을 정리한 것입니다.

1. 인코딩
; 메일의 본문은 인코딩을 할 필요는 없습니다. 어짜피 클라이언트쪽에서 지원하지 않으면 인코딩을 했건 그렇지 않건간에 볼 수가 없으니까요. 문자셋만 제대로 써 주면 됩니다.
단, UTF-8의 경우는 hotmail에서 볼 수 없고, 다음메일에서 클릭 한번 더 해줘야 하는 일이 발생합니다. 다른건 몰라도 메일은 유니코드쪽 보다는 로컬셋을 이용하는 것이 좋을듯 합니다.
본문 외에 보내는 사람, 받는 사람 이름과 제목은 반드시 인코딩을 해 줘야 합니다. 클라이언트에서 디폴트문자셋으로 지정되어있지 않으면 깨져서 보여버리죠.(최근 파란닷컴 메일이 보내는 이 이름이 깨져서 옵니다.)
인코딩하는 방법은 다들 아시다시피

‘=?ks_c_5601-1987?B?’.base64_encode($subject).’?=’

요거 되겠습니다. 가끔 ks 대신 euc-kr로 하는 경우도 있습니다. 네이버가 그런식으로 하는것 같더군요. 구글멜은 utf-8 되겠습니다. 🙂

2. text인가 html인가?
; 개인적으로 보내는 것은 몰라도 메일링리스트나 멜로봇이 보내는 것이면 둘 다 써주는 것이 좋습니다. 클라이언트 쪽에서는 자동으로 세팅을 보고 text쪽으로 보여줄지 html쪽으로 보여줄지를 결정합니다.
이 것이 중요한 이유는 보통 보는 쪽은 html로 하는 경우가 많지만, 보내는 쪽에서 text로 세팅이 되는 경우도 많은데(저 같은 경우) 리플라이 버튼을 누를 경우 text로 세팅이 되면 하단에 붙는 받은 메일 본문이 text에 있는 메세지가 붙어버립니다.
구글멜과 인터넷제국의 멜같은 경우가 둘 같이 보냅니다.

3. 헤더와 스타일 그리고 이미지
; HTML의 head태그나 body태그를 쓰는 경우가 있지만 전혀 필요없는 짓입니다. body 태그가 있다 치고 메세지를 작성하면 됩니다.
스타일의 경우 외부 파일을 링크시켜버리면 웹메일에서 적용되지 않는 경우가 많습니다. 야후닷컴 멜은 외부 스타일을 인정하지 않습니다. 따라서, 커스텀태그를 적용하는 편이 가장 편합니다.(템플릿언더바 사용자라면 포스트필터를 적용하면 편합니다.)
이미지의 경우 SP2부터 기본적으로 보여지지 않기 때문에 이미지를 링크시킬 경우엔 크기와 타이틀이나 alt속성을 넣어주면 좋고, 최상단의 경우 배너형식 보다는 이미지 따로 텍스트 따로 넣는 편이 좋습니다. 구글멜도 기본적으로 그림을 보여주지 않고, 다음의 경우는 메일마다 틀립니다.
스크립트의 경우는 넣어봤자 대부분 실행되지 않습니다. 야후의 음악멜의 경우 실행되는 웹메일을 거의 본적이 없네요. 플래쉬도 마찬가지로 실행되지 않습니다.

4. 확인 스크립트
; 보통 투명이미지로 확인했는지를 체크하는데, 광고의 효과면에서 볼때 그렇게 측정하는 것 보다는 모든 링크를 리다이렉트 시켜서 처리하는 것이 훨씬 정확합니다. 메일을 확인한 것이 중요한게 아니라 메일을 확인하고 클릭을 유도하는 것이 훨씬 중요합니다. 또한, 투명이미지의 경우 SP2나 구글멜, 다음 처럼 보여주지 않는 경우도 많기 때문에 정확도 면에서 신뢰할 수 없습니다.

5. 기타
; 다음의 우표정책을 시도 하시는 분들은 알아두시면 좋습니다. 정보성 메일로 신경써서 발송할 경우 대부분 정보성메일로 판명납니다. 하지만 응답자가 적을 경우 정보성의 유무에 상관없이 한달간 발송한 메일 전체에 과금됩니다. 우표정책에 대한 글을 다음에서 모두 읽어봤지만, 그 부분에 대해서 나온 부분은 1군데 밖에 없었고(회원가입 후의 화면) 그 메세지 마져 왠만하면 과금되지 않는다는 형식으로 쓰여져 있습니다.

그 외에 보내는 메일을 정확하게 작성한다던지, IP소유의 메일서버의 호스트명을 제대로 넣는다던지 하는 것은 다 아시리라 생각되네요.

덧글. 5번의 다음 우표정책은 지금은 시행되지 않습니다.

2 thoughts on “메일발송과 문자셋 문제

  1. EUC-KR이 바른 이름입니다. ks_c_5601-1987은 실제 한국 표준과 관계도 없는 마이크로소프트 고유의 인코딩 방법(EUC-KR을 포함하므로, 상위 호환성이 있습니다.)인 Windows-949를 가리킬 때 MS가 부르는 신기한 이름입니다.

    참고로 EUC-KR은 KS X 1001 (KS C 5601은 한국 공업 표준 체계 변경 전에 정보 통신 규격이 섹션 C에 있던 시절 이름입니다)과 US-ASCII/KS X 1003을 같이 표현하는 인코딩 방법 중 하나입니다.

    또, 메일 본문도 경우에 따라서는 Content-Type-Encoding으로 8bit 대신 base64나 QP를 써야 합니다. 요새는 드물지만, 가끔씩 8BITMIME을 지원하지 않는 메일 서버가 있으니까요.

    RFC 2821, 2822, 2045, 2046, 2047, 2048, 2049, 2231을 읽어 보세요.

    로컬에서 EUC-KR을 쓰는 게 좋다고 하셨는데, 현실적으로 그럴 수 밖에 없는 경우가 있습니다. 하지만, 하루속히 UTF-8로 옮겨가야 할 당위도 있습니다. 한국에 산다고, 한국 웹 메일 계정 사용자라고 해서 항상 한국어 메일만 주고 받는다는 법은 어디에도 없으니까요.

    네이버는 이제 유니코드를 잘 지원하더군요. 한메일은 그럭저럭 지원하고요. 다른 웹 메일 서비스도 빨리 네이버 수준 (지메일 수준은 아니라도)으로 지원하기 바랍니다.

  2. 메일과는 크게 관련이 없지만 Java를 사용할 때 필요한 문자셋과 인코딩을 제가 조금 정리 하였습니다.
    참고하세요.

    http://www.jopenbusiness.com/mediawiki/index.php/%EB%AC%B8%EC%9E%90%EC%85%8B%EA%B3%BC_%EC%9D%B8%EC%BD%94%EB%94%A9

    JavaMail을 사용하여 인코딩/디코딩을 하는 부분은 제가 자세히 알고 있는데 홈페이지를 구축하고 있는 중이라 아직 정리를 하여 올리지는 못 하였습니다. 우선 궁금한 사항이 Q&A 있으면 게시판에 글을 올려 주세요. 그러면 제가 아는 한도내에서 답변 드리겠습니다.

    오픈소스 비즈니스 컨설팅 http://www.jopenbusiness.com/

Leave a Reply

Your email address will not be published. Required fields are marked *