주제: 메일링 작업에서의 난관 봉착

포럼의 글들은 매일 잘보고 있습니다~~ -_-
저도 요즘 파견나와서 유지보수 작업을 하고있는데 이곳방침자체가 'IE 전용' 이고, 여러가지의 제약으로 인해 저도 표준작업을 할 기회가 줄어들어서 점점 감각을 잃어가고 있습니다 (입사 3개월째.. 한참 표준 배우면서 신규프로젝트에 적용하면서 내공을 쌓고 있었는데...)

일단 푸념은 이정도로 하고, 몇일전 메일링 작업을 했는데요, 큰 문제가 있더라고요.
메일링 작업을 CSS를 사용해서 발송을 해봤는데 네이버는 인라인 CSS를 제외하고는 외부링크나 <style> 태그 안의 CSS는 자동으로 제거를 하고
파란은 클래스 네임이 겹쳐서 CSS가 깨지기도 하고(이건 네이밍을 바꿔서 해결했습니다) td에 align을 자동으로 center로 주더군요(이것도 결국 전체 DIV에
id를 주어 해결은 했지만요) 많은 문제들이 생기더라고요
중요한건 이런 변수들을 모든 메일 서비스를 상대로 파악하기가 힘들다는것..
하지만 여기서는 모든 메일에서 보여질수 있도록 하라는것 (물론, 당연한 얘기지요)

그러나 네이버처럼 아예 인라인 CSS밖에 안되는 상황이라 CSS를 사용하기도 힘들고(주문확인 같은 메일들이라 데이터가 들어가는 테이블이 몇개 있습니다)
그에따라 시맨틱한 마크업을 사용할수가 없어 결국 그동안 만든 메일폼들을 테이블화 하고 CSS를 최대한 사용안하는 쪽으로 해야하는 상황에 처해있습니다

이곳에도 에이전시에서 일하시는분이 많으신데 혹시 이런 난관에 봉착한적이 없으신지요~
이럴땐 어찌해야하나요~~

아, 그리고 쿠키님 블로그에서 현석님이 메일링이야말로 아이프레임으로 사용하는게 좋다고 하셨는데 저도 그 글을 읽고 동감했습니다만, 이번과 같은 메일은
고객의 주문정보 같은 프로그래밍이 들어가기 때문에 아이프레임으로는 구현이 안될것 같네요~

p.s 내일 모임 재밌게 노세요~~ 저도 가고 싶었지만 약속이 있어서... 여기계신 많은 분들과 친해지고싶네요~~~
      다음에 기회가 있다면 꼭 참석토록 하겠습니다~

최종 편집 : hoiheart (2007-01-11 10:22 PM)

답변: 메일링 작업에서의 난관 봉착

예전에 제가 테스트 했을 때만 해도 link 속성으로 CSS를 넣더라두 네이버에서도 잘 보였던 것 같은데 바뀌었나보네요.
저 같은 경우는 블로그에 썼듯이 korea.com 에서 import를 인식하지 못해서 link로 바꾸었던 문제(?)밖에 없었습니다.

예전 회사 사이트 개편 후에 이메일도 모두 현재 메일 시스템 때문에 dtd는 빼고 div기반으로만 작업했었는데, 부모 div의 id만 잘 지정해주면 class가 겹치거나 하는 문제는 없었던 것 같아요.

Just kukie.

답변: 메일링 작업에서의 난관 봉착

외부에서 어떤 파일(CSS, Javascript)을 참조하지 못하도록 하는 것은 보안상의 문제인 것으로 알고 있습니다.
만약 그것을 허용한다면 자동으로 페이지를 이동시키거나 무한팝업을 띄우는 것도 가능할 테니까요.
저같은 경우 internal 방식의 CSS 를 삽입해서 작업했었고 그것이 현재로서는 유일한 대안으로 알고 있습니다.

답변: 메일링 작업에서의 난관 봉착

아. dece24님이 댓글 달고 나니 자바스크립트 이슈도 하나 생각이 나네요.
파일 내부에서 자바스크립트를 사용할 수 없어서, 수신거부..였나.. 아무튼 어떤 창을 작은 팝업으로 띄우고 싶어했는데, 어쩔 수 없이 모든 링크는 그냥 일반 링크로 처리했던 것이 생각이 납니다.

메일 서비스 제공 업체 마다 메일이 보여질때의 조건을 다르게 해 놓아서, 메일링 작업을 하는 작업자들은 어려움이 많을 것 같아요.
전 개인적으로.. 사적인 메일을 주고 받는 것 처럼 텍스트로만 이루어진 메일이 좋던데.. 아무래도 마케팅 측면에서 비주얼이나 시선 끌기 등을 생각한다면 이미지나 테이블,  기타 다른 오브젝트가 들어가지 않을 순 없겠죠.

