전자우편

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

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

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

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

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

## 용어
전자우편이라는 용어는 1975년부터 현대적인 의미로 사용되었으며, 더 짧은 이메일의 변형은 1979년부터 사용되었다.
* **email**은 현재 일반적인 형태이며 스타일 가이드에서 권장한다. IETF Requests for Comments (RFC) 및 워킹 그룹에서 요구하는 형태이다. 이 표기는 대부분의 사전에도 나타난다.
* **e-mail**은 원래 편집된 출판물인 미국 영어 및 영국 영어 글쓰기에서 선호되는 형태였으며, 이전에는 일부 스타일 가이드에서 선호되었다.
* **E-mail**이 때때로 사용된다. 1979년 6월, 원래 사용된 것은 Electronics 저널에서 1970년대 후반에 개발되어 1980년대 초반에 운영된 미국 우정공단의 E-COM이라는 이니셔티브를 언급할 때였다.
* **EMAIL**은 1981년 4월부터 컴퓨서브에서 사용되어 이 용어를 대중화시켰다.
* **EMail**은 "Author's Address"에 대한 RFC에서 사용되는 전통적인 형태이다.

이 서비스는 종종 단순히 메일이라고 불리며, 단일 전자 메일은 메시지라고 불린다. 이메일 내 필드(예: "받는 사람", "보낸 사람", "참조", "숨은 참조" 등)에 대한 관례는 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)를 사용하여 메시지를 전송할 때 발생하는 일반적인 일련의 이벤트이다.

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

이 예 외에도 이메일 시스템에는 대안과 복잡성이 존재한다:
* 앨리스나 밥은 IBM Lotus Notes나 마이크로소프트 Exchange와 같은 기업 이메일 시스템에 연결된 클라이언트를 사용할 수 있다. 이러한 시스템은 종종 자체 내부 이메일 형식을 가지며, 클라이언트는 일반적으로 공급업체별 독점 프로토콜을 사용하여 이메일 서버와 통신한다. 서버는 제품의 인터넷 메일 게이트웨이를 통해 인터넷을 통해 이메일을 보내거나 받으며, 필요한 재포맷 작업도 수행한다. 앨리스와 밥이 같은 회사에 근무한다면, 전체 거래는 단일 기업 이메일 시스템 내에서 완전히 이루어질 수 있다.
* 앨리스는 컴퓨터에 MUA가 없을 수도 있지만, 대신 웹 메일 서비스에 연결할 수 있다.
* 앨리스의 컴퓨터는 자체 MTA를 실행하여 1단계의 전송을 피할 수 있다.
* 밥은 여러 가지 방법으로 이메일을 가져올 수 있다. 예를 들어, mx.b.org에 로그인하여 직접 읽거나, 웹 메일 서비스를 사용할 수 있다.
* 도메인은 일반적으로 여러 메일 교환 서버를 가지므로 주 서버를 사용할 수 없더라도 메일을 계속 수신할 수 있다.

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

이메일은 인스턴트 메신저보다 앞서며, 신뢰할 수 없는 네트워크 링크와 바쁜 서버(인터넷 초기에 더 흔했음)에 대처하기 위해 속도보다 신뢰성을 선호한다. 느린 배송의 이유는 다음과 같다.
* 많은 수의 수신자에게 보내는 메시지는 더 많은 처리가 필요하다.
* 대용량 메시지(예: 대용량 첨부 파일 포함)는 네트워크를 통해 전송하는 데 더 많은 시간이 걸린다.
* 메시지는 여러 서버(때로는 같은 조직 내의 여러 서버)를 통과해야 한다.
* 하나 이상의 메일 서버가 과부하(아마도 스팸 또는 서비스 거부 공격으로 인해)되어 수신 메일을 대기열에 넣거나 일시적으로 수신 연결을 거부한다.
* SMTP는 여러 번의 왕복 통신을 요구하며, 이는 느린 네트워크나 손실된 패킷의 영향을 증폭시킬 수 있다.
* 발신자 또는 수신자가 일시적으로 네트워크에서 연결이 끊긴 경우(예: 노트북이 Wi-Fi 범위 밖에 있는 경우)
* 느린 DNS 응답
* 유지 보수 또는 오작동으로 인한 서버 다운

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

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

## 메시지 형식
이메일에 사용되는 기본 인터넷 메시지 형식은 에 의해 정의되며, 비-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 등.
* : 메시지에 답장하는 데 사용해야 할 주소.
* 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 확장은 이러한 인코딩 없이 메일 전송을 허용하기 위해 도입되었지만, 많은 메일 전송 에이전트는 이를 지원하지 않을 수 있다. 일부 국가에서는 이메일 소프트웨어가 를 위반하여 원시 비 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년대에는 집을 떠나서도, 다른 도시나 전 세계 어디에서든 이메일을 확인할 수 있게 되었다. 새로운 메시지가 오면 스마트폰이나 다른 기기로 알림을 보낼 수도 있다. 이는 이메일이 사용자 간에 더 빈번한 통신에 사용될 수 있게 해주었고, 하루 종일 이메일을 확인하고 메시지를 작성할 수 있게 해주었다.  전 세계적으로 약 14억 명의 이메일 사용자가 있었고, 하루에 500억 통의 스팸이 아닌 이메일이 전송되었다.

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

