Page semi-protected

이메일

Email
이 스크린샷에는 전자 메일 클라이언트의 "수신함" 페이지가 표시됩니다. 사용자는 새 전자 메일을 보고 이러한 메시지를 읽거나 삭제, 저장 또는 응답하는 등의 작업을 수행할 수 있습니다.
모든 SMTP 이메일[1] 주소의 일부인 앳 기호
Wikipedia의 "로봇"이 이미지 파일을 변경하면 업로더는 변경된 내용에 대한 이메일을 받습니다.

전자 메일(전자 메일 또는 전자 메일)은 전자 장치를 사용하는 사람들 간에 메시지("메일")를 교환하는 방법입니다.따라서 "메일"이 물리적 메일(따라서 e-+메일)만을 의미할 때 이메일은 메일전자(디지털) 버전 또는 그에 상응하는 것으로 생각되었습니다.이메일은 나중에 유비쿼터스(매우 널리 사용되는) 통신 수단이 되었습니다.현재의 사용법에서는 이메일 주소는 대부분의 국가에서 비즈니스, 상업, 정부, 교육, 엔터테인먼트 및 기타 일상 생활 분야의 많은 프로세스에서 기본적이고 필요한 부분으로 취급되고 있습니다.전자 메일은 매체이며, 전자 메일과 함께 보내는 각 메시지를 전자 메일(대량/수 구분)이라고 합니다.

이메일은 컴퓨터 네트워크(주로 인터넷)와 LAN(로컬 영역 네트워크)을 통해 작동합니다.오늘날의 이메일 시스템은 스토어 앤 포워드(store-and-Forward) 모델을 기반으로 합니다.이메일 서버는 메시지를 수락, 전달, 배달 및 저장합니다.사용자와 컴퓨터가 동시에 온라인 상태가 될 필요는 없습니다.메시지를 송수신하거나 다운로드하려면 일반적으로 메일 서버나 웹 메일인터페이스에 접속해야 합니다.

원래 ASCII 텍스트 전용 통신 매체였던 인터넷 이메일은 MIME(Multipurpose Internet Mail Extensions)에 의해 확장되어 다른 문자 세트 및 멀티미디어 컨텐츠 첨부 파일로 텍스트를 전송합니다.UTF-8을 사용하여 국제화된 이메일 주소를 사용하는 국제 이메일은 표준화되었지만 널리 [2]채택되지는 않았습니다.

용어.

전자 메일이라는 용어는 1975년부터 현대적 의미와 함께 사용되어 왔으며,[3][4] 1979년부터 짧은 전자 메일의 변형된 용어가 사용되고 있습니다.

  • e-메일이 일반적인 형식이 되어 스타일 [5][6]가이드에 의해 추천되고 있습니다.이것은 IETF Requests for Comments(RFC; 코멘트 요구) 및 작업 [7]그룹에 필요한 형식입니다.이 철자는 대부분의 [8][9][10][11][12][13][14][15]사전에도 나와 있습니다.
  • 전자 메일은 현대 미국 영어 [16]말뭉치에 반영되어 편집된 미국 영어 및 영국 영어 작문에서는 선호되는 형식이지만 일부 스타일 [6][17]가이드에서는 선호되지 않습니다.
  • 이메일[18]사용되기도 합니다.1979년 6월에 처음 사용된 것은 1970년대 후반에 개발되어 1980년대 [3][4]초에 운영된 미국 우정사업국 이니셔티브E-COM과 관련하여 Electronics 저널에 소개되었습니다.
  • 이메일도 사용됩니다.
  • E-메일(EMAIL)은 1981년 4월부터 CompuServe에 의해 사용되어 이 [19][20]용어가 대중화되었습니다.
  • EMail은 RFC에서 "Author's Address"에 사용되는 전통적인 형식입니다.

이 서비스는 종종 단순히 메일이라고 불리며, 하나의 전자 메일은 메시지라고 불립니다.전자 메일 내의 필드에 대한 표기법: "수신인", "발신인", "CC", "BCC" 등.1975년에 [21]RFC-680에서 시작되었습니다.

인터넷 이메일은 봉투내용으로 [22]구성되며, 내용은 헤더[23]본문으로 구성됩니다.

역사

1960년대 초 시분할이 등장한 이후,[24] 1965년 MIT의 CTSS 프로젝트에 의해 현저하게 구현되면서, 동일한 시스템의 사용자들 간의 컴퓨터 기반 메시징이 가능해졌다.초기 메인프레임과 미니컴퓨터의 개발자들은 대부분 유사하지만 일반적으로 호환되지 않는 메일 애플리케이션을 개발했습니다.1971년에 최초의 ARPANET 네트워크 메일이 송신되어, 유저의 시스템 [25]주소를 나타내는 「@」기호가 붙은 익숙한 주소 구문이 도입되었습니다.일련RFC에서 File Transfer Protocol을 통해 메일 메시지를 보내기 위한 규칙이 개선되었습니다.

독점적인 이메일 시스템이 곧 등장하기 시작했다.IBM, CompuServeXerox는 1970년대에 사내 메일 시스템을 사용했으며, CompuServe는 1978년부터, IBM과 Xerox는 [nb 1][26][27][28]1981년부터 사내 메일 제품을 판매했습니다.DEC의 ALL-IN-1Hewlett-Packard의 HPMAIL(나중에 HP DeskManager)은 1982년에 출시되었습니다.전자의 개발 작업은 1970년대 후반에 시작되어 후자는 세계에서 가장 많이 판매되는 이메일 [29][30]시스템이 되었습니다.

SMTP(Simple Mail Transfer Protocol) 프로토콜은 1983년에 ARPANET에 구현되었습니다.LAN 이메일 시스템은 1980년대 중반에 등장했습니다.1980년대 후반과 1990년대 초반에는 GOSIP(Government Open Systems Interconnection Profile)의 일부인 독점적인 상용 시스템 또는 X.400 이메일 시스템이 우세할 것으로 생각되었습니다.그러나,[31][32] 1995년에 인터넷을 통한 상업 트래픽 전송에 대한 최종 제한이 끝나자, 복합적인 요소들이 현재의 SMTP, POP3, IMAP 이메일 프로토콜의 인터넷 스위트를 [nb 2]표준으로 만들었다.

작동

다음은 발신인 Alice가 [33]수신인의 전자 메일 주소로 지정된 메일 사용자 에이전트(MUA)를 사용하여 메시지를 전송할 때 발생하는 일반적인 일련의 이벤트입니다.

이메일 조작
  1. MUA는 메시지를 전자 메일 형식으로 포맷하고 SMTP(Simple Mail Transfer Protocol)의 프로파일인 제출 프로토콜을 사용하여 메시지 내용을 로컬 메일 제출 에이전트(MSA)로 보냅니다.이 경우 smtp.a.org.
  2. MSA 는, SMTP 프로토콜(메시지 헤더가 아닌)로 제공되는 행선지 주소(이 경우는 bob@b.org)를 결정합니다.이것은 Fully Qualified Domain Address(FQDA; 완전 수식 도메인주소)입니다.@ 기호 앞부분은 주소의 로컬 부분(대부분은 수신자의 사용자 이름), @ 기호 뒤부분은 도메인 이름입니다.MSA는 도메인 이름을 해결하고 Domain Name System(DNS; 도메인네임 시스템)에서 메일서버의 완전 수식 도메인 이름을 결정합니다.
  3. 도메인 b.org(ns.b.org)의 DNS 서버는 해당 도메인의 메일 교환 서버(이 경우 mx.b.org)를 나열하는 MX 레코드로 응답합니다.이 경우 수신인의 [34]ISP에 의해 실행되는 Message Transfer Agent(MTA; 메시지 전송 에이전트) 서버입니다.
  4. smtp.a.org 는, SMTP 를 사용해 mx.b.org 에 메세지를 송신합니다.이 서버는 메시지가 최종 Message Delivery Agent(MDA; 메시지 배달 에이전트)에 도달하기 전에 메시지를 다른 MTA로 전송해야 할 수 있습니다.
  5. MDA는 이것을 사용자 bob의 우편함에 전달합니다.
  6. Bob의 MUA는 Post Office Protocol(POP3) 또는 Internet Message Access Protocol(IMAP)을 사용하여 메시지를 수신합니다.