역시나 여기서 또 제가 생각할 수 있는 문제는 한글 글꼴 문제 입니다.
한글 글꼴이 조금만 더 예쁘고 사용하기에 문제가 없었다면, 정보성 메일까지 이미지로 도배되는 일은 일어나기 힘들었을 텐데 말이예용..

아이쿠, 자꾸 상관없는 얘기로 빠지네요 ^^;

Just kukie.

답변: 메일링 작업에서의 난관 봉착

dece24 wrote:

외부에서 어떤 파일(CSS, Javascript)을 참조하지 못하도록 하는 것은 보안상의 문제인 것으로 알고 있습니다.
만약 그것을 허용한다면 자동으로 페이지를 이동시키거나 무한팝업을 띄우는 것도 가능할 테니까요.
저같은 경우 internal 방식의 CSS 를 삽입해서 작업했었고 그것이 현재로서는 유일한 대안으로 알고 있습니다.

네이버 메일은 inline만 지원이 되는것 같더라고요
인라인으로 할경우 엄청난 코드량과 코드를 친사람도 알아볼수 없을정도로 변해버린다는;


kukie wrote:

아. dece24님이 댓글 달고 나니 자바스크립트 이슈도 하나 생각이 나네요.

덕분에 또하나의 문제를 알게되었네요~~ 감사합니다

답변: 메일링 작업에서의 난관 봉착

http://www.campaignmonitor.com/blog/arc … 1.html#web

메일서비스(gmail,hotmail,yahoo) 별로 css 속성을 지원하는 항목을 정리해 놓은 사이트 입니다. 참고가 될런지 모르겠네요..

답변: 메일링 작업에서의 난관 봉착

정종선 wrote:

http://www.campaignmonitor.com/blog/arc … 1.html#web

메일서비스(gmail,hotmail,yahoo) 별로 css 속성을 지원하는 항목을 정리해 놓은 사이트 입니다. 참고가 될런지 모르겠네요..

아 감사합니다~~
국내메일뿐의 문제는 아니었군요

상황을 보니 메일에서의 CSS사용은 여러가지로 제약이 많다는게 결론이군요

답변: 메일링 작업에서의 난관 봉착

제가 유지보수하는 사이트같은 경우 메일페이지 스타일시트(인라인포함)은 물론 이미지맵도 못 쓰게 하던데요...
이해가 좀 안되네요..

nateon: kyoo119@nate.com, gtalk: kyoo119@gmail.com

답변: 메일링 작업에서의 난관 봉착

hoiheart wrote:

아, 그리고 쿠키님 블로그에서 현석님이 메일링이야말로 아이프레임으로 사용하는게 좋다고 하셨는데 저도 그 글을 읽고 동감했습니다만, 이번과 같은 메일은
고객의 주문정보 같은 프로그래밍이 들어가기 때문에 아이프레임으로는 구현이 안될것 같네요~

메일은 프로그램이 돌아가고 나온 HTML결과 발송하기 때문에 프로그래밍 문제와는 별개의 것입니다. 당연히 프레임으로 넣어야 합니다.

메일을 보내실때에는 모든 스타일을 style="" 속성을 이용해서 넣어줘야 합니다. 그리고 네이버는 position 속성도 사용할 수 없게 해 놨습니다. 사실 이렇게 접근하는 거면 float도 못쓰게 막아야 하는데 float는 안막았더군요. 기본을 잘 지키지 않아서(독립적인 html 데이터를 html 안에 삽입) 삽질이 계속 되는 거죠.

그리고 당연히 스크립트도 사용할 수 없습니다. 이건 모든 메일에 공통적으로 적용되는 거죠. 이미지도 막는 판에...

written by hyeonseok.com

답변: 메일링 작업에서의 난관 봉착

hyeonseok wrote:

메일은 프로그램이 돌아가고 나온 HTML결과 발송하기 때문에 프로그래밍 문제와는 별개의 것입니다. 당연히 프레임으로 넣어야 합니다.

아.. 메일서비스 자체에서 프레임에 넣어줘야 한다는 말씀이셨군요~~
메일코드 자체를 아이프레임으로 보낸다는 걸로 잘못 이해했네요~~~;

답변: 메일링 작업에서의 난관 봉착

position 속성을 막은 이유는 자사 웹사이트의 주요 UI 를 악의적으로 가려서 사용하지 못하도록 하는것을 방지하기위한 이유 때문이라고 추측됩니다. 예를 들어 이런 코드가 가능하다면...

<div style="position:absolute; z-index:99; background:#FFF; left:500px; top:200px; width:100px; height:30px;"></div>

스팸신고 버튼을 가려서 웹메일의 UI 를 사용할 수 없도록 할 수도 있겠죠.

