전자우편

이 스크린샷은 이메일 클라이언트의 "받은 편지함" 페이지를 보여준다. 사용자들은 새 이메일을 확인하고, 읽기, 삭제, 저장, 답장 등의 작업을 수행할 수 있다.
위키백과의 "로봇"이 이미지 파일을 변경하면 업로더는 변경 사항에 대한 이메일을 받는다.

전자우편(한국 한자: 電子郵便) 혹은 이메일(영어: e-mail)은 컴퓨터 망을 통해 전자 장치를 사용하여 디지털 메시지를 전송하고 수신하는 방법이다. 20세기 후반에 우편의 디지털 버전 또는 대응물로 고안되었다(따라서 e- + mail). 이메일은 유비쿼터스적이고 매우 널리 사용되는 통신 매체이다. 현재 사용에서 전자우편 주소(일반적으로 local-part + 골뱅이표 + 도메인 네임)는 대부분의 국가에서 비즈니스, 상업, 정부, 교육, 엔터테인먼트 및 기타 일상생활 영역에서 많은 과정의 기본적이고 필수적인 부분으로 간주된다.

이메일은 주로 인터넷과 근거리 통신망과 같은 컴퓨터 네트워크에서 작동한다. 오늘날의 이메일 시스템은 저장 후 전달 모델을 기반으로 한다. 이메일 서버는 메시지를 수락, 전달, 배달 및 저장한다. 사용자나 그들의 컴퓨터가 동시에 온라인 상태일 필요는 없으며, 일반적으로 메일 서버 또는 웹 메일 인터페이스에 연결하여 메시지를 보내거나 받거나 다운로드해야 한다.

원래 텍스트 전용 ASCII 통신 매체였던 인터넷 이메일은 MIME에 의해 확장되어 확장된 문자 세트의 텍스트와 이미지와 같은 멀티미디어 콘텐츠를 전송할 수 있게 되었다. 국제 이메일은 UTF-8을 사용하는 국제화된 이메일 주소를 포함하며, 표준화되었지만 널리 채택되지는 않았다.

대한민국 최초의 무료 이메일인 한메일이나 구글의 지메일처럼 해당 서비스에 가입함으로써 인터넷이 연결되면 어디서나 쓸 수 있는 웹 메일, 자신의 컴퓨터에 선택적으로 내려 받을 수 있는 POP3, 간단하게 메일을 보내는 SMTP 방식 등이 주로 쓰인다. PC통신 시절에는 유료로 아이디를 만들어서 전자우편을 사용하곤 했다.

용어

전자우편이라는 용어는 1975년부터 현대적인 의미로 사용되었으며, 더 짧은 이메일의 변형은 1979년부터 사용되었다.

이 서비스는 종종 단순히 메일이라고 불리며, 단일 전자 메일은 메시지라고 불린다. 이메일 내 필드(예: "받는 사람", "보낸 사람", "참조", "숨은 참조" 등)에 대한 관례는 1975년 RFC-680부터 시작되었다.

인터넷 이메일은 봉투와 내용으로 구성된다. 내용은 헤더와 본문으로 구성된다.

역사

동일 시스템 사용자 간의 컴퓨터 기반 메시징은 1960년대 초 시분할 시스템의 등장 이후 가능해졌으며, 1965년 MIT의 CTSS 프로젝트에서 주목할 만한 구현이 있었다. 초기 메인프레임 및 미니컴퓨터 개발자 대부분은 유사하지만 일반적으로 호환되지 않는 메일 응용 프로그램을 개발했다. 1971년 첫 아파넷 네트워크 메일이 전송되었고, 현재 익숙한 @ 기호로 사용자의 시스템 주소를 지정하는 주소 구문이 도입되었다. 일련의 RFC를 통해 파일 전송 프로토콜을 통한 메일 메시지 전송 규칙이 정교화되었다.

독점적인 전자 메일 시스템이 곧 등장하기 시작했다. IBM, 컴퓨서브 및 제록스는 1970년대에 사내 메일 시스템을 사용했으며, 컴퓨서브는 1978년에 IBM에, 1981년부터 제록스에 상업용 사무실 내 메일 제품을 판매했다. DEC의 ALL-IN-1과 휴렛 팩커드의 HPMAIL (이후 HP DeskManager)은 1982년에 출시되었으며, 전자는 1970년대 후반에 개발 작업이 시작되었고 후자는 세계에서 가장 많이 팔린 이메일 시스템이 되었다.

Simple Mail Transfer Protocol (SMTP)은 1983년 아파넷에 구현되었다. LAN 이메일 시스템은 1980년대 중반에 등장했다. 1980년대 후반부터 1990년대 초반까지 한동안 독점 상용 시스템 또는 X.400 이메일 시스템 (GOSIP (Government Open Systems Interconnection Profile)의 일부)이 지배적일 것으로 보였다. 그러나 인터넷을 통한 상업 트래픽 운반에 대한 최종 제한이 1995년에 해제되자, 여러 요인이 결합되어 SMTP, POP3 및 IMAP 이메일 프로토콜의 현재 인터넷 스위트가 표준이 되었다( 프로토콜 전쟁 참조).

작동 방식

다음은 발신자 앨리스가 수신자의 전자우편 주소로 지정된 메일 사용자 에이전트 (MUA)를 사용하여 메시지를 전송할 때 발생하는 일반적인 일련의 이벤트이다.

이메일 작동 방식
  1. MUA는 메시지를 이메일 형식으로 포맷하고 Simple Mail Transfer Protocol (SMTP)의 프로필인 제출 프로토콜을 사용하여 메시지 내용을 로컬 메일 제출 에이전트 (MSA), 이 경우에는 smtp.a.org로 보낸다.
  2. MSA는 SMTP 프로토콜(메시지 헤더가 아닌)에 제공된 대상 주소를 결정한다. 이 경우 bob@b.org는 FQDA (Fully Qualified Domain Address)이다. @ 기호 앞 부분은 주소의 로컬 부분으로, 종종 수신자의 사용자 이름이며, @ 기호 뒤 부분은 도메인 네임이다. MSA는 도메인 네임 시스템 (DNS)에서 메일 서버의 전체 주소 도메인 네임을 결정하기 위해 도메인 네임을 확인한다.
  3. 도메인 b.org (ns.b.org)의 DNS 서버는 해당 도메인의 메일 교환 서버를 나열하는 MX 레코드를 응답하며, 이 경우 수신자의 ISP가 운영하는 메시지 전송 에이전트 (MTA) 서버인 mx.b.org이다.
  4. smtp.a.org는 SMTP를 사용하여 mx.b.org로 메시지를 보낸다. 이 서버는 메시지가 최종 메시지 전달 에이전트 (MDA)에 도달하기 전에 다른 MTA로 메시지를 전달해야 할 수 있다.
  5. MDA는 사용자 밥의 메일함으로 메시지를 전달한다.
  6. 밥의 MUA는 POP3 또는 IMAP을 사용하여 메시지를 가져온다.

이 예 외에도 이메일 시스템에는 대안과 복잡성이 존재한다:

많은 MTA는 한때 인터넷 상의 모든 수신자에게 메시지를 수락하고 최선을 다해 전달했다. 이러한 MTA를 오픈 메일 릴레이라고 불렀다. 이것은 네트워크 연결이 불안정했던 인터넷 초기에 매우 중요했다. 그러나 이 메커니즘은 원치 않는 대량 이메일 발신자에게 악용될 수 있음이 입증되었고, 그 결과 오픈 메일 릴레이는 드물게 되었으며, 많은 MTA는 오픈 메일 릴레이로부터 메시지를 수락하지 않는다.

이메일은 인스턴트 메신저보다 앞서며, 신뢰할 수 없는 네트워크 링크와 바쁜 서버(인터넷 초기에 더 흔했음)에 대처하기 위해 속도보다 신뢰성을 선호한다. 느린 배송의 이유는 다음과 같다.

메일은 발신자에게 영구적인 배달 실패를 알리기 전까지 최대 5일 동안 대기열에 저장되어 재시도될 수 있다. 메시지는 각 서버를 통과할 때 타임스탬프가 찍히므로 느린 배달을 진단할 수 있지만, 시간대와 부정확하게 설정된 컴퓨터 시계로 인해 분석이 복잡하다.