이 예와 더불어 이메일 시스템에는 다음과 같은 대체 방법과 복잡한 문제가 있습니다.

  • Alice 또는 Bob은 IBM Lotus Notes 또는 Microsoft Exchange와 같은 회사 이메일 시스템에 연결된 클라이언트를 사용할 수 있습니다.이러한 시스템은 자체 이메일 형식을 가지고 있으며, 일반적으로 클라이언트는 벤더 고유의 독점 프로토콜을 사용하여 이메일 서버와 통신합니다.서버는 제품의 인터넷 메일 게이트웨이를 통해 인터넷을 통해 이메일을 보내거나 수신합니다. 이 게이트웨이는 필요한 재포맷도 수행합니다.Alice와 Bob이 같은 회사에서 일하는 경우, 전체 트랜잭션은 하나의 회사 이메일 시스템 내에서 완전히 발생할 수 있습니다.
  • Alice는 컴퓨터에 MUA가 없을 수 있지만 대신 웹 메일 서비스에 연결할 수 있습니다.
  • Alice의 컴퓨터는 자체 MTA를 실행할 수 있으므로 1단계에서 전송을 피하십시오.
  • 밥은 mx.b.org에 로그인하여 직접 읽거나 웹 메일 서비스를 사용하는 등 여러 가지 방법으로 이메일을 받을 수 있습니다.
  • 도메인은 일반적으로 주 서버를 사용할 수 없는 경우에도 메일을 계속 수신할 수 있도록 여러 개의 메일 교환 서버를 가지고 있습니다.

많은 MTA는 인터넷 상의 모든 수신자에게 메시지를 수신하고 메시지를 전달하기 위해 최선을 다했습니다.이러한 MTA를 오픈 메일 릴레이라고 부릅니다.이것은 네트워크 접속을 신뢰할 [35][36]수 없었던 인터넷 초창기에 매우 중요했습니다.그러나 이 메커니즘은 불필요한 대량 전자 메일의 발신자에 의해 악용될 수 있는 것으로 판명되었으며, 그 결과 열린 메일 릴레이가 [37]드물어져 많은 MTA가 열린 메일 릴레이로부터의 메시지를 받아들이지 않습니다.

메시지 형식

이메일에 사용되는[38] 기본 인터넷 메시지 형식은 다음과 같이 정의됩니다. RFC5322. RFC 2045에서 RFC 2049까지에 정의되어 있는 비 ASCII 데이터 및 멀티미디어 콘텐츠 첨부 파일의 인코딩을 사용하여 집합적으로 MIME이라고 부릅니다.국제 전자 메일의 확장자는 전자 메일에만 적용됩니다.RFC 5322는 2008년에 이전의 RFC 2822를 대체하고 2001년에 RFC 2822를 대체했습니다.RFC 822는 수십 년 동안 인터넷 이메일의 표준이었습니다.1982년에 발표된 RFC 822는 이전의 ARPANET용 [39]RFC 733에 기초하고 있습니다.

인터넷 이메일 메시지는 'header'와 'body'의 두 섹션으로 구성됩니다.이들은 '콘텐츠'[40][41]로 알려져 있습니다.헤더는 From, To, CC, Subject, Date 등의 필드 및 이메일에 대한 기타 정보로 구성됩니다.시스템 간에 전자 메일메시지를 전송하는 과정에서 SMTP는 메시지 헤더필드를 사용하여 전달 파라미터와 정보를 통신합니다.본문에는 메시지(구조화되지 않은 텍스트)가 포함되어 있으며 마지막에 시그니처 블록을 포함할 수 있습니다.헤더는 본문에서 공백 행으로 구분됩니다.

메시지 헤더

RFC 5322 에서는, 전자 메일 헤더의 구문이 규정되어 있습니다.각 전자 메일 메시지에는 여러 필드("헤더 필드")로 구성된 헤더(사양에 따라 메시지의 "헤더 섹션")가 있습니다.각 필드에는 이름("필드 이름" 또는 "헤더 필드 이름")과 구분 문자 ":" 및 값("필드 본문" 또는 "헤더 필드 본문")이 있습니다.

각 필드명은 헤더 섹션의 새로운 행의 첫 번째 문자로 시작하여 공백이 아닌 인쇄 가능 문자로 시작합니다.끝은 구분 문자 ":"로 끝납니다.구분 기호 뒤에 필드 값("필드 본문")이 나옵니다.이러한 행에 첫 번째 문자로 공백 또는 탭이 있는 경우 값은 후속 행으로 계속 이어질 수 있습니다.필드 이름 및 SMTPUTF8을 사용하지 않을 경우 필드 본문은 7비트 ASCII 문자로 제한됩니다.ASCII 이외의 일부 값은 MIME 부호화 워드를 사용하여 나타낼 수 있습니다.

헤더 필드

이메일 헤더필드는 여러 줄로 만들 수 있으며 각 행은 78자 이내로 하는 것이 좋습니다.[42]단, 제한은 998자입니다.RFC 5322에서 정의된 헤더필드에는 US-ASCII 문자만 포함됩니다.다른 세트의 부호화 문자의 경우 RFC 2047에서 지정된 구문을 [43]사용할 수 있습니다.일부 예에서는 IETF EAI 작업 그룹이 일부 표준 트랙 [44][45]확장을 정의하고 UTF-8 인코딩된 Unicode 문자를 헤더 내에서 사용할 수 있도록 이전의 실험 확장자를 대체합니다.특히, 이것에 의해, E-메일 주소는 비ASC 를 사용할 수 있습니다.II 문자이러한 주소는 Google 및 Microsoft 제품에 의해 지원되며 일부 정부 [46]에이전트에 의해 홍보됩니다.

메시지 헤더에는 적어도 다음 [47][48]필드가 포함되어야 합니다.

  • 보낸 사람: 이메일 주소 및 작성자 이름(선택 사항)입니다.일부 이메일 클라이언트는 계정 설정을 통해 변경할 수 있습니다.
  • 날짜: 메시지가 작성된 로컬 시각 및 날짜.From: 필드와 마찬가지로 많은 전자 메일클라이언트는 송신 전에 이 정보를 자동으로 입력합니다.수신인의 클라이언트는 수신인의 로컬 형식과 표준 시간대로 시간을 표시할 수 있습니다.

