HTML 이메일

HTML email

HTML e-메일은 HTML의 서브셋을 사용하여 일반 텍스트로는 사용할 수 없는 e-메일에 형식과 의미 표시 기능을 제공하는 것이다.[1] 텍스트는 URL을 표시하거나 긴 URL을 여러 조각으로 구분하지 않고 연결할 수 있다. 텍스트는 각 줄을 78자(기존 텍스트 단자에서 필요했던 RFC 5322에 정의됨)로 균일하게 끊는 것이 아니라 보기 창의 너비에 맞게 포장된다. 달리 전달하기 어려운 이미지(일반적으로 ASCII 아트를 사용하는 경우)로 이미지, 테이블, 다이어그램 또는 수학 공식을 인라인으로 포함할 수 있다.

입양

대부분의 그래픽 전자 메일 클라이언트는 HTML 전자 메일을 지원하며, 기본적으로 HTML 전자 메일이 많다. 이러한 클라이언트 중 다수는 HTML 전자 메일을 작성하기 위한 GUI 편집기와 수신된 HTML 전자 메일을 표시하기 위한 렌더링 엔진을 모두 포함한다.

그것의 구상 이후, 많은 사람들은 다양한 이유로 모든 HTML 이메일 (그리고 심지어 MIME 그 자체도)을 소리 높여 반대해왔다.[2] 예를 들어, ASCII 리본 캠페인은 모든 전자 메일이 ASCII 텍스트 형식으로 전송되어야 한다고 주장했다. 이 캠페인은 성공하지 못했고 2013년에 포기되었다.[3][4] 많은 뉴스 그룹 게시물과 우편물 목록에서는 여전히 부적절하다고 여겨지지만, 개인 우편과 업무용 우편물에 대한 채택은 시간이 지남에 따라 증가했을 뿐이다. 처음 나왔을 때 강하게 반대했던 사람들 중 일부는 지금은 대부분 무해하다고 본다.[5]

온라인 마케팅 회사들의 조사에 따르면, HTML 지원 이메일 클라이언트의 채택은 이제 거의 보편화되어 있으며, 3% 미만이 문자 전용 클라이언트를 사용하고 있다고 보고하고 있다.[6] 대다수의 사용자는 일반 텍스트보다 HTML 전자 메일을 받는 것을 선호한다.[7][8]

호환성.

RFC 2822를 준수하는 이메일 소프트웨어는 HTML 서식이 아닌 일반 텍스트만 지원하면 된다. 따라서 HTML 형식의 전자 메일을 보내는 것은 수신자의 전자 메일 클라이언트가 이를 지원하지 않을 경우 문제를 일으킬 수 있다. 최악의 경우, 수신자는 의도된 메시지 대신 HTML 코드를 보게 될 것이다.

HTML을 지원하는 이메일 클라이언트 중 일부는 W3C 규격과 일관되게 렌더링하지 않으며, 많은 HTML 이메일도 컴플라이언스 또는 전송 문제를 일으킬 수 있다.

특히 더. <head> 전체 HTML 문서에 대한 CSS 스타일 규칙을 저장하는 데 사용되는 태그는 잘 지원되지 않으며, 때로는 완전히 벗겨져 인라인 스타일 선언이 사실상의 표준이 되는 경우가 있는데, 인라인 스타일 선언은 인라인 스타일 선언이 비효율적이며 HTML의 스타일 선언과 콘텐츠를 분리하는 능력을 잘 활용하지 못한다.[citation needed] 해결책이 개발되었지만,[9] 이것은 뉴스레터 개발자들에게 좌절감을 주지 않고, 웹 표준 프로젝트에서 영감을 얻은 산성 테스트의 렌더링에 대해 전자 메일 고객을 등급을 매기는 풀뿌리 전자 메일 표준 프로젝트를 시작하고, 개발자들이 그들의 제품을 개선하도록 로비하는 것이다. 예를 들어 구글이 Gmail의 렌더링을 개선하도록 설득하기 위해, 그들은 얼굴을 찡그리는 웹 개발자들의 비디오 몽타주를 출판하여 [10]한 직원의 관심을 받았다.