스팸 필터에 의해 스팸으로 분류된 이메일 메시지는 수신자가 수동으로 확인해야 하는 별도의 폴더로 분류되거나 완전히 삭제될 수 있다.

메시지 형식

이메일에 사용되는 기본 인터넷 메시지 형식은 RFC 5322에 의해 정의되며, 비-ASCII 데이터 및 멀티미디어 콘텐츠 첨부 파일의 인코딩은 RFC 2045부터 RFC 2049까지, 총칭하여 Multipurpose Internet Mail Extensions 또는 MIME으로 정의된다. 국제 이메일의 확장 기능은 이메일에만 적용된다. RFC 5322는 2008년에 RFC 2822를 대체했다. 이전에 2001년에 RFC 2822는 수십 년 동안 인터넷 이메일 표준이었던 RFC 822를 대체했다. 1982년에 발표된 RFC 822는 초기 아파넷용 RFC 733을 기반으로 했다.

인터넷 이메일 메시지는 "헤더"와 "본문"의 두 부분으로 구성된다. 이를 "콘텐츠"라고 부른다. 헤더는 From, To, CC, Subject, Date 및 이메일에 대한 기타 정보와 같은 필드로 구성된다. 시스템 간에 이메일 메시지를 전송하는 과정에서 SMTP는 메시지 헤더 필드를 사용하여 전송 매개변수 및 정보를 통신한다. 본문은 메시지를 비구조화된 텍스트로 포함하며, 때로는 끝에 서명 블록이 포함될 수 있다. 헤더는 빈 줄로 본문과 구분된다.

메시지 헤더

RFC 5322는 이메일 헤더의 구문을 지정한다. 각 이메일 메시지는 여러 필드(사양에 따르면 메시지의 "헤더 섹션")로 구성된 헤더를 가진다. 각 필드는 이름("필드 이름" 또는 "헤더 필드 이름")과 구분자 문자 ":"가 뒤따르고 값("필드 본문" 또는 "헤더 필드 본문")을 가진다.

각 필드 이름은 헤더 섹션의 새 줄 첫 문자에서 시작하며 비공백 인쇄 가능한 문자로 시작한다. 구분자 문자 ":"로 끝난다. 구분자 뒤에는 필드 값("필드 본문")이 온다. 이 값은 해당 줄의 첫 문자가 공백이나 탭인 경우 다음 줄로 계속될 수 있다. 필드 이름은 SMTPUTF8이 없는 경우 필드 본문과 함께 7비트 ASCII 문자로 제한된다. 일부 비-ASCII 값은 MIME 인코딩된 단어를 사용하여 표현될 수 있다.

헤더 필드

이메일 헤더 필드는 여러 줄로 구성될 수 있으며, 각 줄은 78자를 넘지 않도록 권장되지만 제한은 998자이다. RFC 5322에서 정의된 헤더 필드에는 US-ASCII 문자만 포함된다. 다른 세트의 문자를 인코딩하기 위해 RFC 2047에 지정된 구문을 사용할 수 있다. 일부 예시에서 IETF EAI 워킹 그룹은 이전 실험적 확장을 대체하는 일부 표준 트랙 확장을 정의하므로 UTF-8로 인코딩된 유니코드 문자를 헤더 내에서 사용할 수 있다. 특히, 이는 이메일 주소가 비-ASCII 문자를 사용할 수 있도록 허용한다. 이러한 주소는 구글 및 마이크로소프트 제품에서 지원되며 일부 정부 기관에서 홍보한다.

메시지 헤더에는 최소한 다음 필드가 포함되어야 한다.

  • From: 발신자의 이메일 주소 및 선택적으로 이름. 일부 이메일 클라이언트는 계정 설정을 통해 변경 가능하다.
  • Date: 메시지가 작성된 현지 시간 및 날짜. From: 필드와 마찬가지로, 많은 이메일 클라이언트가 전송 전에 이 정보를 자동으로 채운다. 수신자의 클라이언트는 시간을 현지 형식과 시간대로 표시할 수 있다.

RFC 3864는 Internet Assigned Numbers Authority에 메시지 헤더 필드 등록 절차를 설명한다. MIME, 유즈넷 및 HTTP에 정의된 필드를 포함하고 관련 RFC를 참조하여 영구 및 임시 필드 이름을 제공한다. 이메일에 대한 일반적인 헤더 필드는 다음과 같다.

  • To: 메시지 수신자(들)의 이메일 주소(들) 및 선택적으로 이름(들). 주 수신자(복수 허용)를 나타내며, 보조 수신자의 경우 Cc: 및 Bcc:를 참조하십시오.
  • Subject: 메시지 주제에 대한 간략한 요약. 특정 약어는 제목에 일반적으로 사용되며, "RE:" 및 "FW:"를 포함한다.
  • Cc: 먹지 사본; 많은 이메일 클라이언트는 받은 편지함에 있는 이메일을 To: 또는 Cc: 목록에 있는지 여부에 따라 다르게 표시한다.
  • Bcc: 숨은 참조; 주소는 일반적으로 SMTP 전달 중에만 지정되며, 메시지 헤더에는 일반적으로 나열되지 않는다.
  • 콘텐츠 유형: 메시지가 어떻게 표시되어야 하는지에 대한 정보, 일반적으로 MIME 유형이다.
  • Precedence: 일반적으로 "bulk", "junk", "list" 값을 가지며, 자동 "휴가" 또는 "부재중" 응답이 이 메일에 대해 반환되지 않아야 함을 나타내는 데 사용된다. 예를 들어, 메일링 리스트의 다른 모든 구독자에게 휴가 알림이 전송되는 것을 방지한다. Sendmail은 이 필드를 사용하여 대기 중인 이메일의 우선순위에 영향을 미치며, "Precedence: special-delivery" 메시지는 더 빨리 전달된다. 현대의 고대역폭 네트워크에서는 전달 우선순위가 이전보다 덜 중요하다. Microsoft Exchange는 세밀한 자동 응답 억제 메커니즘인 X-Auto-Response-Suppress 필드를 따른다.
  • 메시지 ID: 여러 번의 전달을 방지하고 In-Reply-To: (아래 참조)에서 참조하기 위한 자동 생성 필드.
  • In-Reply-To: 이 메시지가 답장하는 메시지의 Message-ID. 관련 메시지를 함께 연결하는 데 사용된다. 이 필드는 답장 메시지에만 적용된다.
  • List-Unsubscribe: 메일링 리스트에서 구독을 취소하기 위한 HTTP 링크.
  • References: 이 메시지가 답장하는 메시지의 Message-ID와 이전 답장이 답장하는 메시지의 Message-ID 등.
  • Reply-To: 메시지에 답장하는 데 사용해야 할 주소.
  • Sender: From: 필드에 나열된 작성자를 대신하여 (비서, 목록 관리자 등) 발신자의 주소.
  • Archived-At: 개별 이메일 메시지의 보관된 형태로의 직접 링크.

To: 필드는 메시지가 전달되는 주소와 관련이 없을 수 있다. 배달 목록은 전송 프로토콜인 SMTP에 별도로 제공되며, 이는 헤더 내용에서 추출될 수 있다. "To:" 필드는 외부 봉투의 주소에 따라 배달되는 일반적인 편지의 상단 주소 지정과 유사하다. 마찬가지로 "From:" 필드는 발신자가 아닐 수 있다. 일부 메일 서버는 릴레이된 메시지에 전자우편 인증 시스템을 적용한다. 서버 활동과 관련된 데이터도 아래에 정의된 대로 헤더의 일부이다.

SMTP는 다음 두 필드를 사용하여 헤더에 저장된 메시지의 추적 정보를 정의한다.

  • Received: SMTP 서버가 메시지를 수락한 후, 이 추적 레코드를 헤더 상단에 삽입한다(가장 나중에 온 것이 가장 먼저 온다).
  • Return-Path: 전달 SMTP 서버가 메시지를 최종적으로 전달한 후, 이 필드를 헤더 상단에 삽입한다.