RFC 3864에서는 IANA에서의 메시지헤더 필드의 등록 절차에 대해 설명하고 있습니다.MIME, Netnews 및 HTTP용으로 정의된 필드를 포함하여 영속적인 필드명 및 잠정적인 필드명을 지정하고 관련 RFC를 참조합니다.이메일의 일반적인 헤더 필드는 다음과 같습니다.[49]

  • 수신인: 메시지 수신인의 이메일 주소 및 이름(선택 사항)입니다.프라이머리 수신자(복수 허용)를 나타냅니다.세컨더리 수신자에 대해서는, 다음의 「참조:」및 「비밀 참조:」를 참조해 주세요.
  • 제목 : 메시지 토픽의 간단한 요약."RE:" 및 "FW:"를 포함한 특정 약어가 주제에서 일반적으로 사용됩니다.
  • 참조: 카본 복사: 많은 전자 메일 클라이언트는 수신인: 또는 참조인: 목록에 있는지 여부에 따라 받은 편지함에 전자 메일을 다르게 표시합니다.
  • 숨은 참조: 블라인드 카본 복사.주소는 보통 SMTP 전송 중에만 지정되며, 일반적으로 메시지 헤더에는 표시되지 않습니다.
  • Content-Type: 메시지 표시 방법에 대한 정보(일반적으로 MIME 유형).
  • 우선 순위: 일반적으로 값이 "bulk", "junk" 또는 "list"입니다. 자동 "휴가" 또는 "부재중" 응답을 나타내기 위해 사용되는 경우, 예를 들어 휴가 통지가 메일링 목록의 다른 모든 사용자에게 발송되지 않도록 하기 위해 이 메일에 대해 반환해서는 안 됩니다.Sendmail은 이 필드를 사용하여 "Precedence: Special-Delivery" 메시지가 더 빨리 배달되는 대기 중인 전자 메일의 우선 순위에 영향을 줍니다.현대의 고대역폭 네트워크에서는 전달 우선순위는 이전보다 문제가 되지 않습니다.Microsoft Exchange 에서는, 상세한 자동 응답 억제 메카니즘인 「X-Auto-Response-Suppress[50]필드에 준거하고 있습니다.
  • 메시지 ID:또, 복수의 딜리버리(Delivery)를 방지해, 회답처:(아래를 참조해 주세요).
  • In-Reply-To: 회신 메시지 ID.관련 메시지를 링크하기 위해 사용됩니다.이 필드는 회신 메시지에만 적용됩니다.
  • 참고 자료:이것이 응답인 메시지의 메시지 ID 및 이전 응답이 응답인 메시지의 메시지 ID 등입니다.
  • [회신처(Reply-To)
  • 보낸 사람: 보낸 사람: 필드에 나열된 작성자(비서, 목록 관리자 등)를 대신하는 보낸 사람의 주소입니다.
  • Archived-At: 개별 전자 메일 메시지의 아카이브 형식에 대한 직접 링크입니다.

받는 사람: 필드는 메시지가 배달되는 주소와 관련이 없을 수 있습니다.전송 목록은 헤더 콘텐츠에서 추출할 수 있는 전송 프로토콜인 SMTP에 별도로 제공됩니다."수신인:" 필드는 외부 봉투에 있는 주소에 따라 배달되는 기존의 편지 상단에 있는 주소와 유사합니다.마찬가지로 "From:" 필드가 발신인이 아닐 수도 있습니다.일부 메일 서버는 릴레이된 메시지에 전자 메일 인증 시스템을 적용합니다.서버의 활동과 관련된 데이터도 아래에 정의된 것처럼 헤더의 일부입니다.

SMTP 는, 다음의 2 개의 [51]필드를 사용해 헤더에 보존된 메시지의 트레이스 정보를 정의합니다.

  • 수신: SMTP 서버는 메시지를 수신한 후 헤더 상단에 이 트레이스 레코드를 삽입합니다(마지막에서 첫 번째).
  • Return-Path: 전달 SMTP 서버가 메시지를 최종 전달한 후 헤더 상단에 이 필드를 삽입합니다.

수신 서버에 의해 헤더 상단에 추가된 다른 필드는 트레이스 [52]필드라고 불립니다.

  • Authentication-Results: 서버는 인증을 검증한 후 결과를 다운스트림에이전트에서 [53]사용할 수 있도록 이 필드에 저장할 수 있습니다.
  • Received-SPF: SPF 체크 결과를 Authentication-Results보다 [54]상세하게 저장합니다.
  • DKIM-Signature: DomainKeys Identified Mail(DKIM; 도메인키 식별 메일) 암호 해독 결과를 저장하여 메시지가 [55]발송된 후 변경되지 않았는지 확인합니다.
  • Auto-Submitted:[56] 자동 생성된 메시지를 표시하기 위해 사용합니다.
  • VBR-Info: VBR 화이트리스트[57] 청구

메시지 본문

콘텐츠 인코딩

인터넷 이메일은 7비트 [58]ASCII용으로 설계되었습니다.대부분의 전자 메일 소프트웨어는 8비트 클린이지만 7비트 서버 및 메일 리더와 통신할 것으로 가정해야 합니다.MIME 규격에서는 ASCII 이외의 데이터의 전송을 가능하게 하는 문자 세트 지정자와 2개의 컨텐츠 전송 인코딩이 도입되었습니다.대부분의 7비트 컨텐츠에 대해서는, 그 범위 밖에 있는 몇개의 문자의 인쇄 가능, 임의의 바이너리 데이터에 대해서는 base64 입니다.8BITMIME BINARY 확장자는 이러한 인코딩 없이 메일을 전송할 수 있도록 도입되었지만 많은 메일 전송 에이전트는 이러한 확장자를 지원하지 않을 수 있습니다.일부 국가에서는 이메일소프트웨어가 ASCII 이외의 원시 텍스트를 전송하여[nb 3] RFC 5322위반하고 여러 인코딩 방식이 공존하고 있습니다.그 결과, 디폴트에서는, 라틴어 이외의 알파벳 언어의 메세지가 판독 불가능한 형태로 표시됩니다(송신측과 수신측이 같은 인코딩 방식을 사용하는 경우는, 유일한 예외입니다).따라서 국제 문자 집합의 경우 유니코드의 [59]인기가 높아지고 있습니다.

일반 텍스트 및 HTML

대부분의 최신 그래픽 전자 메일 클라이언트에서는 사용자가 임의로 메시지 본문에 일반 텍스트 또는 HTML을 사용할 수 있습니다.HTML 이메일 메시지에는 호환성을 위해 자동 생성된 일반 텍스트 복사본이 포함되어 있는 경우가 많습니다.HTML의 장점은 인라인 링크와 이미지를 포함하거나, 이전 메시지를 블록 따옴표로 구분하거나, 디스플레이에서 자연스럽게 랩하거나, 밑줄이나 이탤릭체 등의 강조를 사용하거나, 글꼴 스타일을 변경할 수 있다는 것입니다.단점으로는 이메일 크기 증가, 버그에 대한 사생활 문제, 피싱 공격의 매개체로서의 HTML 이메일 남용, 악성 소프트웨어 [60]확산 등이 있습니다.

일부 전자 메일 클라이언트는 본문을 HTML로 해석합니다.Content-Type: html헤더 필드. 이로 인해 다양한 문제가 발생할 수 있습니다.

일부 웹 기반 메일링 리스트에서는 위의 이유로 [61][62]에 72자 또는 80자의 일반 텍스트로 모든 투고를 작성할 것을 권장합니다.또한 Mutt와 같은 텍스트 기반 전자 메일클라이언트를 사용하는 독자가 상당히 많기 때문입니다.Microsoft 전자 메일클라이언트에 따라서는 독자적인 RTF(Rich Text Format)를 사용한 리치 포맷을 허가하는 경우가 있습니다만, 수신자가 호환성이 있는 전자 메일클라이언트를 [63]가지고 있는 것을 보증하지 않는 한, 이 포맷은 피해야 합니다.

서버 및 클라이언트 응용 프로그램

이메일 클라이언트 Thunderbird의 인터페이스입니다.

메시지는 Simple Mail Transfer Protocol을 사용하여 MTA(메일 전송 에이전트)라는 소프트웨어 프로그램과 호스트 간에 교환되며 메일 배달 에이전트(MDA, 로컬 배달 에이전트라고도 함)에 의해 메일 저장소에 전달됩니다.메시지를 받아들이면 MTA가 메시지를 [64]전달해야 합니다.메시지를 전달할 수 없는 경우 MTA는 문제를 나타내는 바운스메시지를 발신인에게 반송해야 합니다.

사용자는 POP 또는 IMAP과 같은 표준 프로토콜을 사용하거나, 대규모 기업 환경에서 Novell Groupwise, Lotus Notes 또는 Microsoft Exchange Server에 고유한 독점 프로토콜을 사용하여 서버에서 메시지를 검색할 수 있습니다.사용자가 전자 메일을 검색, 읽기 및 관리하는 데 사용하는 프로그램을 MUA(메일 사용자 에이전트)라고 합니다.

전자 메일을 열면 "읽기"로 표시되므로 일반적으로 클라이언트의 사용자 인터페이스에 있는 "읽지 않은" 메시지와 명확하게 구분됩니다.전자 메일 클라이언트는 사용자가 [65]읽지 않은 전자 메일에 집중할 수 있도록 받은 편지함에서 읽은 전자 메일을 숨길 수 있습니다.

메일은 클라이언트, 서버 또는 둘 다에 저장할 수 있습니다.우편함의 표준 형식에는 Maildirmbox가 있습니다.몇몇 유명한 이메일 클라이언트는 독자적인 포맷을 사용하고 있으며 이메일을 전송하기 위해 변환 소프트웨어가 필요합니다.서버 측 스토리지는 종종 독자 사양이지만 IMAP와 같은 표준 프로토콜을 통해 액세스하기 때문에 프로토콜을 지원하는 MUA를 통해 서버 간에 전자 메일을 이동할 수 있습니다.

현재 많은 이메일 사용자는 MTA, MDA 또는 MUA 프로그램을 직접 실행하지 않고 Gmail이나 Yahoo!와 같은 웹 기반 이메일 플랫폼을 사용합니다. 메일 - 동일한 [66]태스크를 수행합니다.이러한 웹 메일 인터페이스를 통해 사용자는 로컬 전자 메일 클라이언트에 의존하지 않고 모든 컴퓨터에서 표준 웹 브라우저를 사용하여 메일에 액세스할 수 있습니다.

파일 이름 확장자

전자 메일 메시지를 수신하면 전자 메일 클라이언트 응용 프로그램은 메시지를 파일 시스템의 운영 체제 파일에 저장합니다.개별 메시지를 개별 파일로 저장하는 클라이언트도 있고, 집합 스토리지에 다양한 데이터베이스 형식(대부분 독점)을 사용하는 클라이언트도 있습니다.스토리지의 과거 표준은 mbox 형식입니다.사용되는 특정 형식은 종종 특수 파일 확장자로 나타납니다.

eml
Novell GroupWise, Microsoft Outlook Express, Lotus Notes, Windows Mail, Mozilla Thunderbird 및 Postbox를 비롯한 많은 전자 메일 클라이언트에서 사용됩니다.파일에는 여러 형식 중 하나 이상의 첨부 파일을 포함하여 전자 메일 헤더 및 본문이 포함된 MIME 형식일반 텍스트로 전자 메일 내용이 포함됩니다.
emlx
Apple Mail에서 사용합니다.
msg
Microsoft Office Outlook 및 Office Logic 그룹웨어에서 사용됩니다.
mbx
mbox 형식을 기반으로 Opera Mail, KMailApple Mail에서 사용됩니다.

일부 응용 프로그램(예: Apple Mail)은 검색하기 위해 메시지에 인코딩된 첨부 파일을 남겨두고 첨부 파일의 복사본을 저장합니다.다른 사용자는 첨부 파일을 메시지에서 분리하여 특정 디렉토리에 저장합니다.

URI 스킴 mailto

IANA에 등록된 URI 스킴에 의해,mailto:SMTP 이메일주소의 스킴.이 양식의 URL은 엄격히 정의되어 있지 않지만, URL이 활성화될 때 수신인 [67][68]필드의 URL로 정의된 주소로 사용자의 메일 클라이언트의 새 메시지 창을 열기 위해 사용됩니다.또한 많은 클라이언트는 제목 줄이나 카본 복사 [69]수신자와 같은 다른 전자 메일 필드에 대한 쿼리 문자열 매개 변수를 지원합니다.

종류들

웹 기반 이메일

많은 전자 메일 공급자는 웹 기반 전자 메일 클라이언트를 가지고 있습니다.이를 통해 사용자는 호환되는 웹 브라우저를 사용하여 전자 메일 계정에 로그인하여 전자 메일을 보내고 받을 수 있습니다.일반적으로 메일은 웹 클라이언트에 다운로드되지 않으므로 현재 인터넷에 연결되어 있지 않으면 읽을 수 없습니다.

POP3 이메일 서버

POP3(Post Office Protocol 3)는 클라이언트 응용프로그램이 메일 서버에서 메시지를 읽기 위해 사용하는 메일 액세스 프로토콜입니다.수신된 메시지는 서버에서 삭제되는 경우가 많습니다.POP에서는 리모트메일함에의 액세스에 관한 [70]간단한 다운로드 및 삭제 요건을 서포트하고 있습니다(POP RFC에 기재되어 있습니다).POP3를 사용하면 로컬 컴퓨터에 전자 메일 메시지를 다운로드하여 오프라인 [71][72]상태에서도 읽을 수 있습니다.

IMAP 이메일 서버

Internet Message Access Protocol(IMAP)은 여러 장치에서 우편함을 관리하는 기능을 제공합니다.스마트폰과 같은 소형 휴대용 기기는 이동 중에 이메일을 확인하고 간단한 회신을 하는 데 점점 더 많이 사용되고 있으며, 키보드 접근성이 뛰어난 대형 기기는 더 긴 회신을 하는 데 사용되고 있습니다.IMAP 에는, 메시지의 헤더, 송신자, 및 제목과 디바이스가 특정의 메시지의 다운로드를 요구할 필요가 있는 것이 표시됩니다.일반적으로 메일은 메일 서버의 폴더에 남아 있습니다.

MAPI 이메일 서버

MAPI(Messaging Application Programming Interface)는 Microsoft Exchange Server 및 Axigen Mail Server, Kerio Connect, Scalix, Zimbra, HP OpenMail, IBM Lotus Notes, Zarafa 및 Bynari 벤더와 통신하기 위해 Microsoft Outlook에서 사용됩니다.Outlook을 통해 직접 삽입.

사용하다

비즈니스 및 조직의 용도

이메일은 선진국에서 기업, 정부 및 비정부기구에서 널리 받아들여지고 있으며, 직장 커뮤니케이션의 'e-혁명'의 핵심 요소 중 하나입니다(또 다른 핵심 요소는 고속 인터넷의 광범위한 채택).2010년 직장 커뮤니케이션에 관한 협찬 조사에 따르면 미국 지식노동자의 83%가 이메일이 직장에서의 [73]성공과 생산성에 중요하다고 느끼고 있습니다.

비즈니스 및 기타 조직에 다음과 같은 몇 가지 주요 이점이 있습니다.

로지스틱스의 원활화
대부분의 비즈니스 세계는 물리적으로 같은 건물, 지역 또는 국가에 있지 않은 사람들 간의 커뮤니케이션에 의존하고 있습니다.직접 회의, 전화 통화 또는 전화 회의의 셋업과 참석은 불편하고 시간이 많이 걸리며 비용이 많이 들 수 있습니다.전자 메일은 셋업 비용 없이 둘 이상의 사용자 간에 정보를 교환하는 방법을 제공하며 일반적으로 물리적 회의나 전화 통화보다 훨씬 저렴합니다.
동기화 지원
회의 또는 전화에 의한 실시간 통신을 사용하는 경우, 참가자는 같은 스케줄에 따라 작업해야 하며, 각 참가자는 회의 또는 통화에 같은 시간을 소비해야 합니다.이메일은 비동기화를 허용합니다.각 참가자는 개별적으로 스케줄을 제어할 수 있습니다.착신 전자 메일을 일괄 처리하면, 콜을 중단하는 것에 비해 워크플로우를 개선할 수 있습니다.
비용 절감
이메일을 보내는 것은 우편이나 장거리 전화, 텔렉스 또는 전보를 보내는 것보다 훨씬 저렴하다.
고속화
대부분의 대안보다 훨씬 더 빠릅니다.
"쓰기된" 레코드 만들기
전화나 직접 대화와 달리 이메일은 본질적으로 통신, 발신자 및 수신자의 신원, 메시지가 발송된 날짜와 시간에 대한 상세한 서면 기록을 작성합니다.계약 또는 법적 분쟁이 발생한 경우 저장된 이메일을 사용하여 각 이메일에 날짜와 시간이 기록되므로 특정 문제에 대해 개인에게 통지되었음을 증명할 수 있습니다.
자동 처리 및 유통 개선 가능성
또, 고객의 주문의 전처리나 담당자의 대응도 자동화해 실시할 수 있습니다.

이메일 마케팅

"옵션인"을 통한 이메일 마케팅은 특별한 판매 상품 및 신제품 [74]정보를 보내는 데 자주 사용됩니다.수신자의 [75]문화에 따라서는, 허가 없이 송신된 전자 메일(예: 「옵션인」)은 환영받지 못하는 「전자 메일 스팸」으로 간주될 가능성이 있습니다.

개인 용도

퍼스널 컴퓨터

많은 사용자들은 그들의 집이나 아파트에서 개인 컴퓨터를 사용하여 친구나 가족들로부터 개인 이메일에 접속합니다.

모바일.

이메일은 스마트폰과 모든 종류의 컴퓨터에서 사용되고 있다.이메일용 모바일 "앱"은 집 밖에 있는 사용자의 미디어에 대한 접근성을 향상시킵니다.이메일이 발송된 초기에는 데스크톱 컴퓨터에서만 이메일에 액세스할 수 있었지만, 2010년대에는 사용자가 외출할 때 이메일을 확인할 수 있게 되었습니다.이메일은 시내를 넘어 전 세계를 불문하고 사용할 수 있게 되었습니다.또한 스마트폰이나 다른 기기에 경보를 보내 새 메시지를 즉시 알릴 수도 있습니다.이것에 의해, 유저간의 보다 빈번한 커뮤니케이션에 E-메일을 사용할 수 있게 되어, 유저는 하루 종일 E-메일을 체크해 메세지를 쓸 수 있게 되었습니다.2011년 현재 전세계 이메일 사용자는 약 14억 명, 비스팸 이메일은 [68]약 500억 명입니다.

개인은 종종 스마트폰에서 개인 메시지와 업무 관련 메시지를 모두 확인해요.미국 성인들은 웹브라우징이나 페이스북 계정보다 이메일을 더 많이 확인하는 것으로 밝혀져 이메일을 스마트폰에서 가장 인기 있는 활동인 것으로 나타났다.조사에 참여한 응답자의 78%가 전화로 [76]이메일을 확인한다고 밝혔다.소비자의 30%가 이메일 확인에 스마트폰만 사용하는 것으로 나타났고, 91%는 스마트폰으로 이메일을 하루에 한 번 이상 확인하는 것으로 나타났다.그러나 스마트폰에서 이메일을 사용하는 소비자의 비율은 국가에 따라 크게 다릅니다.예를 들어, 미국 소비자의 75%와 비교했을 때, 인도 소비자의 17%만이 그것을 사용했다.[77]

젊은 층의 이용 감소

2010년 현재 이메일 사이트를 방문하는 미국인의 수는 2009년 11월에 정점을 찍은 후 6% 감소했다.12~17명의 경우 18% 감소했다.젊은이들은 인스턴트 메시지, 문자, 소셜 미디어선호했다.테크놀로지 라이터인 Matt Richtel은 New York Times에서 이메일은 VCR, 비닐 레코드필름 카메라와 비슷하며 더 이상 쿨하지 않고 나이 든 사람들이 [78][79]하는 일이라고 말했습니다.

Android 사용자를 대상으로 한 2015년 조사에서 13~24명이 45세 이상보다 3.5배 더 많은 메시징 앱을 사용했으며 이메일을 [80]사용할 가능성은 훨씬 낮았다.

문제들

첨부 파일 크기 제한

이메일 메시지에는 이메일에 추가되는 추가 파일인 첨부 파일이 하나 이상 있을 수 있습니다.일반적인 첨부 파일에는 Microsoft Word 문서, PDF 문서 및 종이 문서의 스캔 이미지가 포함됩니다.첨부 파일의 크기나 수에는 원칙적으로 기술적인 제한이 없습니다.그러나 실제로는 전자 메일 클라이언트, 서버 및 인터넷 서비스 공급자가 파일 크기 또는 전체 전자 메일 크기에 대해 다양한 제한(일반적으로 25MB 이하)[81][82][83]을 구현합니다.또, 기술적인 이유로, 이러한 트랜스포트 시스템에 표시되는 첨부 파일의 사이즈가 유저에게 [84]표시되는 사이즈와 다를 가능성이 있습니다.이러한 사이즈는, 송신자가 이메일로 파일을 안전하게 송신할 수 있는지를 판단할 때, 송신자에게 혼란을 줄 가능성이 있습니다.대용량 파일을 공유해야 하는 경우 다양한 파일 호스팅 서비스를 사용할 수 있으며 일반적으로 사용됩니다.[85][86]

정보의 과부하

지식노동자나 화이트칼라 종업원을 위한 이메일이 보편화됨에 따라 수신자가 증가하는 [87][88]이메일 처리에서 "정보 과부하"에 직면할 것이라는 우려가 제기되고 있습니다.모바일 기기가 증가함에 따라 기본적으로 직원들은 근무일 이외에도 업무 관련 이메일을 받을 수 있습니다.이것은 스트레스의 증가와 일에 대한 만족도 저하로 이어질 수 있다.일부 관측통들은 심지어 많은 이메일을 읽으려는 노력이 생산성을 떨어뜨릴 수 있기 때문에 이것이 상당한 경제적 [89]영향을 미칠 수 있다고 주장한다.

스팸

전자 메일 "스팸"은 원하지 않는 대량 전자 메일입니다.이러한 전자 메일의 송신 코스트가 낮기 때문에, 2003년에는 총 전자 메일 트래픽의 최대 30%가 [90][91][92]스팸이 되어, 실용적인 툴로서의 전자 메일의 유용성이 위협받고 있었습니다.2003년의 미국 CAN-SPAM법 및 기타 유사한 법률이[93] 영향을 미쳤으며,[94] 많은 효과적인 안티스팸 기법들이 스팸을 필터링하거나 거부함으로써 스팸의 영향을 크게 완화시키고 있지만, 전송되는 양은 여전히 매우 많아 제품에 대한 광고가 아닌 악의적인 콘텐츠 또는 [95]링크 등으로 구성되어 있습니다.예를 들어, 2017년 9월에는 합법적인 이메일에 대한 스팸 비율이 59.56%[96]로 증가했습니다.2021년 스팸 메일의 비율은 85%[97][better source needed]로 추정됩니다.

말웨어

다양한 악성 전자 메일 유형이 있습니다.여기에는 사전 수수료 사기 "Nigerian Letters"와 같은 "Social Engineering" 사기, 피싱, 전자 메일 버드 및 전자 메일 웜 등 다양유형의 전자 메일 사기가 포함됩니다.

이메일 스푸핑

전자 메일 스푸핑은 전자 메일 메시지 헤더가 메시지가 알려진 소스 또는 신뢰할 수 있는 원본에서 온 것으로 보이도록 설계된 경우 발생합니다.전자 메일 스팸 피싱 방법은 일반적으로 스푸핑을 사용하여 수신자에게 실제 메시지 원본에 대해 오인합니다.전자 메일 스푸핑은 장난이나 개인 또는 조직을 사취하기 위한 범죄 활동의 일부로 수행될 수 있습니다.사기성 전자 메일 스푸핑의 예로는 개인이 대기업의 청구서로 보이는 전자 메일을 작성하여 한 명 이상의 수신자에게 보내는 경우가 있습니다.경우에 따라서는, 이러한 부정 이메일에 조직의 로고가 포함되어 있어, 전자 메일 주소도 정규인 것처럼 보일 수 있습니다.

이메일 폭격

이메일 폭파는 대량의 메시지를 대상 주소로 의도적으로 보내는 것입니다.대상 전자 메일 주소를 오버로드하면 사용할 수 없게 되고 메일 서버가 충돌할 수도 있습니다.

프라이버시 문제

현재는 인터넷과 내부 이메일 시스템을 구별하는 것이 중요할 수 있습니다.인터넷 이메일은 발신인 또는 수신인의 제어 없이 이동하거나 네트워크 및 컴퓨터에 저장될 수 있습니다.전송 시간 중에는 제삼자가 내용을 읽거나 수정할 수도 있습니다.정보가 조직 네트워크에서 유출되지 않는 내부 메일 시스템은 보다 안전할 수 있습니다.단, 감시 또는 관리와 관련된 IT 직원 및 기타 기능이 다른 직원의 이메일에 액세스하고 있을 수 있습니다.

다음과 같은 이유로 보안 예방 조치 없이 전자 메일 개인 정보가 침해될 수 있습니다.

  • 이메일 메시지는 일반적으로 암호화되지 않습니다.
  • 전자 메일 메시지는 수신처에 도달하기 전에 중간 컴퓨터를 통과해야 합니다. 즉, 다른 사용자가 메시지를 가로채고 읽는 것이 비교적 쉽다는 것을 의미합니다.
  • 많은 ISP(Internet Service Provider)는 전자 메일 메시지가 배달되기 전에 메일 서버에 전자 메일 메시지의 복사본을 저장합니다.이러한 백업은 우편함에서 삭제되어도 서버에 최대 몇 개월 동안 남아 있을 수 있습니다.
  • "수신됨:" 필드 및 전자 메일의 기타 정보는 종종 발신인을 식별하여 익명 통신을 방지할 수 있습니다.
  • HTML 컨텐츠에 눈에 띄지 않게 짜넣어진 Web 버그는, E-메일이 HTML 로 렌더링 될 때마다(일부 E-메일 클라이언트는, E-메일을 읽거나 재읽을 때에 이것을 실시합니다), 송신자에게 통지할 수 있습니다.또, 어느 IP 주소도 통지할 수 있습니다.또한 사용자 에이전트 문자열을 통해 스마트폰, PC 또는 Apple Mac 장치에서 전자 메일을 읽었는지도 확인할 수 있습니다.

상기 중 하나 또는 여러 가지에 대한 해결책으로 사용할 수 있는 암호화 애플리케이션이 있습니다.예를 들어, 가상 사설 네트워크 또는 토르 네트워크는 동안 GPG, PGP6.5.8은 PGP, SMEmail,[98]또는 S/MIME 엔드 투 엔드 메시지 암호화에 사용할 수 있는 사용자 기기에서 더 안전한 네트워크에 트래픽 암호화하는 데,와 SMTPSTARTTLSSMTPTransportLayerSecurity/Secure는 SSL기반의 동안 단일 우편 ho에 대한 통신 암호화하는 데 사용될 수도 있는 시스템.pbSMTP 클라이언트와 SMTP 서버 사이에 있습니다.

또한 많은 메일 사용자 에이전트는 로그인 및 비밀번호를 보호하지 않으므로 공격자가 쉽게 가로채게 됩니다.SASL 등의 암호화 인증 스킴에 의해 이 문제가 회피됩니다.마지막으로 첨부된 파일은 피어 투 피어 파일 공유에서 발견되는 위험과 동일한 위험을 공유합니다.첨부된 파일에는 트로이 목마나 바이러스가 포함되어 있을 수 있습니다.

법적 계약

이메일 교환은 구속력 있는 계약을 맺을 수 있으므로 사용자는 이메일 [99][100]서신을 통해 보내는 내용에 주의해야 합니다.이메일의 서명 블록은 [101]계약에 대한 서명 요건을 충족하는 것으로 해석될 수 있습니다.

불타기

플래밍은 어떤 사람이 분노하거나 적대적인 내용으로 메시지(또는 많은 메시지(또는 많은 메시지)이 용어는 특히 열띤 이메일 토론을 설명하기 위해 incidentary라는 단어를 사용한 데서 유래되었습니다.이메일 의사소통의 용이성과 비인격성은 직접 또는 전화로 공손함을 장려하는 사회적 규범이 존재하지 않으며 공손함이 [102]잊혀질 수 있음을 의미합니다.

이메일 파산

e-메일 파산은 e-메일 메시지를 읽고 답하는 데 뒤처진 뒤 이를 무시하는 것을 말한다.뒤처지는 이유는 종종 정보의 과부하와 일반의식 때문에 모든 것을 읽을 수 없을 정도로 많은 정보가 있다.해결책으로 이메일 수신함이 꽉 차서 모든 메시지를 지우는 중임을 설명하는 "보일러 플레이트" 메시지를 보내는 경우가 있습니다.하버드 대학교 법학과 교수 로렌스 레식은 이 용어를 만든 것으로 알려져 있지만, 그는 단지 [103]이 용어를 대중화했을 뿐이다.

국제화

원래 인터넷 이메일은 완전히 ASCII 텍스트 기반이었습니다.MIME은 이제 국제 문자 집합에서 본문 내용 텍스트와 일부 헤더 내용 텍스트를 허용하지만 UTF-8을 사용하는 다른 헤더와 이메일 주소는 아직[104] 널리 [2][105]채택되지 않았습니다.

발송 메일 추적

원래의 SMTP 메일서비스는, 송신된 메시지를 추적하기 위한 제한적인 메카니즘을 제공하지만, 송신된 메시지 또는 읽혀진 메시지를 확인하기 위한 메카니즘은 없습니다.각 메일 서버가 계속 전달하거나 장애 알림(바운스 메시지)을 반환해야 하지만 소프트웨어 오류와 시스템 장애로 인해 메시지가 손실될 수 있습니다.이를 수정하기 위해 IETF는 Delivery Status Notification(Delivery Status Notification)(Delivery Status Notification)(Delivery Status Notification)(Delivery Disposition Notification)(Return Receipt)을 도입했습니다.다만,[nb 4] 이것들은, 실가동시에 보편적으로 전개되고 있는 것은 아닙니다.

현재 많은 ISP는 스팸 발송자의 액티비티에 의해 Non-Delivery Report(NDR; 비배달 보고서) 및 배달 확인을 의도적으로 비활성화합니다.

  • Delivery Reports를 사용하여 주소가 존재하는지 여부를 확인할 수 있습니다.존재하는 경우 스팸 발송자에게 스팸 발송이 가능함을 나타냅니다.
  • 스팸 송신자가 위조된 송신자 전자 메일주소(이메일 스푸핑)를 사용하고 있는 경우, 사용된 무해한 전자 메일주소는 스팸 송신자가 메일을 송신하려고 했을 가능성이 있는 다수의 무효 전자 메일주소의 NDR로 플래딩 될 가능성이 있습니다.이러한 NDR은 ISP에서 무고한 사용자에게 스팸을 구성합니다.

표준 방법이 없는 경우 웹 버그 사용을 중심으로 한 다양한 시스템이 개발되었습니다.그러나, 이러한 문제는, HTML [108][109]의 렌더링을 서포트하고 있는 전자 메일 클라이언트에서만 동작하는 경우가 많아, 디폴트로 「Web 컨텐츠」[110]를 표시하지 않게 되어 있습니다. 메일 공급자는 이미지를 미리 캐시하여 [111]웹 버그를 방해할 수도 있습니다.

「 」를 참조해 주세요.

메모들

  1. ^ IBM의 시스템은 정식 출시 전에 요청 시 고객에게 제공되었습니다.
  2. ^ '프로토콜 전쟁'을 참조하십시오.
  3. ^ 국제화 이메일 또는 MIME 사용 안 함
  4. ^ 완전한 메시지 트래킹메커니즘도 정의되어 있습니다만, 그 메커니즘은 트랙션을 얻지 못했습니다.RFC 3885[106] ~[107]3888을 참조해 주세요.

레퍼런스

  1. ^ "RFC 5321 – Simple Mail Transfer Protocol". Network Working Group. Archived from the original on January 16, 2015. Retrieved January 19, 2015.
  2. ^ a b "DataMail: World's first free linguistic email service supports eight India languages". Archived from the original on October 22, 2016.
  3. ^ a b "email noun earlier than 1979". Oxford English Dictionary. October 25, 2012. Retrieved May 14, 2020.
  4. ^ a b Ohlheiser, Abby (July 28, 2015). "Why the first use of the word 'e-mail' may be lost forever". Washington Post. Retrieved May 14, 2020.
  5. ^ "Yahoo style guide". Styleguide.yahoo.com. Archived from the original on May 9, 2013. Retrieved January 9, 2014.
  6. ^ a b "AP Removes Hyphen From 'Email' In Style Guide". Huffington Post. New York City. March 18, 2011. Archived from the original on May 12, 2015.
  7. ^ "RFC Editor Terms List". IETF. Archived from the original on December 28, 2013. 이는 RFC Document Style Guide Archived 2015-04-24 at the Wayback Machine에서 권장되고 있습니다.
  8. ^ AskOxford Language Query team. "What is the correct way to spell 'e' words such as 'email', 'ecommerce', 'egovernment'?". FAQ. Oxford University Press. Archived from the original on July 1, 2008. Retrieved September 4, 2009. We recommend email, this is the common form
  9. ^ "Reference.com". Dictionary.reference.com. Archived from the original on December 16, 2013. Retrieved January 9, 2014.
  10. ^ Random House Unbracked Dictionary, 2006년
  11. ^ 미국유산영어사전 제4판
  12. ^ 프린스턴 대학교 WordNet 3.0
  13. ^ 아메리칸 헤리티지 사이언스
  14. ^ "Merriam-Webster Dictionary". Merriam-Webster. Archived from the original on May 12, 2014. Retrieved May 9, 2014.
  15. ^ ""RFC Style Guide", Table of decisions on consistent use in RFC". Archived from the original on December 28, 2013. Retrieved January 9, 2014.
  16. ^ ""Email" or "e-mail"". English Language & Usage – Stack Exchange. August 25, 2010. Archived from the original on August 31, 2010. Retrieved September 26, 2010.
  17. ^ Gerri Berendzen; Daniel Hunt. "AP changes e-mail to email". 15th National Conference of the American Copy Editors Society (2011, Phoenix). ACES. Archived from the original on March 22, 2011. Retrieved March 23, 2011.
  18. ^ "Excerpt from the FAQ list of the Usenet newsgroup alt.usage.english". Alt-usage-english.org. Archived from the original on April 3, 2012. Retrieved January 9, 2014.
  19. ^ "Did V.A. Shiva Ayyadurai Invent Email? SIGCIS". www.sigcis.org. Retrieved September 5, 2020.
  20. ^ Wed, May 22nd 2019 10:35am-Mike Masnick (May 22, 2019). "Laying Out All The Evidence: Shiva Ayyadurai Did Not Invent Email". Techdirt. Retrieved September 5, 2020.
  21. ^ Pexton, Patrick B. (March 1, 2012). "Origins of e-mail: My mea culpa". Washington Post. Retrieved April 18, 2022.
  22. ^ "Mail Objects". Simple Mail Transfer Protocol. IETF. sec. 2.3.1. doi:10.17487/RFC5321. RFC 5321. SMTP transports a mail object. A mail object contains an envelope and content.
  23. ^ "Mail Objects". Simple Mail Transfer Protocol. IETF. sec. 2.3.1. doi:10.17487/RFC5321. RFC 5321. The SMTP content is sent in the SMTP DATA protocol unit, and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section is a collection of header fields, each consisting of a header name, a colon, and data, structured as in the message format specification
  24. ^ Tom Van Vleck. "The History of Electronic Mail".
  25. ^ Ray Tomlinson. "The First Network Email". Openmap.bbn.com. Archived from the original on May 6, 2006. Retrieved October 5, 2019.
  26. ^ Gardner, P. C. (1981). "A system for the automated office environment". IBM Systems Journal. 20 (3): 321–345. doi:10.1147/sj.203.0321. ISSN 0018-8670; "IBM100 - The Networked Business Place". IBM. August 2, 2020. Archived from the original on August 2, 2020. Retrieved September 7, 2020.
  27. ^ Connie Winkler (October 22, 1979). "CompuServe pins hopes on MicroNET, InfoPlex". Computerworld. Vol. 13, no. 42. p. 69; Dylan Tweney (September 24, 1979). "Sept. 24, 1979: First Online Service for Consumers Debuts". Wired.
  28. ^ Ollig, Mark (October 31, 2011). "They could have owned the computer industry". Herald Journal. Retrieved February 26, 2021;;
  29. ^ "ALL-IN-1". DIGITAL Computing Timeline. January 30, 1998.
  30. ^ "HP Computer Museum".
  31. ^ NSFNET Backbone Service 재설치: 시대 종말의 연대기" 2016년 1월 1일 Wayback Machine, Susan R에서 아카이브.Harris, Ph.D. 및 Elise Gerich, ConneXions, Vol.10, No.4, 1996년 4월
  32. ^ Leiner, Barry M.; Cerf, Vinton G.; Clark, David D.; Kahn, Robert E.; Kleinrock, Leonard; Lynch, Daniel C.; Postel, Jon; Roberts, Larry G.; Wolf, Stephen (1999). "A Brief History of the Internet". arXiv:cs/9901011. Bibcode:1999cs........1011L. Archived from the original on August 11, 2015. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  33. ^ How E-mail Works. howstuffworks.com. 2008. Archived from the original on June 11, 2017.
  34. ^ 'MX 레코드 설명' 2015-01-17 Wayback Machine에 보관 it.cornell.edu
  35. ^ "What is open relay?". WhatIs.com. Indiana University. July 19, 2004. Archived from the original on August 24, 2007. Retrieved April 7, 2008.
  36. ^ Ch Seetha Ram (2010). Information Technology for Management. Deep & Deep Publications. p. 164. ISBN 978-81-8450-267-1.
  37. ^ Hoffman, Paul (August 20, 2002). "Allowing Relaying in SMTP: A Series of Surveys". IMC Reports. Internet Mail Consortium. Archived from the original on January 18, 2007. Retrieved April 13, 2008.
  38. ^ 인터넷 메시지 형식은 네트워크 뉴스에도 사용됩니다.
  39. ^ Simpson, Ken (October 3, 2008). "An update to the email standards". MailChannels Blog Entry. Archived from the original on October 6, 2008.
  40. ^ J. Klensin (October 2008), "Mail Objects", Simple Mail Transfer Protocol, sec. 2.3.1., doi:10.17487/RFC5321, RFC 5321, SMTP transports a mail object. A mail object contains an envelope and content. ... The SMTP content is sent in the SMTP DATA protocol unit, and has two parts: the header section and the body.
  41. ^ D. Crocker (July 2009), "Message Data", Internet Mail Architecture, sec. 4.1., doi:10.17487/RFC5598, RFC 5598, A message comprises a transit-handling envelope and the message content. The envelope contains information used by the MHS. The content is divided into a structured header and the body.
  42. ^ P. Resnick, Ed. (October 2008). "RFC 5322, Internet Message Format". IETF. Archived from the original on February 22, 2015.
  43. ^ Moore, K (November 1996). "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text". IETF. Archived from the original on January 14, 2012. Retrieved January 21, 2012.
  44. ^ A Yang, Ed. (February 2012). "RFC 6532, Internationalized Email Headers". Ietf Request for Comments (RFC) Pages - Test. IETF. ISSN 2070-1721. Archived from the original on February 18, 2015.
  45. ^ J. Yao, Ed., W. Mao, Ed. (February 2012). "RFC 6531, SMTP Extension for Internationalized Email Addresses". Ietf Request for Comments (RFC) Pages - Test. IETF. ISSN 2070-1721. Archived from the original on February 18, 2015.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  46. ^ "Now, get your email address in Hindi - The Economic Times". The Economic Times. Archived from the original on August 28, 2016. Retrieved October 17, 2016.
  47. ^ Resnick, Pete (October 2008). "RFC 5322, 3.6. Field Definitions". Tools.ietf.org. Archived from the original on December 30, 2013. Retrieved January 9, 2014.
  48. ^ Resnick, Pete (October 2008). "RFC 5322, 3.6.4. Identification Fields". Tools.ietf.org. Archived from the original on December 30, 2013. Retrieved January 9, 2014.
  49. ^ Dürst, Martin J. (December 2007). "RFC 5064". Tools.ietf.org. Archived from the original on July 25, 2014. Retrieved January 9, 2014.
  50. ^ Microsoft, Auto Response Suppress, 2010, Microsoft 레퍼런스 2011-04-07 at the Wayback Machine, 2010년 9월 22일
  51. ^ John Klensin (October 2008). "Trace Information". Simple Mail Transfer Protocol. IETF. sec. 4.4. doi:10.17487/RFC5321. RFC 5321.
  52. ^ John Levine (January 14, 2012). "Trace headers". email message. IETF. Archived from the original on August 11, 2012. Retrieved January 16, 2012. there are many more trace fields than those two
  53. ^ 이 확장 가능한 필드는 RFC 7001에서 정의되어 있습니다.이 필드에서는 Email Authentication ParametersIANA 레지스트리도 정의되어 있습니다.
  54. ^ RFC 7208.
  55. ^ "RFC6376". Retrieved January 28, 2020.
  56. ^ RFC 3834에 정의되어 있으며 RFC 5436에 의해 갱신되었습니다.
  57. ^ RFC 5518
  58. ^ Craig Hunt (2002). TCP/IP Network Administration. O'Reilly Media. p. 70. ISBN 978-0-596-00297-8.
  59. ^ "What is unicode? Konfinity". www.konfinity.com. Retrieved January 31, 2022.
  60. ^ "Email policies that prevent viruses". Archived from the original on May 12, 2007.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  61. ^ "When posting to a RootsWeb mailing list..." Helpdesk.rootsweb.com. Archived from the original on February 19, 2014. Retrieved January 9, 2014.
  62. ^ "...Plain text, 72 characters per line..." Openbsd.org. Archived from the original on February 8, 2014. Retrieved January 9, 2014.
  63. ^ "How to Prevent the Winmail.dat File from Being Sent to Internet Users". Support.microsoft.com. July 2, 2010. Archived from the original on January 9, 2014. Retrieved January 9, 2014.
  64. ^ 실제로 현재 일부 수신된 메시지는 수신인의 InBox로 전달되지 않고 스팸 또는 정크 폴더로 전달될 수 있습니다.이 폴더는 특히 기업 환경에서 수신인이 접근할 수 없는 경우가 있습니다.
  65. ^ "View only unread messages". support.microsoft.com.
  66. ^ "Free Email Providers in the Yahoo! Directory". dir.yahoo.com. Archived from the original on July 4, 2014.
  67. ^ RFC 2368 섹션 3: 1998년 Paul Hoffman에 의해 "mailto" URL 조작에 대해 설명합니다.
  68. ^ a b Hansen, Derek; Smith, Marc A.; Heer, Jeffrey (2011). "E-Mail". In Barnett, George A (ed.). Encyclopedia of social networks. Thousand Oaks, Calif: Sage. p. 245. ISBN 9781412994170. OCLC 959670912.
  69. ^ "Creating hyperlinks § E-mail links". MDN Web Docs. Retrieved September 30, 2019.
  70. ^ Allen, David (2004). Windows to Linux. Prentice Hall. p. 192. ISBN 978-1423902454. Archived from the original on December 26, 2016.
  71. ^ "Implementation and Operation". DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4. sec. 4.5. doi:10.17487/RFC1733. RFC 1733.
  72. ^ "Message Store (MS)". Internet Mail Architecture. sec. 4.2.2. doi:10.17487/RFC5598. RFC 5598.
  73. ^ 엄말릭, 기가옴.이메일은 저주입니까, 아니면 혜택입니까?2010-12-04년에 Wayback Machine에서 아카이브" 2010년 9월 22일.2010년 10월 11일 취득.
  74. ^ Martin, Brett A. S.; Van Durme, Joel; Raulas, Mika; Merisavo, Marko (2003). "E-mail Marketing: Exploratory Insights from Finland" (PDF). Journal of Advertising Research. 43 (3): 293–300. doi:10.1017/s0021849903030265. Archived (PDF) from the original on October 21, 2012.
  75. ^ Lev, Amir (October 2, 2009). "Spam culture, part 1: China". Archived from the original on November 10, 2016.
  76. ^ "Email Is Top Activity On Smartphones, Ahead Of Web Browsing & Facebook [Study]". March 28, 2013. Archived from the original on April 29, 2014.
  77. ^ "The ultimate mobile email statistics overview". Archived from the original on July 11, 2014.
  78. ^ Richtel, Matt (December 20, 2010). "E-Mail Gets an Instant Makeover". The New York Times. Retrieved April 4, 2018.
  79. ^ Gustini, Ray (December 21, 2010). "Why Are Young People Abandoning Email?". The Atlantic. Retrieved April 4, 2018.
  80. ^ Perez, Sarah (March 24, 2016). "Email is dying among mobile's youngest users". techcrunch.com. Retrieved April 4, 2018.
  81. ^ "Exchange 2010Exchange 2007 메시지 크기 제한 설정" 2013-02-12를 웨이백 머신에 아카이브했습니다.
  82. ^ "Google은 Gmail 및 YouTube의 파일 크기 제한을 업데이트합니다", geek.com Wayback Machine에서 2011-12-19로 보관되었습니다.
  83. ^ "최대 첨부 파일 크기", mail.google.com.
  84. ^ Walther, Henrik (January 2009). "Mysterious Attachment Size Increases, Replicating Public Folders, and More". Exchange Queue & A. TechNet Magazine. Retrieved November 7, 2021 – via Microsoft Docs. {{cite magazine}}:외부 링크 department=(도움말)
  85. ^ "다른 사람에게 대용량 파일 보내기" 2016-08-07년 Wayback Machine, Microsoft.com에 보관
  86. ^ "대용량 첨부 파일을 이메일로 보내는 8가지 방법" 2016-07-02년 Wayback Machine, Chris Hoffman, 2012년 12월 21일 makeuseof.com에서 아카이브
  87. ^ Radicati, Sara. "Email Statistics Report, 2010" (PDF). Archived (PDF) from the original on September 1, 2011.
  88. ^ Gross, Doug (October 20, 2010). "Happy Information Overload Day!". CNN. Archived from the original on October 23, 2015. Retrieved March 24, 2019.
  89. ^ Stross, Randall (April 20, 2008). "Struggling to Evade the E-Mail Tsunami". The New York Times. Archived from the original on April 17, 2009. Retrieved May 1, 2010.
  90. ^ "Seeing Spam? How To Take Care of Your Google Analytics Data". sitepronews.com. May 4, 2015. Archived from the original on November 7, 2017. Retrieved September 5, 2017.
  91. ^ 부자 카와나.2005년의 상위 10개의 이메일 스팸 리스트.ITVibe 뉴스, 2006년 1월 2일, ITvibe.com Wayback Machine에서 2008-07-20 아카이브 완료
  92. ^ Microsoft가 스팸과의 전쟁에서 지고 있는 방법 Salon.com Wayback Machine 2008-06-29 아카이브
  93. ^ 스팸 청구서 2003 (PDF 2006-09-11년 웨이백 머신에서 아카이브 완료)
  94. ^ "Google, 자사의 AI가 Gmail 스팸의 99.9%를 포착했다" 2015년 7월 9일 Cade Metz의 Wayback Machine에서 2016-09-16년 아카이브 완료, wired.com
  95. ^ "2016년 1분기 스팸 피싱" 2016-08-09년 5월 12일 Wayback Machine에 보관됨, securelist.com
  96. ^ "Kaspersky Lab Spam and Phishing report". May 26, 2021.
  97. ^ "2021 Email Usage Statistics". October 5, 2021.
  98. ^ SMEmail 모바일 환경의 안전한 전자 메일을 위한 새로운 프로토콜, 호주 전기통신 네트워크 및 애플리케이션 회의(ATNAC'08) 진행, 페이지 39-44, 호주 애들레이드, 2008년 12월.
  99. ^ "When Email Exchanges Become Binding Contracts". law.com.
  100. ^ Catarina, Jessica; Feitel, Jesse (2019). "Inadvertent Contract Formation via Email under New York Law: An Update". Syracuse Law Review. 69.
  101. ^ Corfield, Gareth. "UK court ruling says email signature blocks can sign binding contracts". The Register. Retrieved December 6, 2019.
  102. ^ S. Kiesler; D. Zubrow; A.M. Moses; V. Geller (1985). "Affect in computer-mediated communication: an experiment in synchronous terminal-to-terminal discussion". Human-Computer Interaction. 1: 77–104. doi:10.1207/s15327051hci0101_3.
  103. ^ Barrett, Grant (December 23, 2007). "All We Are Saying". The New York Times. Archived from the original on April 17, 2009. Retrieved December 24, 2007.
  104. ^ "Internationalized Domain Names (IDNs) Registry.In". registry.in. Archived from the original on May 13, 2016. Retrieved October 17, 2016.
  105. ^ "Made In India 'Datamail' Empowers Russia With Email Address In Russian Language - Digital Conqueror". December 7, 2016. Archived from the original on March 5, 2017.
  106. ^ RFC 3885, 메시지 추적용 SMTP 서비스 확장
  107. ^ RFC 3888, 메시지트래킹 모델과 요건
  108. ^ Amy Harmon (November 22, 2000). "Software That Tracks E-Mail Is Raising Privacy Concerns". The New York Times. Retrieved January 13, 2012.
  109. ^ "About.com". Email.about.com. December 19, 2013. Archived from the original on August 27, 2016. Retrieved January 9, 2014.
  110. ^ 「외관: Web Bugs & Blocked HTML Images' 2015-02-18 Wayback Machine slipstick.com에서 아카이브 완료
  111. ^ 이메일은 이메일 마케팅을 망칩니다.." 2017-06-07 Wayback Machine, Ron Amadeo, 2013년 12월 13일 Ars Technica에서 보관

추가 정보

외부 링크