"전자 메일 표준 프로젝트" 산성 시험 비교(2013년 1월 기준)[1]
클라이언트 결과(기준)
AOL 웹메일 견고한 지원(2011년 7월 13일)
사과 아이폰 견고한 지원(2011년 7월 13일)
애플 아이패드
애플 아이팟 터치
애플 메일 견고한 지원(2007년 11월 28일)
애플 모바일미 견고한 지원 (2008년 8월 15일)
에우도라
에우도라 OSE는 "페넬로피"라고 부호화했다. 		견고한 지원(2007년 11월 28일)
Microsoft 수행자 견고한 지원(2007년 11월 28일)
모질라 썬더버드 견고한 지원(2007년 11월 28일)
윈도 라이브 메일 견고한 지원(2007년 11월 28일)
윈도 메일 견고한 지원(2007년 11월 28일)
야후! 메일 베타 견고한 지원(2011년 7월 8일)
윈도 라이브 핫메일 일부 개선 권고(2011년 7월 8일)
구글 지메일 개선 권고(2011년 7월 13일)
Lotus Notes 8 개선 권고(2007년 11월 28일)
마이크로소프트 아웃룩 2007 개선 권고(2007년 11월 28일)

스타일

일부 발신인은 크고 화려하거나 주의를 산만하게 하는 글꼴에 과도하게 의존하여 메시지를 읽기 어렵게 만들 수 있다.[11] 이러한 서식에 특히 신경을 쓰는 사람들을 위해, 일부 사용자 에이전트는 독자가 서식을 부분적으로 재정의하는 것을 가능하게 한다(예를 들어, Mozilla Thunderbird는 최소 글꼴 크기를 지정할 수 있다). 그러나 이러한 기능은 전세계적으로 이용 가능하지 않다. 또한, 송신자와 독자의 광학적 외관의 차이는 각 섹션의 작성자를 구별하는 데 도움을 줄 수 있어 가독성이 향상된다.

다중 부품 형식

많은 전자 메일 서버가 메시지의 일반 텍스트 버전을 자동으로 생성하여 HTML 버전과 함께 보내도록 구성되어 텍스트 전용 전자 메일 클라이언트에서도 읽을 수 있도록 보장하며, Content-Type: multipart/alternative, RFC 1521에 명시된 바와 같이.[12][13][14] 메시지 자체는 유형임 multipart/alternative, 그리고 첫 번째 유형인 두 부분을 포함한다. text/plain, 텍스트 전용 클라이언트에서 읽으며, 두 번째는 다음 명령으로 읽음 text/htmlHTML 지원 클라이언트에 의해 읽혀지는 . 그러나 일반 텍스트 버전은 중요한 형식 정보를 누락할 수 있다. (예를 들어, 수학 방정식은 위첨자를 잃고 완전히 새로운 의미를 가질 수 있다.)

많은[citation needed] 메일링 리스트는 HTML 전자 메일을 의도적으로 차단하며, HTML 부분을 제거하여 일반 텍스트 부분을 그대로 두거나 전체 메시지를 거부한다.[citation needed]

부품 순서가 상당하다. RFC1341은 다음과 같이 기술하고 있다. 일반적으로 다중/대체 실체를 구성하는 사용자 에이전트는 신체 부위를 선호도, 즉 선호 형식이 마지막인 증가 순서로 배치해야 한다.[15] html 및 일반 텍스트 버전이 포함된 다중 아트 전자 메일의 경우, 즉 일반 텍스트 버전을 먼저 나열하고 그 뒤에 html 버전을 나열하는 것을 의미하며, 그렇지 않으면 클라이언트는 HTML 버전을 사용할 수 있더라도 일반 텍스트 버전을 표시하는 데 기본값을 사용할 수 있다.

메시지 크기

HTML 이메일이 일반 텍스트보다 크다. 특별한 서식을 사용하지 않더라도 최소한의 HTML 문서에 사용된 태그의 오버헤드가 있을 것이며, 서식을 많이 사용하는 경우에는 훨씬 더 높을 수 있다. 동일한 내용의 복제본을 서로 다른 형식으로 가진 다중 부분 메시지는 그 크기를 더욱 증가시킨다. 그러나 IMAP의 FETCH 명령을 사용하여 다중 파트 메시지의 일반 텍스트 섹션을 자체적으로 검색할 수 있다.[16]

일반 텍스트와 혼합 메시지 메일의 다운로드 시간 차이(대부분 사용자가 느린 모뎀을 통해 전자 메일 서버에 액세스하고 있을 때)는 1990년대에 우려되었지만, 현대적인 연결에서 특히 이미지, 음악 파일 또는 기타 통신과 비교할 때 그 차이는 거의 없다.첨부 파일 [17]없음

보안 취약성

HTML은 링크를 임의의 텍스트로 표시할 수 있도록 하여 전체 URL을 표시하는 대신 링크의 일부만 표시하거나 사용자에게 친숙한 대상 이름을 표시할 수 있다. 이는 사용자가 은행 등 권위 있는 출처의 웹사이트를 링크(링크)가 가리킨다고 속여 이를 방문, 사기꾼에게 의도치 않게 개인 정보(통장 번호 등)를 노출하는 피싱 공격에 이용될 수 있다.