수신 서버에 의해 헤더 상단에 추가되는 다른 필드는 추적 필드라고 불릴 수 있다.

  • Authentication-Results: 서버가 인증을 확인한 후, 이 필드에 결과를 저장하여 다운스트림 에이전트가 사용할 수 있도록 할 수 있다.
  • Received-SPF: SPF 확인 결과를 Authentication-Results보다 더 자세히 저장한다.
  • DKIM-Signature: 메시지가 전송된 후 변경되지 않았음을 확인하기 위해 DomainKeys Identified Mail (DKIM) 해독 결과를 저장한다.
  • Auto-Submitted: 자동 생성된 메시지를 표시하는 데 사용된다.
  • VBR-Info: VBR 화이트리스트를 주장한다.

메시지 본문

콘텐츠 인코딩

인터넷 이메일은 7비트 ASCII용으로 설계되었다. 대부분의 이메일 소프트웨어는 8비트 클린하지만, 7비트 서버 및 메일 리더와 통신할 것이라고 가정해야 한다. MIME 표준은 문자 세트 지정자와 두 가지 콘텐츠 전송 인코딩을 도입하여 비 ASCII 데이터 전송을 가능하게 했다. Quoted-printable은 주로 7비트 콘텐츠에 범위 밖의 몇 문자가 있는 경우에 사용되며, 베이스64는 임의의 이진 데이터에 사용된다. 8BITMIME 및 BINARY 확장은 이러한 인코딩 없이 메일 전송을 허용하기 위해 도입되었지만, 많은 메일 전송 에이전트는 이를 지원하지 않을 수 있다. 일부 국가에서는 이메일 소프트웨어가 RFC 5322를 위반하여 원시 비 ASCII 텍스트를 전송하며 여러 인코딩 체계가 공존한다. 결과적으로 기본적으로 비 라틴어 알파벳 언어의 메시지는 읽을 수 없는 형태로 나타난다(유일한 예외는 발신자와 수신자가 동일한 인코딩 체계를 사용하는 경우의 우연이다). 따라서 국제 문자 집합의 경우 유니코드의 인기가 높아지고 있다.

플레인 텍스트와 HTML

대부분의 현대 그래픽 이메일 클라이언트는 사용자의 선택에 따라 메시지 본문에 플레인 텍스트 또는 HTML을 사용할 수 있도록 허용한다. HTML 이메일 메시지는 종종 호환성을 위해 자동으로 생성된 플레인 텍스트 복사본을 포함한다.

HTML의 장점은 인라인 링크 및 이미지를 포함하고, 블록 인용으로 이전 메시지를 구분하고, 모든 디스플레이에서 자연스럽게 줄 바꿈하고, 밑줄 및 이탤릭체와 같은 강조를 사용하고, 글꼴 스타일을 변경할 수 있다는 점이다. 단점은 이메일 크기 증가, 웹 버그에 대한 개인 정보 보호 문제, 피싱 공격 및 악성 소프트웨어 확산을 위한 벡터로서 HTML 이메일의 남용 등이 있다. 일부 이메일 클라이언트는 `Content-Type: html` 헤더 필드가 없는 경우에도 본문을 HTML로 해석하며, 이로 인해 다양한 문제가 발생할 수 있다.

일부 웹 기반 메일링 리스트는 위에 언급된 모든 이유로 모든 게시물을 문자당 72자 또는 80자로 된 플레인 텍스트로 작성할 것을 권장하며, Mutt와 같은 텍스트 기반 이메일 클라이언트를 사용하는 상당수의 독자가 있기 때문이기도 하다. 이메일 및 유즈넷 게시물에서 플레인 텍스트를 마크업하기 위한 다양한 비공식 관례가 발전했으며, 이는 나중에 setext (c. 1992) 및 기타 여러 언어와 같은 공식 언어의 개발로 이어졌고, 그 중 가장 인기 있는 것은 마크다운이다.

일부 마이크로소프트 이메일 클라이언트는 독점적인 Rich Text Format (RTF)을 사용하여 풍부한 서식 지정을 허용할 수 있지만, 수신자가 호환되는 이메일 클라이언트를 가지고 있다는 보장이 없는 한 이는 피해야 한다.

서버 및 클라이언트 애플리케이션

썬더버드 이메일 클라이언트의 인터페이스

메시지는 메일 전송 에이전트 (MTA)라고 불리는 소프트웨어 프로그램을 사용하여 Simple Mail Transfer Protocol을 통해 호스트 간에 교환되며, 메일 전달 에이전트 (MDA, 때로는 로컬 전달 에이전트, LDA라고도 함)라고 불리는 프로그램에 의해 메일 저장소로 전달된다. 메시지를 수락하는 것은 MTA가 메시지를 전달해야 할 의무를 지게 하며, 메시지를 전달할 수 없는 경우 해당 MTA는 문제점을 나타내는 반송 메시지를 발신자에게 다시 보내야 한다.

사용자는 POP 또는 IMAP과 같은 표준 프로토콜을 사용하거나, 대규모 기업 환경에서는 노벨 그룹와이즈, 로터스 노트 또는 마이크로소프트 익스체인지 서버와 같은 독점 프로토콜을 사용하여 서버에서 메시지를 검색할 수 있다. 사용자가 이메일을 검색, 읽기 및 관리하는 데 사용하는 프로그램을 메일 사용자 에이전트 (MUA)라고 한다.

이메일을 열면 "읽음"으로 표시되며, 이는 일반적으로 클라이언트의 사용자 인터페이스에서 "읽지 않음" 메시지와 시각적으로 구분된다. 이메일 클라이언트는 읽은 이메일을 받은 편지함에서 숨겨 사용자가 읽지 않은 이메일에 집중할 수 있도록 할 수 있다.

메일은 클라이언트, 서버 측 또는 양쪽에 저장될 수 있다. 사서함의 표준 형식에는 Maildir 및 mbox가 있다. 몇몇 주요 이메일 클라이언트는 자체 독점 형식을 사용하며, 이메일을 클라이언트 간에 전송하려면 변환 소프트웨어가 필요하다. 서버 측 저장소는 종종 독점 형식이지만, IMAP와 같은 표준 프로토콜을 통해 접근이 가능하므로, 이메일을 한 서버에서 다른 서버로 이동하는 것은 프로토콜을 지원하는 모든 MUA로 수행할 수 있다.

많은 현재 이메일 사용자들은 MTA, MDA 또는 MUA 프로그램을 직접 실행하지 않고, Gmail 또는 Yahoo! Mail과 같은 웹 기반 이메일 플랫폼을 사용하여 동일한 작업을 수행한다. 이러한 웹 메일 인터페이스를 통해 사용자들은 로컬 이메일 클라이언트에 의존하는 대신, 어떤 표준 웹 브라우저로든 어떤 컴퓨터에서든 자신의 메일에 접근할 수 있다.

파일 확장자

이메일 메시지를 수신하면 이메일 클라이언트 응용 프로그램은 파일 시스템의 운영 체제 파일에 메시지를 저장한다. 일부 클라이언트는 개별 메시지를 별도의 파일로 저장하는 반면, 다른 클라이언트는 집단 저장을 위해 다양한 데이터베이스 형식(종종 독점 형식)을 사용한다. mbox 형식은 역사적인 저장 표준이다. 사용되는 특정 형식은 종종 특별한 파일 확장자로 표시된다:

eml
노벨 그룹와이즈, 마이크로소프트 아웃룩 익스프레스, Lotus notes, 윈도우 메일, 모질라 선더버드, 그리고 Postbox를 포함한 많은 이메일 클라이언트에서 사용된다. 이 파일들은 이메일 헤더와 본문을 포함하는 MIME 형식의 플레인 텍스트로 이메일 내용을 포함하며, 여러 형식 중 하나 이상의 첨부 파일을 포함한다.
emlx
Apple Mail에서 사용된다.
msg
마이크로소프트 오피스 아웃룩 및 OfficeLogic Groupware에서 사용된다.
mbx
오페라 메일, KMail, 그리고 mbox 형식을 기반으로 한 Apple Mail에서 사용된다.

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