PS: position 사용을 금지하는 것을 두둔하는 것은 아니지만 메일을 발송하는 입장에서도 CSS 의 의존도를 최대한 줄여서 내용전달하는데 문제가 없도록 하는것이 좋겠다는 생각 입니다. 그거야 뭐 항상 저희 의지대로 되는것은 아니겠지만요. 갑과 을의 관계에 있는한 그것 말고도 부딪힐 일은 수두룩 하지요. 하지만 적어도 이런 문제를 만났을 때 고객을 직접 설득해 보려는 시도는 중요하다고 생각합니다. '씨알이 먹히려나 싶어서 말조차 꺼내지 않는것 보다는 훨씬 낫다' 라는 생각입니다. 누가 이런말을 즐겨 했다죠. "해보기나 했어?" 라구요.

최종 편집 : dece24 (2007-01-12 03:01 PM)

답변: 메일링 작업에서의 난관 봉착

저도 몇달전에 웹진 작업을 했었는데 난감한 상황이 많이 발생되더군요.. 그 때 기본적으로 필요한 정보를 좀 적어놨었는데..

-----------------------------------------------------------------------------------------------------------------------------------
웹진 작업좀 하다가 한번 정리해둬야 할것 같아 일단 되는대로 정리 해봅니다.
웹진이나 뉴스레터, 메일링 등은 메일 수신 서버 정책에 따라 표현되는게 각양 다르므로 개발시 이에 대한 숙지가 필요합니다.

1. 기본태그를 사용하는것이 좋습니다.
2. 자바스크립트, 외부css, div 등은 사용하지 않는것이 좋습니다.
3. 경로는 당연히 도메인포함한 절대경로를 사용해야합니다.

다음은 포탈별 대략적인 정책입니다.

포탈       기본태그 이미지표시 인라인스타일 헤드스타일 외부스타일 자바스크립트 플래시 등
다음           o              o                 ox                  x                x                  x                x
네이트        o              o                 ox                 ox               x                  x                o
네이버        o              o                 ox                 ox               x                  x                o
야후           o                                                                        x                   x   
gmail        ox            ox                 x                   x                x                  x                 x

대략 이정도 인것같습니다.
간단하게 정리하니 관련된 컨텐츠 개발자분들께서는 작업시 직접 확인하시면서 진행하실 필요가 있습니다!
-----------------------------------------------------------------------------------------------------------------------------------

위 내용은 그 때 적어놓어던걸 가공하지 않고 그대로 올린것입니다. (귀차니즘으로 인해...^^)

그리고 저같은 경우는 팝업창 같은걸 띠울일이 있으면 아래 방법을 사용합니다.

거의 대부분 포털 사이트들이 기본적으로 window.open 같은 자바스크립트까지 모두 막아 버리기 때문에 전  url을 이용한 get 방식을 사용합니다.

관련 파일은 서버에 올려놓고....

http://xxxx/ScriptPage.html?id=popup 뭐 이런식으로 링크를 걸어두고..

ScriptPage.html에서는 id값에 따라 팝업이든 뭐든 처리를 하도록 유도합니다. 단 메일내의 문서 로드시에 스크립트를 실행시키지 못해서 로드시 팝업창이라든지 뭐 그런건 구현 불가능하다는거...(너무 당연한가..^^)

아~ 마지막으로 한가지 더...

제가 잘못했는지는 모르겠지만  css를 이용한 div로 레이아웃을 잡았을때와 테이블로 잡았을때 후자쪽이 훨씬 오류가 적게 나더군요. 작업하기도 훨씬 수월하고.....제 경우는 이랬는데...

최종 편집 : 착한고래 (2007-01-15 02:17 PM)

답변: 메일링 작업에서의 난관 봉착

참고 : http://css-discuss.incutio.com/?page=StyleInEmail

간략하게 적어보는 주의점
- 포지셔닝을 하지 말 것.
- link, import로 스타일쉬트를 지정해도 소용없음.
- 웹메일 솔루션의 경우 어떤 것들은 header를 잘라버리는 경우가 있기 때문에 대부분의 기법이 소용없음.
- 심지어 inline CSS들도 잘라버리고 다시 재구성하는 경우도 있기 때문에 주의.
- font 엘리먼트를 쓰는 편이 유용.
- 특정 메일사용자를 대상으로 하지 않고, 범용적으로 발송하는 메일이라면, HTML이라기보다는 차라리 RTF라고 생각하는 편이 유용.

결론 : 메일은 HTML이 아님.

최종 편집 : nowhere0 (2007-01-15 02:39 PM)

scama, nowhere0, 안봄, joat, eouia, melona ... What the fucking guys!

답변: 메일링 작업에서의 난관 봉착

nowhere0 wrote:

결론 : 메일은 HTML이 아님.

공감 100%입니다.

답변: 메일링 작업에서의 난관 봉착

Campaign Monitor 는 이메일 HTML 파일과 CSS 파일, 그리고 JPG 파일들을 하나로 묶어서 올려주면 자동으로 CSS를 각 instance 에 일일히 inline 으로 넣어주는 괴력(...)을 발휘합니다. 한번 써보세요. 편한게 한두가지가 아닙니다.