전자 메일에 웹 버그(사진과 같은 외부 서버의 내용을 인라인으로 입력)가 포함된 경우, 서버는 제3자에게 전자 메일이 열려 있음을 알릴 수 있다. 이는 잠재적인 프라이버시 위험으로, 전자 메일 주소가 (앞으로 타겟이 될 수 있도록) 실제임을 밝히고, 메시지를 읽은 시기를 밝힌다.

HTML 콘텐츠는 문서 구문 분석, 렌더링 및 표시에 엔진을 사용하는 이메일 프로그램을 필요로 한다. 이로 인해 더 많은 보안 취약성, 서비스 거부 또는 구형 컴퓨터의 성능이 저하될 수 있다.

네트워크 위협이 증가하는 기간 동안 미국 국방부는 수신되는 모든 HTML 전자 메일을 텍스트 전자 메일로 변환한다.[18]

멀티파트 타입은 다른 방법으로 동일한 내용을 보여주기 위한 것이지만, 이것은 때때로 남용된다; 일부 이메일 스팸은 스팸 필터를 속여 메시지가 합법적이라고 믿게 하는 형식을 이용한다. 그들은 메시지의 텍스트 부분에 악의 없는 내용을 포함시키고 (사용자에게 표시되는) HTML 부분에 스팸을 넣음으로써 이것을 한다.

대부분의 전자 메일 스팸은 이러한 이유로 HTML로[citation needed] 보내지기 때문에 스팸 필터는 때때로 HTML 메시지에 더 높은 스팸 점수를 준다.[citation needed]

2018년 EFAIL이 공개되면서 암호화된 HTML 이메일의 실제 내용을 공격자에게 공개할 수 있는 심각한 취약성이 드러났다.

참고 항목

참조

  1. ^ "Text Email vs HTML Email – The Pros and Cons Thunder Mailer – Mass Emailing Software". www.thundermailer.com. Retrieved 30 January 2016.
  2. ^ HTML 전자 메일: 가능할 때마다 끄십시오!
  3. ^ "The Ascii Ribbon Campaign official homepage". Archived from the original on 11 March 2010. Retrieved 30 January 2016.
  4. ^ "Shutdown of the ASCII ribbon campaign - Pale Moon forum". forum.palemoon.org. Archived from the original on 3 February 2016. Retrieved 30 January 2016.
  5. ^ HTML 전자 메일: 여론 조사 (E-Mail의 HTML이 왜 나쁜 아이디어인가에 대한 많은 연관성을 가진 Scot Hacker의 원조자는 1990년대 이후 그의 감정이 어떻게 바뀌었는지에 대해 토론한다.)
  6. ^ "Email Marketing Statistics and Metrics - EmailLabs". 29 March 2007. Archived from the original on 29 March 2007. Retrieved 30 January 2016. HTML has nearly universal adoption among consumers: A Jupiter Research consumer survey found just 3% receive only text email.
  7. ^ Grossman, Edward (9 July 2002). "Real-World Email Client Usage: The Hard Data ClickZ". www.clickz.com. Retrieved 30 January 2016. Do you prefer receiving HTML or text email? HTML: 41.95%, Text: 31.52%, No preference: 26.53%
  8. ^ "The Science of Email Marketing". www.slideshare.net. Retrieved 30 January 2016. In what format do you prefer to receive email messages from companies? HTML: 88%, Plain text: 12%
  9. ^ Dialect <http://dialect.ca/>. "Premailer: make CSS inline for HTML e-mail". Premailer.dialect.ca. Retrieved 24 June 2012.
  10. ^ "The 2008 Gmail Appeal Email Standards Project". Email-standards.org. Archived from the original on 15 May 2012. Retrieved 24 June 2012.
  11. ^ Shobe, Matt (12 October 2004). "A pretty fair argument against HTML Email". Burningdoor.com. Archived from the original on 24 April 2012. Retrieved 24 June 2012.
  12. ^ RFC 1521 7.2.3. 다중/대체 하위 유형
  13. ^ "TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients" (PDF). Retrieved 24 June 2012.
  14. ^ "Sending HTML and Plain Text E-Mail Simultaneously". Wilsonweb.com. 28 April 2000. Retrieved 24 June 2012.
  15. ^ "RFC1341 Section 7.2 The Multipart Content-Type". Retrieved 15 July 2014.
  16. ^ "Do we really want to send web pages in e-mail?". Dsv.su.se. Retrieved 24 June 2012.
  17. ^ HTML 전자 메일 - 여전히 악의적인가?
  18. ^ "DOD bars use of HTML e-mail, Outlook Web Access". fcw.com. Retrieved 23 June 2015.