URI 스킴 mailto

IANA에 등록된 URI 스킴은 SMTP 전자우편 주소에 대한 mailto: 스킴을 정의한다. 비록 사용이 엄격하게 정의되어 있지는 않지만, 이 형식의 URL은 URL이 활성화될 때 사용자의 메일 클라이언트의 새 메시지 창을 열고, To: 필드에 URL에 정의된 주소를 채우도록 의도되었다. 많은 클라이언트는 제목 줄이나 참조 수신자와 같은 다른 이메일 필드에 대한 쿼리 문자열 매개변수도 지원한다.

유형

웹 기반 이메일

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

POP3 이메일 서버

포스트 오피스 프로토콜 3 (POP3)은 클라이언트 응용 프로그램이 메일 서버에서 메시지를 읽는 데 사용하는 메일 액세스 프로토콜이다. 수신된 메시지는 종종 서버에서 삭제된다. POP는 원격 사서함(POP RFC에서 메일드롭이라고 함)에 액세스하기 위한 간단한 다운로드-및-삭제 요구 사항을 지원한다. POP3는 로컬 컴퓨터에 메시지를 다운로드하여 오프라인 상태에서도 읽을 수 있도록 한다.

IMAP 이메일 서버

인터넷 메시지 접속 프로토콜 (IMAP)은 여러 장치에서 사서함을 관리하는 기능을 제공한다. 스마트폰과 같은 소형 휴대용 장치는 여행 중에 이메일을 확인하고 짧은 답장을 하는 데 점점 더 많이 사용되며, 더 나은 키보드 액세스가 가능한 대형 장치는 더 긴 답장을 하는 데 사용된다. IMAP은 메시지의 헤더, 발신자 및 제목을 보여주며, 장치는 특정 메시지를 다운로드하도록 요청해야 한다. 일반적으로 메일은 메일 서버의 폴더에 남겨진다.

MAPI 이메일 서버

메시징 응용 프로그래밍 인터페이스 (MAPI)는 마이크로소프트 아웃룩이 마이크로소프트 익스체인지 서버와 통신하는 데 사용되며, 악시겐 메일 서버, 케리오 커넥트, 스칼릭스, Zimbra, HP OpenMail, IBM Lotus Notes, Zarafa, Bynari와 같은 다양한 다른 이메일 서버 제품과 통신하는 데도 사용된다. 이러한 제품 공급업체는 아웃룩을 통해 직접 액세스할 수 있도록 MAPI 지원을 추가했다.

용도

비즈니스 및 조직 사용

이메일은 선진국의 기업, 정부 및 비정부 조직에 의해 널리 채택되었으며, 직장 통신에서 '전자 혁명'의 핵심 부분 중 하나이다(다른 핵심 부분은 고속 인터넷의 광범위한 채택). 2010년 직장 통신에 대한 후원 연구에 따르면 미국 지식 근로자의 83%가 이메일이 업무 성공 및 생산성에 매우 중요하다고 느꼈다.

이는 비즈니스 및 기타 조직에 다음과 같은 주요 이점을 제공한다.

물류 촉진
비즈니스 세계의 많은 부분은 물리적으로 같은 건물, 지역, 심지어 국가에 있지 않은 사람들 간의 의사소통에 의존한다. 직접 회의, 전화 통화 또는 콘퍼런스 콜을 설정하고 참석하는 것은 불편하고, 시간이 많이 걸리며, 비용이 많이 들 수 있다. 이메일은 설정 비용 없이 두 명 이상의 사람 간에 정보를 교환하는 방법을 제공하며, 일반적으로 물리적 회의나 전화 통화보다 훨씬 저렴하다.
동기화 지원
회의나 전화 통화와 같은 실시간 통신에서는 참가자들이 같은 일정으로 작업해야 하며, 각 참가자는 회의나 통화에서 같은 시간을 보내야 한다. 이메일은 비동기를 허용한다. 각 참가자는 자신의 일정을 독립적으로 제어할 수 있다. 수신 이메일을 일괄 처리하면 통화 중단에 비해 작업 흐름을 개선할 수 있다.
비용 절감
이메일을 보내는 것은 우편물을 보내는 것, 또는 장거리 전화 통화, 텔렉스 또는 전보보다 훨씬 저렴하다.
속도 증가
대부분의 대안보다 훨씬 빠르다.
"서면" 기록 생성
전화 통화나 직접 대화와 달리 이메일은 본질적으로 통신 내용, 발신자 및 수신자의 신원, 메시지 발송 날짜와 시간에 대한 자세한 서면 기록을 생성한다. 계약 또는 법적 분쟁 발생 시 저장된 이메일은 각 이메일에 날짜와 시간이 기록되어 있으므로 개인이 특정 문제에 대해 조언을 받았음을 입증하는 데 사용될 수 있다.
자동 처리 및 개선된 배포 가능성
고객 주문의 전처리 또는 담당자 지정도 자동화된 절차를 통해 구현할 수 있다.

이메일 마케팅

"옵트인"을 통한 이메일 마케팅은 종종 특별 할인 행사 및 신제품 정보를 보내는 데 성공적으로 사용된다. 수신자의 문화에 따라 허가 없이 보낸 이메일(예: "옵트인" 이메일이 아닌 경우)은 환영받지 못하는 "스팸 메일"로 간주될 가능성이 높다.

개인적인 용도

개인용 컴퓨터

많은 사용자들은 집이나 아파트에 있는 개인용 컴퓨터를 사용하여 친구나 가족 구성원으로부터 개인 이메일에 접속한다.

모바일

이메일은 스마트폰과 모든 유형의 컴퓨터에서 사용되고 있다. 이메일용 모바일 "앱"은 집 밖에 있는 사용자의 매체 접근성을 높인다. 이메일 초기에는 사용자들이 데스크톱 컴퓨터에서만 이메일에 접속할 수 있었지만, 2010년대에는 집을 떠나서도, 다른 도시나 전 세계 어디에서든 이메일을 확인할 수 있게 되었다. 새로운 메시지가 오면 스마트폰이나 다른 기기로 알림을 보낼 수도 있다. 이는 이메일이 사용자 간에 더 빈번한 통신에 사용될 수 있게 해주었고, 하루 종일 이메일을 확인하고 메시지를 작성할 수 있게 해주었다. 2011년 기준 전 세계적으로 약 14억 명의 이메일 사용자가 있었고, 하루에 500억 통의 스팸이 아닌 이메일이 전송되었다.

개인들은 종종 개인 및 업무 관련 메시지 모두를 위해 스마트폰으로 이메일을 확인한다. 미국 성인들은 웹을 탐색하거나 페이스북 계정을 확인하는 것보다 이메일을 더 많이 확인하는 것으로 나타났으며, 이메일은 스마트폰 사용자에게 가장 인기 있는 활동이 되었다. 연구 응답자의 78%는 스마트폰으로 이메일을 확인한다고 밝혔다. 또한 소비자의 30%가 스마트폰만으로 이메일을 확인하며, 91%는 스마트폰으로 하루에 최소 한 번 이상 이메일을 확인할 가능성이 높은 것으로 나타났다. 그러나 스마트폰에서 이메일을 사용하는 소비자의 비율은 국가마다 크게 다르다. 예를 들어, 미국 소비자의 75%가 사용하는 반면, 인도에서는 17%만이 사용했다.

젊은층의 사용 감소

2010년 기준, 이메일 웹사이트를 방문하는 미국인의 수는 2009년 11월에 정점을 찍은 후 6% 감소했다. 12세에서 17세 사이의 경우, 이 수치는 18% 감소했다. 젊은 사람들은 인스턴트 메신저, 문자 메시지 및 소셜 미디어를 선호했다. 기술 작가 맷 리첼은 뉴욕 타임스에서 이메일이 VCR, 바이닐 음반 및 필름 카메라와 같으며, 더 이상 멋지지 않고 나이 든 사람들이 하는 것이라고 말했다.