#### 젊은층의 사용 감소
, 이메일 웹사이트를 방문하는 미국인의 수는 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자가 내용을 읽거나 수정할 수도 있다. 정보가 조직 네트워크를 벗어나지 않는 내부 메일 시스템은 더 안전할 수 있지만, 정보기술 직원 및 모니터링 또는 관리 기능을 수행하는 다른 사람들은 다른 직원의 이메일에 접근할 수 있다.

이메일 개인 정보는 일부 보안 예방 조치 없이는 다음과 같은 이유로 침해될 수 있다.
* 이메일 메시지는 일반적으로 암호화되지 않는다.
* 이메일 메시지는 목적지에 도달하기 전에 중간 컴퓨터를 거쳐야 하므로 다른 사람들이 메시지를 가로채거나 읽는 것이 비교적 쉽다.
* 많은 인터넷 서비스 제공업체(ISP)는 이메일 메시지가 배달되기 전에 메일 서버에 사본을 저장한다. 이 백업은 사서함에서 삭제된 후에도 서버에 몇 달 동안 남아 있을 수 있다.
* 이메일의 "Received:" 필드 및 기타 정보는 종종 발신자를 식별하여 익명 통신을 방해할 수 있다.
* HTML 콘텐츠에 보이지 않게 삽입된 웹 버그는 이메일이 HTML로 렌더링될 때(일부 이메일 클라이언트는 사용자가 이메일을 읽거나 다시 읽을 때 이렇게 함) 언제든지 발신자에게 알리고 IP 주소도 알려줄 수 있다. 또한 사용자 에이전트 문자열을 통해 이메일이 스마트폰, PC 또는 애플 맥 장치에서 읽혔는지 여부도 밝힐 수 있다.

위의 문제 중 하나 이상에 대한 해결책으로 사용할 수 있는 암호학 응용 프로그램이 있다. 예를 들어, 가상 사설망 또는 토르 네트워크는 사용자 기기에서 더 안전한 네트워크로 트래픽을 암호화하는 데 사용될 수 있으며, 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)와 배달 확인을 비활성화한다.
* 배달 보고서는 주소가 존재하는지 확인할 수 있으며, 만약 그렇다면 스패머에게 스팸을 보낼 수 있음을 알려준다.
* 스패머가 위조된 발신자 이메일 주소(이메일 스푸핑)를 사용하는 경우, 사용된 무고한 이메일 주소는 스패머가 메일을 보내려고 시도했을 수 있는 많은 유효하지 않은 이메일 주소로부터 NDR로 범람할 수 있다. 이러한 NDR은 ISP에서 무고한 사용자에게 스팸(백스캐터)이 된다.

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

## 같이 보기

* 익명 재메일러
* 안티스팸 기술
* biff
* 반송 메시지
* 이메일 클라이언트 비교
* 다크 메일 얼라이언스
* 임시 이메일 주소
* 이카드
* 전자 메일링 리스트
* 이메일 아트
* 전자우편 인증
* 이메일 다이제스트
* 이메일 암호화
* 이메일 호스팅 서비스
* 이메일 허브
* 이메일 폭풍
* 이메일 추적
* HTML 이메일
* 정보 과다
* 인터넷 팩스
* 이메일 제목 약어 목록
* MCI 메일
* 네티켓
* 포스팅 스타일
* 개인 정보 강화 전자우편
* 푸시 이메일
* RSS
* 전보
* 유니코드와 전자우편
* 유즈넷 인용
* 웹 메일, 웹 메일 제공자 비교
* X-Originating-IP
* X.400

## 내용주

## 각주

## 추가 자료

* Cemil Betanov, Introduction to X.400, Artech House, .
* Marsha Egan, "Inbox Detox and The Habit of Email Excellence ", Acanthus Publishing 
* Lawrence Hughes, Internet e-mail Protocols, Standards and Implementation, Artech House Publishers, .
* Kevin Johnson, Internet Email Protocols: A Developer's Guide, Addison-Wesley Professional, .
* Pete Loshin, Essential Email Standards: RFCs and Protocols Made Practical, John Wiley & Sons, .
* 
* Sara Radicati, Electronic Mail: An Introduction to the X.400 Message Handling Standards, Mcgraw-Hill, .
* John Rhoton, Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP, Elsevier, .
* John Rhoton, X.400 and SMTP: Battle of the E-mail Protocols, Elsevier, .
* David Wood, Programming Internet Mail, O'Reilly, .

## 외부 링크
* IANA의 표준 헤더 필드 목록
* The History of Email은 이메일 진화의 '중요한' 사건들의 순서를 포착하려는 데이브 크로커의 시도이며, 이 페이지도 인용하는 협력적인 노력이다.
* The History of Electronic Mail은 초기 이메일 시스템 구현자의 개인 회고록이다.
* A Look at the Origins of Network Email은 주요 역사적 사실을 간결하면서도 생생하게 요약한 글이다.
* Business E-Mail Compromise - An Emerging Global Threat, 연방수사국
* Explained from first principles, 100개가 넘는 RFC를 요약하려는 2021년 기사


분류:전자 문서
분류:인터넷 용어
분류:인터넷의 역사
분류:페디버스