2015년 안드로이드 사용자 설문조사에 따르면, 13세에서 24세 사이의 사람들은 45세 이상의 사람들보다 메시징 모바일 앱을 3.5배 더 많이 사용했으며, 이메일을 사용할 가능성이 훨씬 낮았다.

문제점

첨부 파일 크기 제한

이메일 메시지에는 하나 이상의 첨부 파일이 있을 수 있으며, 이는 이메일에 추가되는 파일이다. 일반적인 첨부 파일에는 마이크로소프트 워드 문서, PDF 문서 및 스캔된 종이 문서 이미지가 포함된다. 원칙적으로 첨부 파일의 크기나 수에 대한 기술적 제한은 없다. 그러나 실제로는 이메일 클라이언트, 서버 및 인터넷 서비스 제공업체는 파일 또는 전체 이메일 크기에 대해 다양한 제한을 구현하며, 일반적으로 25MB 이하이다. 또한, 기술적인 이유로 이러한 전송 시스템에서 보이는 첨부 파일 크기는 사용자가 보는 것과 다를 수 있으며, 이로 인해 발신자가 이메일로 파일을 안전하게 보낼 수 있는지 여부를 평가할 때 혼란스러울 수 있다. 더 큰 파일을 공유해야 하는 경우 다양한 파일 호스팅 서비스를 사용할 수 있으며 일반적으로 사용된다.

정보 과다

지식 근로자와 "화이트칼라" 직원에게 이메일이 보편화되면서 수신자들이 증가하는 이메일 양으로 인한 "정보 과다"에 직면하고 있다는 우려가 제기되었다. 모바일 기기 사용이 증가하면서 직원들은 기본적으로 근무 시간 외에도 업무 관련 이메일을 받을 수 있게 되었다. 이는 스트레스 증가와 업무 만족도 저하로 이어질 수 있다. 일부 관찰자들은 많은 이메일을 읽으려는 노력이 생산성을 감소시켜 상당한 부정적인 경제적 영향을 미칠 수 있다고 주장하기도 한다.

스팸

이메일 "스팸"은 원치 않는 대량 이메일이다. 이러한 이메일을 보내는 비용이 저렴하다는 것은 2003년까지 전체 이메일 트래픽의 30%가 스팸이었고, 실용적인 도구로서 이메일의 유용성을 위협하고 있음을 의미했다. 미국의 CAN-SPAM Act of 2003 및 다른 지역의 유사 법률은 어느 정도 영향을 미쳤고, 현재는 효과적인 스팸 방지 기술이 대부분의 사용자에게 스팸을 필터링하거나 거부함으로써 스팸의 영향을 크게 완화하고 있지만, 전송되는 양은 여전히 매우 높으며, 점차적으로 제품 광고가 아닌 악성 콘텐츠나 링크로 구성되어 있다. 예를 들어, 2017년 9월에는 스팸의 비율이 합법적인 이메일 대비 59.56%로 증가했다. 2021년 스팸 이메일의 비율은 85%로 추정된다.

악성 소프트웨어

이메일은 악성 소프트웨어 배포의 주요 벡터이다. 이는 종종 악성 프로그램을 메시지에 첨부하고 잠재적 피해자가 파일을 열도록 설득함으로써 달성된다. 이메일을 통해 배포되는 악성 소프트웨어 유형에는 웜 및 랜섬웨어가 포함된다.

이메일 스푸핑

이메일 스푸핑은 이메일 메시지 헤더가 메시지가 알려진 또는 신뢰할 수 있는 출처에서 온 것처럼 보이도록 설계될 때 발생한다. 스팸 메일 및 피싱 방법은 일반적으로 수신자에게 실제 메시지 출처에 대해 오해를 주기 위해 스푸핑을 사용한다. 이메일 스푸핑은 장난으로 수행되거나 개인 또는 조직을 사취하려는 범죄 행위의 일부로 수행될 수 있다. 잠재적으로 사기성 이메일 스푸핑의 예는 개인이 주요 회사에서 온 청구서처럼 보이는 이메일을 만들고 하나 이상의 수신자에게 보내는 경우이다. 일부 경우 이러한 사기성 이메일에는 주장하는 조직의 로고가 포함되어 있으며 이메일 주소도 합법적으로 보일 수 있다.

메일폭탄

메일폭탄은 대상 주소로 대량의 메시지를 의도적으로 보내는 것이다. 대상 전자우편 주소의 과부하로 인해 사용 불능 상태가 될 수 있으며 심지어 메일 서버가 다운될 수도 있다.

개인 정보 보호 문제

오늘날 인터넷과 내부 이메일 시스템을 구분하는 것이 중요할 수 있다. 인터넷 이메일은 발신자나 수신자의 통제 없이 네트워크와 컴퓨터를 통해 전송되고 저장될 수 있다. 전송 시간 동안 제3자가 내용을 읽거나 수정할 수도 있다. 정보가 조직 네트워크를 벗어나지 않는 내부 메일 시스템은 더 안전할 수 있지만, 정보기술 직원 및 모니터링 또는 관리 기능을 수행하는 다른 사람들은 다른 직원의 이메일에 접근할 수 있다.

이메일 개인 정보는 일부 보안 예방 조치 없이는 다음과 같은 이유로 침해될 수 있다.

위의 문제 중 하나 이상에 대한 해결책으로 사용할 수 있는 암호학 응용 프로그램이 있다. 예를 들어, 가상 사설망 또는 토르 네트워크는 사용자 기기에서 더 안전한 네트워크로 트래픽을 암호화하는 데 사용될 수 있으며, GPG, PGP, SMEmail, 또는 S/MIME은 종단 간 메시지 암호화에 사용될 수 있으며, SMTP STARTTLS 또는 Transport Layer Security/Secure Sockets Layer를 통한 SMTP는 SMTP 클라이언트와 SMTP 서버 간의 단일 메일 홉에 대한 통신을 암호화하는 데 사용될 수 있다.

또한 많은 메일 사용자 에이전트는 로그인 및 비밀번호를 보호하지 않아 공격자가 쉽게 가로챌 수 있다. Simple Authentication and Security Layer와 같은 암호화된 인증 방식은 이를 방지한다. 마지막으로, 첨부 파일은 피어 투 피어 파일 공유에서 발견되는 것과 동일한 많은 위험을 공유한다. 첨부 파일에는 트로이 목마 또는 바이러스가 포함될 수 있다.

법적 계약

이메일 교환은 구속력 있는 계약을 형성할 수 있으므로, 사용자들은 이메일 서신을 통해 무엇을 보내는지 주의해야 한다. 이메일의 서명 블록은 계약의 서명 요건을 충족하는 것으로 해석될 수 있다.

악성 댓글

악성 댓글은 어떤 사람이 화가 나거나 적대적인 내용을 담은 메시지(또는 여러 메시지)를 보낼 때 발생한다. 이 용어는 특히 격렬한 이메일 토론을 설명하기 위해 방화성이라는 단어를 사용한 데서 유래한다. 이메일 통신의 용이성과 비인격성은 대면 또는 전화를 통한 정중함을 장려하는 사회 규범이 존재하지 않아 정중함이 잊혀질 수 있다는 것을 의미한다.

이메일 파산

"이메일 피로"라고도 알려진 이메일 파산은 사용자가 읽고 답변하는 데 뒤처진 후 많은 이메일 메시지를 무시하는 경우를 말한다. 뒤처지는 이유는 종종 정보 과다와 모든 정보를 읽는 것이 불가능하다는 일반적인 느낌 때문이다. 해결책으로, 사람들은 때때로 이메일 받은 편지함이 가득 찼고 모든 메시지를 정리하는 중이라는 "보일러플레이트" 메시지를 보낸다. 하버드 대학교 법학 교수 로런스 레시그가 이 용어를 만든 것으로 알려져 있지만, 그는 단지 이 용어를 대중화했을 수도 있다.

국제화

원래 인터넷 이메일은 완전히 ASCII 텍스트 기반이었다. 이제 MIME은 본문 콘텐츠 텍스트와 일부 헤더 콘텐츠 텍스트를 국제 문자 세트로 허용하지만, UTF-8을 사용하는 다른 헤더와 이메일 주소는 표준화되어 있음에도 불구하고 아직 널리 채택되지 않았다.

전송된 메일 추적

원래 SMTP 메일 서비스는 전송된 메시지를 추적하는 제한된 메커니즘을 제공하며, 배달 또는 읽혔는지 확인하는 메커니즘은 전혀 제공하지 않는다. 각 메일 서버는 메시지를 계속 전달하거나 실패 통지(반송 메시지)를 반환해야 하지만, 소프트웨어 버그와 시스템 오류 모두 메시지 손실을 유발할 수 있다. 이를 해결하기 위해 IETF는 배달 상태 알림 (배달 확인) 및 메시지 처리 알림 (읽음 확인)을 도입했지만, 이들은 실제로 보편적으로 배포되지 않았다.

많은 ISP는 스패머의 활동 때문에 고의적으로 배달 불가능 보고서(NDR)와 배달 확인을 비활성화한다.

표준 방법이 없는 상황에서, 웹 버그 사용을 기반으로 하는 다양한 시스템이 개발되었다. 그러나 이러한 시스템은 종종 은밀하거나 개인 정보 보호 문제를 제기하는 것으로 간주되며, HTML 렌더링을 지원하는 이메일 클라이언트에서만 작동한다. 많은 메일 클라이언트는 이제 기본적으로 "웹 콘텐츠"를 표시하지 않는다. 웹 메일 제공업체는 이미지를 미리 캐시하여 웹 버그를 방해할 수도 있다.

같이 보기

내용주

  1. ↑ IBM의 시스템은 공식 출시 이전에 고객에게 요청 시 제공되었다.
  2. ↑ 국제 이메일 또는 MIME을 사용하지 않음
  3. ↑ 완전한 메시지 추적 메커니즘도 정의되었지만, 결코 인기를 얻지 못했다. RFC 3885부터 3888을 참조하라.

각주

  1. 1 2 “DataMail: World's first free linguistic email service supports eight India languages”. 《The Economic Times》. 2016년 10월 22일에 원본 문서에서 보존된 문서.
  2. 1 2 “email noun earlier than 1979”. 《Oxford English Dictionary》. 2012년 10월 25일. 2023년 4월 6일에 원본 문서에서 보존된 문서. 2020년 5월 14일에 확인함.
  3. 1 2 Ohlheiser, Abby (2015년 7월 28일). “Why the first use of the word 'e-mail' may be lost forever”. 《Washington Post》. 2023년 4월 7일에 원본 문서에서 보존된 문서. 2020년 5월 14일에 확인함.
  4. 1 2 3 “From E-mail to Email: Is the Sky Falling?”. 《CMOS Shop Talk》. 시카고 매뉴얼 오브 스타일. 2017년 10월 11일. 2024년 9월 18일에 확인함.
  5. ↑ “Yahoo style guide”. Styleguide.yahoo.com. 2013년 5월 9일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함.
  6. ↑ “AP Removes Hyphen From 'Email' In Style Guide”. 《허핑턴 포스트》. New York City. 2011년 3월 18일. 2015년 5월 12일에 원본 문서에서 보존된 문서.
  7. ↑ “RFC Editor Terms List”. IETF. 2013년 12월 28일에 원본 문서에서 보존된 문서. This is suggested by the RFC Document Style Guide 보관됨 2015-04-24 - 웨이백 머신
  8. ↑ AskOxford Language Query team. “What is the correct way to spell 'e' words such as 'email', 'ecommerce', 'egovernment'?”. 《FAQ》. 옥스퍼드 대학교 출판부. 2008년 7월 1일에 원본 문서에서 보존된 문서. 2009년 9월 4일에 확인함. We recommend email, this is the common form
  9. ↑ “Reference.com”. Dictionary.reference.com. 2013년 12월 16일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함.
  10. ↑ “"RFC Style Guide", Table of decisions on consistent use in RFC”. 2013년 12월 28일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함.
  11. ↑ Israel, Mark. “How do you spell "e-mail"?”. Alt-usage-english.org. 2012년 4월 3일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함.
  12. ↑ thaigh (2015). “Did V.A. Shiva Ayyadurai Invent Email?”. 《SIGCIS》. 2022년 4월 17일에 원본 문서에서 보존된 문서. 2020년 9월 5일에 확인함.
  13. ↑ Masnick, Mike (2019년 5월 22일). “Laying Out All The Evidence: Shiva Ayyadurai Did Not Invent Email”. 《Techdirt.》. 2022년 1월 27일에 원본 문서에서 보존된 문서. 2020년 9월 5일에 확인함.
  14. ↑ Pexton, Patrick B. (2012년 3월 1일). “Origins of e-mail: My mea culpa” (미국 영어). 《Washington Post》. 2022년 5월 19일에 원본 문서에서 보존된 문서. 2022년 4월 18일에 확인함.
  15. ↑ "Mail Objects". Simple Mail Transfer Protocol. IETF. sec. 2.3.1. RFC 5321. https://tools.ietf.org/html/rfc5321#section-2.3.1. "SMTP transports a mail object. A mail object contains an envelope and content."
  16. ↑ "Mail Objects". Simple Mail Transfer Protocol. IETF. sec. 2.3.1. RFC 5321. https://tools.ietf.org/html/rfc5321#section-2.3.1. "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"
  17. ↑ Tom Van Vleck. “The History of Electronic Mail”. 2017년 12월 2일에 원본 문서에서 보존된 문서. 2005년 3월 23일에 확인함.
  18. ↑ Ray Tomlinson. “The First Network Email”. Openmap.bbn.com. 2006년 5월 6일에 원본 문서에서 보존된 문서. 2019년 10월 5일에 확인함.
  19. ↑ Gardner, P. C. (1981). 《A system for the automated office environment》. 《IBM Systems Journal》 20. 321–345쪽. doi:10.1147/sj.203.0321. ISSN 0018-8670; “IBM100 - The Networked Business Place”. 《IBM》. 2020년 8월 2일. 2020년 8월 2일에 원본 문서에서 보존된 문서. 2020년 9월 7일에 확인함.
  20. ↑ Connie Winkler (1979년 10월 22일). “CompuServe pins hopes on MicroNET, InfoPlex”. 《컴퓨터월드》. 13권 42호. 69쪽; Dylan Tweney (1979년 9월 24일). “Sept. 24, 1979: First Online Service for Consumers Debuts”. 《Wired》.
  21. ↑ Ollig, Mark (2011년 10월 31일). “They could have owned the computer industry”. 《Herald Journal》. 2021년 2월 27일에 원본 문서에서 보존된 문서. 2021년 2월 26일에 확인함; “Tech before its time: Xerox's shooting Star computer” (미국 영어). 《New Scientist》. 2012년 2월 15일. 2022년 4월 18일에 원본 문서에서 보존된 문서. 2022년 4월 18일에 확인함; “The Xerox Star”. 《toastytech.com》. 2011년 7월 18일에 원본 문서에서 보존된 문서. 2022년 4월 18일에 확인함.
  22. ↑ “ALL-IN-1”. 《DIGITAL Computing Timeline》. 1998년 1월 30일. 2017년 1월 3일에 원본 문서에서 보존된 문서. 2022년 4월 20일에 확인함.
  23. ↑ “HP Computer Museum”. 2016년 9월 9일에 원본 문서에서 보존된 문서. 2016년 11월 10일에 확인함.
  24. ↑ "Retiring the NSFNET Backbone Service: Chronicling the End of an Era" 보관됨 2016-01-01 - 웨이백 머신, Susan R. Harris, Ph.D., and Elise Gerich, ConneXions, Vol. 10, No. 4, April 1996
  25. ↑ 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. 2015년 8월 11일에 원본 문서에서 보존된 문서.
  26. ↑ Rutter, Dorian (2005). 《From Diversity to Convergence: British Computer Networks and the Internet, 1970-1995》 (PDF) (학위논문). The University of Warwick. 2022년 10월 10일에 원본 문서 (PDF)에서 보존된 문서. 2022년 12월 23일에 확인함.
  27. ↑ Campbell-Kelly, Martin; Garcia-Swartz, Daniel D (2013). 《The History of the Internet: The Missing Narratives》 (영어). 《Journal of Information Technology》 28. 18–33쪽. doi:10.1057/jit.2013.4. ISSN 0268-3962. S2CID 41013. SSRN 867087.
  28. ↑ 《How E-mail Works》. howstuffworks.com. 2008. 2017년 6월 11일에 원본 문서에서 보존된 문서.
  29. ↑ "MX Record Explanation" 보관됨 2015-01-17 - 웨이백 머신, it.cornell.edu
  30. ↑ “What is open relay?”. 《WhatIs.com》. 인디애나 대학교. 2004년 7월 19일. 2007년 8월 24일에 원본 문서에서 보존된 문서. 2008년 4월 7일에 확인함.
  31. ↑ Ch Seetha Ram (2010). 《Information Technology for Management》. Deep & Deep Publications. 164쪽. ISBN 978-81-8450-267-1.
  32. ↑ Hoffman, Paul (2002년 8월 20일). “Allowing Relaying in SMTP: A Series of Surveys”. 《IMC Reports》. Internet Mail Consortium. 2007년 1월 18일에 원본 문서에서 보존된 문서. 2008년 4월 13일에 확인함.
  33. 1 2 3 “Why Email is Not Instantaneous -- and Not Supposed to Be”. 2013년 10월 15일.
  34. ↑ 인터넷 메시지 형식은 네트워크 뉴스에도 사용된다
  35. ↑ Simpson, Ken (2008년 10월 3일). “An update to the email standards”. MailChannels Blog Entry. 2008년 10월 6일에 원본 문서에서 보존된 문서.
  36. ↑ J. Klensin (October 2008). "Mail Objects". Simple Mail Transfer Protocol. sec. 2.3.1. RFC 5321. https://tools.ietf.org/html/rfc5321#section-2.3.1. "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."
  37. ↑ D. Crocker (July 2009). "Message Data". Internet Mail Architecture. sec. 4.1. RFC 5598. https://tools.ietf.org/html/rfc5598#section-4.1. "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."
  38. ↑ P. Resnick, ed. (October 2008). Internet Message Format. IETF Network Working Group. RFC 5322. https://tools.ietf.org/html/rfc5322. Draft Standard. Obsoletes RFC 2822. Updates RFC 4021. Updated by RFC 6854.
  39. ↑ K. Moore (November 1996). MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. Network Working Group. RFC 2047. https://tools.ietf.org/html/rfc2047. Draft Standard. Updated by RFC 2184 and 2231. Obsoletes RFC 1590, 1522 and 1521.
  40. ↑ A. Yang; S. Steele; N. Freed (February 2012). Internationalized Email Headers. Internet Engineering Task Force. ISSN 2070-1721. RFC 6532. https://tools.ietf.org/html/rfc6532. Proposed Standard. Obsoletes RFC 5335. Updates RFC 2045.
  41. ↑ J. Yao; W. Mao (February 2012). SMTP Extension for Internationalized Email. Internet Engineering Task Force. ISSN 2070-1721. RFC 6531. https://tools.ietf.org/html/rfc6531. Proposed Standard. Obsoletes RFC 5336.
  42. ↑ “Now, get your email address in Hindi - The Economic Times”. 《The Economic Times》. 2016년 8월 28일에 원본 문서에서 보존된 문서. 2016년 10월 17일에 확인함.
  43. ↑ "Field Definitions". Internet Message Format. October 2008. sec. 3.6. RFC 5322. https://tools.ietf.org/html/rfc5322#section-3.6. Retrieved 2014-01-09.
  44. ↑ "Identification Fields". Internet Message Format. October 2008. sec. 3.6.4. RFC 5322. https://tools.ietf.org/html/rfc5322#section-3.6.4. Retrieved 2014-01-09.
  45. ↑ M. Duerst (December 2007). The Archived-At Message Header Field. Network Working Group. RFC 5064. https://tools.ietf.org/html/rfc5064. Proposed Standard.
  46. ↑ Microsoft, Auto Response Suppress, 2010, Microsoft reference 보관됨 2011-04-07 - 웨이백 머신, 2010 Sep 22
  47. ↑ 존 클렌신 (October 2008). "Trace Information". Simple Mail Transfer Protocol. IETF. sec. 4.4. RFC 5321. https://tools.ietf.org/html/rfc5321#section-4.4.
  48. ↑ John Levine (2012년 1월 14일). “Trace headers”. 《email message》. IETF. 2012년 8월 11일에 원본 문서에서 보존된 문서. 2012년 1월 16일에 확인함. there are many more trace fields than those two
  49. ↑ 이 확장 가능한 필드는 RFC 7001에 정의되어 있으며, 이는 Internet Assigned Numbers Authority의 Email Authentication Parameters 등록도 정의한다.
  50. ↑ RFC 7208.
  51. ↑ D. Crocker; T. Hansen; M. Kucherawy, eds. (September 2011). DomainKeys Identified Mail (DKIM) Signatures. Internet Engineering Task Force. ISSN 2070-1721. RFC 6376. https://tools.ietf.org/html/rfc6376. Internet Standard. Updated by RFC 8301, 8463, 8553 and 8616. Obsoletes RFC 4871 and 5672.
  52. ↑ Defined in RFC 3834, and updated by RFC 5436.
  53. ↑ RFC 5518.
  54. ↑ Craig Hunt (2002). 《TCP/IP Network Administration》. 오라일리 미디어. 70쪽. ISBN 978-0-596-00297-8.
  55. ↑ “What is unicode?”. 《Konfinity》. 2022년 1월 31일에 원본 문서에서 보존된 문서. 2022년 1월 31일에 확인함.
  56. ↑ “Email policies that prevent viruses”. 《Advosys Consulting》. 2007년 5월 12일에 원본 문서에서 보존된 문서.
  57. ↑ “Problem Solving: Sending Messages in Plain Text”. RootsWeb HelpDesk. 2014년 2월 19일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함. When posting to a RootsWeb mailing list, your message should be sent as "plain text."
  58. ↑ “OpenBSD Mailing Lists”. OpenBSD. 2014년 2월 8일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함. Plain text, 72 characters per line
  59. ↑ “Verhindern, dass die Datei "Winmail.dat" an Internetbenutzer gesendet wird” [How to Prevent the Winmail.dat File from Being Sent to Internet Users]. Microsoft Support. 2010년 7월 2일. 2014년 1월 9일에 원본 문서에서 보존된 문서. 2014년 1월 9일에 확인함.
  60. ↑ 실제로는 수락된 일부 메시지가 수신자의 받은 편지함으로 전달되지 않고, 특히 기업 환경에서 수신자가 접근할 수 없는 스팸 또는 정크 폴더로 전달될 수 있다.
  61. ↑ “View only unread messages”. 《support.microsoft.com》. 2021년 11월 13일에 원본 문서에서 보존된 문서. 2021년 11월 13일에 확인함.
  62. ↑ “Free Email Providers in the Yahoo! Directory”. 《dir.yahoo.com》. 2014년 7월 4일에 원본 문서에서 보존된 문서.
  63. ↑ RFC 2368 section 3 : by Paul Hoffman in 1998 discusses operation of the "mailto" URL.
  64. 1 2 Hansen, Derek; Smith, Marc A.; Heer (2011). 〈E-Mail〉. Barnett, George A (편집). 《Encyclopedia of social networks》. Thousand Oaks, Calif: Sage. 245쪽. ISBN 9781412994170. OCLC 959670912.
  65. ↑ “Creating hyperlinks § E-mail links” (영어). 《MDN Web Docs》. 2019년 8월 18일에 원본 문서에서 보존된 문서. 2019년 9월 30일에 확인함.
  66. ↑ Allen, David (2004). 《Windows to Linux》. Prentice Hall. 192쪽. ISBN 978-1423902454. 2016년 12월 26일에 원본 문서에서 보존된 문서.
  67. ↑ "Implementation and Operation". DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4. sec. 4.5.. RFC 1733. https://tools.ietf.org/html/rfc1733#section-4.5..
  68. ↑ "Message Store (MS)". Internet Mail Architecture. sec. 4.2.2.. RFC 5598. https://tools.ietf.org/html/rfc5598#section-4.2.2..
  69. ↑ By Om Malik, GigaOm. "Is Email a Curse or a Boon? 보관됨 2010-12-04 - 웨이백 머신" September 22, 2010. Retrieved October 11, 2010.
  70. ↑ 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. 293–300쪽. doi:10.1017/s0021849903030265. ISSN 0021-8499. 2012년 10월 21일에 원본 문서 (PDF)에서 보존된 문서.
  71. ↑ Lev, Amir (2009년 10월 2일). “Spam culture, part 1: China”. 2016년 11월 10일에 원본 문서에서 보존된 문서.
  72. ↑ “Email Is Top Activity On Smartphones, Ahead Of Web Browsing & Facebook [Study]”. 2013년 3월 28일. 2014년 4월 29일에 원본 문서에서 보존된 문서.
  73. ↑ “The ultimate mobile email statistics overview”. 2014년 7월 11일에 원본 문서에서 보존된 문서.
  74. ↑ Richtel, Matt (2010년 12월 20일). “E-Mail Gets an Instant Makeover”. 《뉴욕 타임스》. 2018년 4월 5일에 원본 문서에서 보존된 문서. 2018년 4월 4일에 확인함.
  75. ↑ Gustini, Ray (2010년 12월 21일). “Why Are Young People Abandoning Email?”. 《디 애틀랜틱》. 2018년 4월 5일에 원본 문서에서 보존된 문서. 2018년 4월 4일에 확인함.
  76. ↑ Perez, Sarah (2016년 3월 24일). “Email is dying among mobile's youngest users”. 《TechCrunch》. 2018년 4월 5일에 원본 문서에서 보존된 문서. 2018년 4월 4일에 확인함.
  77. ↑ Suneja, Bharat (2007년 9월 10일). “Set Message Size Limits in Exchange 2010 and Exchange 2007”. 《Exchangepedia》. 2013년 2월 12일에 원본 문서에서 보존된 문서.
  78. ↑ Humphries, Matthew (2009년 6월 29일). “Google updates file size limits for Gmail and YouTube”. 《Geek.com》. 2011년 12월 19일에 원본 문서에서 보존된 문서.
  79. ↑ "Maximum attachment size", Gmail Help. 보관됨 10월 15, 2011 - 웨이백 머신.
  80. ↑ Walther, Henrik (January 2009). “Mysterious Attachment Size Increases, Replicating Public Folders, and More”. 《테크넷 매거진》. 2021년 11월 7일에 확인함 – 마이크로소프트 독스 경유. Exchange Queue & A.
  81. ↑ "Send large files to other people" 보관됨 2016-08-07 - 웨이백 머신, Microsoft.com
  82. ↑ "8 ways to email large attachments" 보관됨 2016-07-02 - 웨이백 머신, Chris Hoffman, December 21, 2012, makeuseof.com
  83. ↑ Radicati, Sara. “Email Statistics Report, 2010” (PDF). 2011년 9월 1일에 원본 문서 (PDF)에서 보존된 문서.
  84. ↑ Gross, Doug (2010년 10월 20일). “Happy Information Overload Day!”. 《CNN》. 2015년 10월 23일에 원본 문서에서 보존된 문서. 2019년 3월 24일에 확인함.
  85. ↑ Stross, Randall (2008년 4월 20일). “Struggling to Evade the E-Mail Tsunami”. 《The New York Times》. 2009년 4월 17일에 원본 문서에서 보존된 문서. 2010년 5월 1일에 확인함.
  86. ↑ “Seeing Spam? How To Take Care of Your Google Analytics Data”. 《sitepronews.com》. 2015년 5월 4일. 2017년 11월 7일에 원본 문서에서 보존된 문서. 2017년 9월 5일에 확인함.
  87. ↑ Rich Kawanagh. The top ten email spam list of 2005. ITVibe news, 2006, January 02, ITvibe.com 보관됨 2008-07-20 - 웨이백 머신
  88. ↑ How Microsoft is losing the war on spam Salon.com 보관됨 2008-06-29 - 웨이백 머신
  89. ↑ Spam Bill 2003 (PDF 보관됨 2006-09-11 - 웨이백 머신)
  90. ↑ "Google Says Its AI Catches 99.9 Percent of Gmail Spam" 보관됨 2016-09-16 - 웨이백 머신, Cade Metz, July 09 2015, wired.com
  91. ↑ "Spam and phishing in Q1 2016" 보관됨 2016-08-09 - 웨이백 머신, May 12, 2016, securelist.com
  92. ↑ “Kaspersky Lab Spam and Phishing report”. 2021년 5월 26일. 2018년 7월 17일에 원본 문서에서 보존된 문서. 2018년 7월 17일에 확인함.
  93. ↑ “2021 Email Usage Statistics”. 2021년 10월 5일. 2021년 10월 5일에 원본 문서에서 보존된 문서. 2021년 10월 5일에 확인함.
  94. ↑ Waichulis, Arin (2024년 4월 5일). “Security Bite: iCloud Mail, Gmail, others shockingly bad at detecting malware, study finds” (미국 영어). 《9to5Mac》. 2024년 5월 27일에 확인함.
  95. ↑ “When are email attachments safe to open?”. 《Cloudflare》. 2024년 5월 27일에 확인함.
  96. ↑ Griffiths, James (2020년 5월 2일). “How a badly-coded computer virus caused billions in damage | CNN Business” (영어). 《CNN》. 2024년 5월 27일에 확인함.
  97. ↑ French, Laura (2024년 5월 14일). लाखों-of-emails-via-phorpiex-botnet “LockBit ransomware spread in millions of emails via Phorpiex botnet” |url= 값 확인 필요 (도움말) (영어). 《SC Media》. 2024년 5월 27일에 확인함.
  98. ↑ SMEmail – A New Protocol for the Secure E-mail in Mobile Environments, Proceedings of the Australian Telecommunications Networks and Applications Conference (ATNAC'08), pp. 39–44, Adelaide, Australia, Dec. 2008.
  99. ↑ “When Email Exchanges Become Binding Contracts”. 《law.com》. 2019년 6월 19일에 원본 문서에서 보존된 문서. 2019년 12월 6일에 확인함.
  100. ↑ Catarina, Jessica; Feitel, Jesse (2019). 《Inadvertent Contract Formation via Email under New York Law: An Update》 (PDF). 《시러큐스 로 리뷰》 69.
  101. ↑ Corfield, Gareth (2019년 9월 30일). “UK court ruling says email signature blocks can sign binding contracts”. 《더 레지스터》. 2019년 10월 17일에 원본 문서에서 보존된 문서. 2019년 12월 6일에 확인함.
  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 (2007년 12월 23일). “All We Are Saying.”. 《The New York Times》. 2009년 4월 17일에 원본 문서에서 보존된 문서. 2007년 12월 24일에 확인함.
  104. ↑ “Internationalized Domain Names (IDNs) | Registry.In”. 《registry.in》. 2016년 5월 13일에 원본 문서에서 보존된 문서. 2016년 10월 17일에 확인함.
  105. ↑ “Made In India 'Datamail' Empowers Russia With Email Address In Russian Language - Digital Conqueror”. 2016년 12월 7일. 2017년 3월 5일에 원본 문서에서 보존된 문서.
  106. ↑ RFC 3885, SMTP Service Extension for Message Tracking
  107. ↑ RFC 3888, Message Tracking Model and Requirements
  108. ↑ Amy Harmon (2000년 11월 22일). “Software That Tracks E-Mail Is Raising Privacy Concerns”. 《The New York Times》. 2012년 1월 13일에 확인함.
  109. ↑ "Outlook: Web Bugs & Blocked HTML Images" 보관됨 2015-02-18 - 웨이백 머신, slipstick.com
  110. ↑ "Gmail blows up e-mail marketing..." 보관됨 2017-06-07 - 웨이백 머신, Ron Amadeo, Dec 13 2013, Ars Technica

추가 자료

외부 링크