이메일 클라이언트

(메일 판독기에서 리디렉션됨)
이 기사는 인터넷 전자우편의 메일 리더에 관한 것이다. BBS 메일 판독기에 대한 내용은 오프라인 판독기를 참조하십시오.
Linux 운영 체제에서 Mozilla Thunderbird 전자 메일 클라이언트 사용자 인터페이스

전자 메일 클라이언트, 전자 메일 리더 또는 보다 공식적으로 메시지 사용자 에이전트(MUA) 또는 메일 사용자 에이전트는 사용자의 전자 메일에 액세스하고 관리하는 데 사용되는 컴퓨터 프로그램이다.

메시지 관리, 구성 및 수신 기능을 제공하는 웹 애플리케이션은 웹 전자 메일 클라이언트 역할을 할 수 있으며, 전자 메일 클라이언트로 작동하거나 가장 눈에 띄는 역할을 하는 컴퓨터 하드웨어 또는 소프트웨어의 일부도 이 용어를 사용할 수 있다.

편지함에서 메시지 검색

대부분의 클라이언트 프로그램과 마찬가지로 이메일 클라이언트는 사용자가 실행할 때만 활성화된다. 일반적으로 전자 메일 사용자(클라이언트)가 클라이언트 전자 메일의 수신 및 저장을 위해 원격 MTA(Mail Transfer Agent) 서버와 계약을 체결하는 것이다. MTA는 적합한 메일 배달 에이전트(MDA)를 사용하여 클라이언트의 저장소에 전자 메일 메시지를 추가한다. 원격 메일 저장소를 사용자의 사서함이라고 한다. 대부분의 Unix 시스템의 기본 설정은 메일 서버가 사용자의 홈 디렉토리 내에 형식화된 메시지를 mbox에 저장하는 것이다. 물론, 이 시스템의 사용자들은 그들의 우편함을 호스트하는 동일한 컴퓨터에서 메일 클라이언트를 로그인하고 실행할 수 있다. 이 경우, 서버는 일반적인 의미에서가 아닌 실제 원격은 아니다.

전자 메일은 사용자의 전자 메일 클라이언트가 사용자의 컴퓨터에 다운로드할 것을 요청할 때까지 원격 서버에 있는 사용자의 사서함에 저장되거나, 그렇지 않으면 원격 서버에 있는 사용자의 사서함에 액세스할 수 있다. 이메일 클라이언트는 동시에 여러 메일박스에 접속하도록 설정할 수 있으며, 이메일 다운로드를 사전 설정 간격과 같이 자동으로 요청하거나 사용자가 수동으로 요청할 수 있다.

사용자의 우편함은 두 가지 전용 방법으로 접근할 수 있다. POP(Post Office Protocol)는 사용자가 한 번에 하나씩 메시지를 다운로드할 수 있도록 하며, 로컬 저장소에 성공적으로 저장된 후에만 메시지를 서버에서 삭제할 수 있다. 다른 클라이언트의 액세스를 허용하기 위해 서버에 메시지를 남길 수 있다. 그러나 특정 메시지를 보거나 응답하거나 전달할 수 있는 규정이 없으므로 POP은 다른 기기에서 동일한 메일에 접근하는 사용자에게 편리하지 않다.

또는, IMAP(Internet Message Access Protocol)은 사용자가 메시지를 서버에 보관할 수 있도록 하며, 메시지를 적절하게 플래그 지정한다. IMAP는 폴더와 하위 폴더를 제공하며, 접근 권한이 서로 다를 수 있는 다른 사용자들 간에 공유될 수 있다. 일반적으로 발송된 문서, 미발송 문서 및 휴지통 폴더는 기본적으로 작성된다. IMAP는 실시간 업데이트를 위한 유휴 확장을 특징으로, 장기간 연결이 가능한 폴링보다 빠른 알림을 제공한다. 아래 원격 메시지 섹션을 참조하십시오.

JSON Meta Application Protocol(JMAP)은 HTTP를 통한 JSON API를 사용하여 구현되며 IMAP/SMTP의 대안으로 개발되었다.

또한 우편함 저장소는 서버에서 실행 중인 프로그램이나 공유 디스크를 통해 직접 액세스할 수 있다. 직접 액세스는 더 효율적일 수 있지만 우편함 형식에 따라 이동성이 떨어지기 때문에 일부 웹메일 응용프로그램을 포함한 일부 전자 메일 클라이언트에서 사용되고 있다.

메시지 구성

이메일 클라이언트에는 일반적으로 텍스트를 표시하고 편집하기 위한 사용자 인터페이스가 포함되어 있다. 일부 애플리케이션은 프로그램 외부 편집기의 사용을 허용한다.

이메일 클라이언트는 헤더와 본문의 경우 RFC 5322, 텍스트가 아닌 내용과 첨부파일의 경우 MIME에 따라 포맷을 수행한다. 머리글에는 대상 필드인 To, Cc(Carbon copy의 줄임말), Bc(Blind carbon copy)와 메시지의 작성자인 발신인 필드, 작성자가 더 있을 경우 발신인 필드, 응답이 다른 사서함으로 발송될 경우 회신인 필드 등이 있다. 사용자가 대상 필드를 더 잘 활용할 수 있도록, 많은 클라이언트는 하나 이상의 주소록을 유지 관리하거나 LDAP 디렉토리 서버에 연결할 수 있다. 발신자 분야의 경우, 고객은 다른 신원을 지원할 수 있다.

클라이언트 설정에는 각 사용자의 ID에 대한 사용자의 실명과 이메일 주소, 그리고 LDAP 서버의 목록이 필요하다.

서버에 메시지 제출

사용자가 이메일을 만들어 보내기를 원할 때 이메일 클라이언트가 작업을 처리한다. 이메일 클라이언트는 일반적으로 사용자의 메일 서버에 연결하도록 자동으로 설정되며, 일반적으로 SMTP 프로토콜의 두 가지 변형인 MSA 또는 MTA가 된다. SMTP 프로토콜을 사용하는 이메일 클라이언트는 메일 서버가 발신인을 인증하는 데 사용하는 인증확장을 작성한다. 이 방법은 모듈화와 유목 컴퓨팅을 용이하게 한다. 이전 방법은 클라이언트가 동일한 컴퓨터에 있고 내부 주소 127.0.0.1을 사용하기 때문에 또는 클라이언트의 IP 주소가 인터넷 접속과 메일 서비스를 모두 제공하는 동일한 인터넷 서비스 제공자에 의해 제어되기 때문에 메일 서버가 클라이언트의 IP 주소를 인식하는 것이었다.

클라이언트 설정에는 선호하는 발신 메일 서버의 이름 또는 IP 주소, 포트 번호(MTA의 경우 25, MSA의 경우 587), 인증을 위한 사용자 이름과 암호가 필요하다. SSL 암호화 SMTP 세션을 위한 비표준 포트 465가 있으며, 많은 클라이언트와 서버가 역호환성을 지원한다.

암호화

엽서와 마찬가지로 암호화되지 않은 이메일 활동은 엿듣는 사람이면 누구나 쉽게 볼 수 있다. 전자 메일 암호화는 메일 세션, 메시지 본문 또는 둘 모두를 암호화하여 프라이버시를 보호할 수 있다. 그것이 없다면, 네트워크 접속과 올바른 도구를 가진 사람이라면 누구나 이메일을 감시하고 로그인 비밀번호를 얻을 수 있다. 우려의 예로는 정부의 검열과 감시 그리고 인터넷 카페와 같은 동료 무선 네트워크 사용자들이 있다.

모든 관련 전자 메일 프로토콜에는 사용자의 이름과 암호가 스니핑되지 않도록 전체 세션을 암호화하는 옵션이 있다. 그것들은 유목민 이용자들을 위해 그리고 인터넷 접속 제공자가 신뢰받지 못할 때마다 강력하게 제안된다.[1] 메일을 발송할 때, 사용자는 클라이언트에서 구성된 발송 메일 서버로 가는 첫번째 홉에서만 암호화를 제어할 수 있다. 어떤 추가 홉에서든, 메시지는 오직 송신 서버의 일반적인 구성과 수신 서버의 기능에 따라 암호화 여부와 관계없이 전송될 수 있다.

암호화된 메일 세션은 일반 텍스트나 암호화된 본문, 사용자의 로컬 사서함 및 대상 서버의 원본 형식으로 메시지를 배달한다. 후자의 서버는 이메일 호스팅 서비스 제공자에 의해 운영되며, 현재 이용 중인 인터넷 접속 제공업체와는 다른 실체일 가능성이 있다.

SSL과 같은 전자 메일 검색 세션을 암호화하면 세션의 두 부분(인증 및 메시지 전송)을 모두 보호할 수 있다.[2][3]

또는 사용자가 메일 서버에 대한 SSH 액세스 권한을 가진 경우 SSH 포트 포워딩을 사용하여 전자 메일을 검색할 암호화된 터널을 만들 수 있다.[4]

메시지 본문 암호화

암호키를 관리하기 위한 두 가지 주요 모델이 있다. S/MIME은 사용자의 공개키에 서명하는 신뢰할 수 있는 CA(인증기관)를 기반으로 한 모델을 채용한다. OpenPGP는 사용자가 서로의 공용 키에 서명할 수 있는 다소 유연한 신뢰 메커니즘을 채택한다. OpenPGP는 또한 MIME 표준화 이전에 작업했던 것처럼 일반 메시지 암호화 및 서명을 여전히 지원한다는 점에서 메시지의 형식에 있어서 더 유연하다.

두 경우 모두 메시지 본문만 암호화된다. 발신인, 수신인 및 제목을 포함한 헤더 필드는 일반 텍스트로 유지된다.

웹메일

주요 기사: 웹메일

데스크톱 컴퓨터에서 실행되는 이메일 클라이언트 외에도, 텔넷에서 액세스할 수 있는 원격 UNIX 설치(즉, 셸 계정)의 일부로서 또는 웹에서 호스팅되는 원격 유닉스 설치의 일부로서 원격으로 호스팅되는 클라이언트도 있다. 이 두 가지 접근법 모두 몇 가지 장점이 있다: 웹 브라우저나 텔넷 클라이언트를 사용하여 사용자의 일반적인 기반에서 멀리 떨어진 곳에서 이메일을 주고받을 수 있는 기능을 공유하기 때문에 사용자의 기기에 전용 이메일 클라이언트를 설치할 필요가 없다.

어떤 웹사이트들은 이메일 서비스 제공에만 전념하고 있으며, 많은 인터넷 서비스 제공자들은 그들의 인터넷 서비스 패키지의 일부로 웹메일 서비스를 제공한다. 웹 메일의 주요 제한사항은 웹 메일 기능의 일부를 OS에 통합할 수 있는 소프트웨어 패키지가 있지만(예: 3차에서 직접 메시지를 만드는 것) 사용자 상호작용이 웹 사이트의 운영체제에 따라 이루어지며, 일반적으로 전자 메일 메시지를 다운로드하고 오프라인에서 메시지를 작성하거나 작업할 수 없다는 것이다. MAPI)를 통한 파티 신청.

IMAP이나 MAPI처럼 웹메일은 메일 서버에 이메일 메시지를 남길 수 있게 해준다. 다음 섹션을 참조하십시오.

원격 메시지

POP3에는 서버에 메시지를 남길 수 있는 옵션이 있다. 이와는 대조적으로 IMAP과 웹메일 모두 사용자가 원하는 대로 로컬 사본을 만들 수 있지만, 서버에 메시지를 그들의 운영 방법으로 보관한다. 서버에 메시지를 보관하는 것은 장단점이 있다.[5]

이점

  • 메시지는 다른 클라이언트를 사용하여 다른 위치에 있는 다양한 컴퓨터나 모바일 장치에서 액세스할 수 있다.
  • 어떤 종류의 백업은 보통 서버에 의해 제공된다.

단점들

  • 제한된 대역폭으로, 전자 메일 클라이언트가 로컬 복사본을 캐시하지 않는 한 긴 메시지에 대한 액세스는 길어질 수 있다.
  • 엔드투엔드 암호화를 사용하지 않는 한, 항상 서버에 남아 있는 메시지는 IT 직원이 무심코 접근할 수 있는 기회가 더 많기 때문에 프라이버시 우려가 있을 수 있다.

프로토콜

메일 검색을 위한 인기 있는 프로토콜로는 POP3와 IMAP4가 있다. 메일 발송은 보통 SMTP 프로토콜을 사용하여 한다.

대부분의 전자 메일 클라이언트가 지원하는 또 다른 중요한 표준은 이진 파일 전자 메일 첨부 파일을 보내는 데 사용되는 MIME이다. 첨부파일은 이메일의 일부가 아니지만 이메일과 함께 전송되는 파일이다.

대부분의 전자 메일 클라이언트는 사용자-에이전트[6] 헤더 필드를 사용하여 메시지를 보내는 데 사용되는 소프트웨어를 식별한다. RFC 2076에 따르면, 이것은 공통적이지만 비표준 헤더 필드다.[disputed – discuss]

RFC 6409, Message Submission for Mail은 메일 제출 에이전트의 역할을 상세하게 설명한다.

RFC 5068, 이메일 제출 작업: 액세스 및 책임 요구사항은 MTA, MSA, MDA 및 MUA의 개념에 대한 설문조사를 제공한다. 그것은 "접근 제공자는 SUPLITY 포트 587을 이용하여 외부 인터넷에 접속하는 것을 차단해서는 안 된다"와 "MUA는 SUPLITY 포트를 메시지 제출에 사용해야 한다"고 언급하고 있다.

포트 번호

관례에 따른 이메일 서버와 클라이언트는 다음 표의 TCP 포트 번호를 사용한다. MSA, IMAP 및 POP3의 경우 표는 SRV 기록을 쿼리하고 해당 서비스의 호스트 이름과 포트 번호를 모두 검색하는 데 클라이언트가 사용할 수 있는 레이블도 보고한다.[7]

의정서 사용하다 일반 텍스트 또는
세션 암호화 		평문.
세션만 		세션 암호화
단 한 가지
POP3 들어오는 우편물 110
_pop3._properties 		995
_pop3s._properties.
IMAP4 들어오는 우편물 143
_imap._properties 		993
_imaps._message
SMTP 발송 우편물 25 587
MSA 발송 우편물 587
_불쌍한_beakes 		465[8]
_파견._beakes
HTTP 웹메일 80 443

웹메일은 암호화 및 일반 텍스트 세션을 위한 별도의 포트를 갖는 이전의 HTTP 처분에 따르는 반면, 메일 프로토콜은 STARTLS 기법을 사용하므로 이미 설정된 TCP 연결에서 암호화를 시작할 수 있다. RFC 2595는 이전에 설정된 포트 995와 993의 사용을 억제하는 데 사용되었지만, RFC 8314는 사용 가능할 때 암묵적 TLS의 사용을 촉진한다.

독점 클라이언트 프로토콜

Microsoft 메일 시스템은 Microsoft Outlook과 같은 클라이언트 응용 프로그램의 독점 MAPI(Messaging Application Programming Interface)를 사용하여 Microsoft Exchange 전자 메일 서버에 액세스한다.

참고 항목

참조

  1. ^ C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (November 2007). "Message Submission Authentication/Authorization Technologies". Email Submission Operations: Access and Accountability Requirements. IETF. sec. 5. doi:10.17487/RFC5068. BCP 134. RFC 5068. Retrieved 24 August 2011. This document does not provide recommendations on specific security implementations. It simply provides a warning that transmitting user credentials in clear text over insecure networks SHOULD be avoided in all scenarios as this could allow attackers to listen for this traffic and steal account data. In these cases, it is strongly suggested that an appropriate security technology MUST be used.
  2. ^ 실 2003, 페이지 353: "SMTP와 마찬가지로 POP3는 암호화되지 않는다. 그러나 SMTP와 달리 다음과 같은 인증이 필요하다. 사용자들은 자신을 식별하고 자신이 자신이 누구인지를 증명해야 한다. 불행히도, 인증은 대개 사용자 이름과 사용자만 알고 있는 비밀번호와 POP3 서버로 구성된다. POP3 대화는 암호화되지 않기 때문에 도청자는 사용자의 사용자 이름과 비밀번호를 입수하여 재사용하여 사용자의 우편함에 접속할 수 있다. 그래서 일반 POP3는 사용자가 검색한 메일 메시지의 내용을 노출시키고, 사용자 이름과 비밀번호를 노출시켜, 다른 사람이 재사용할 수 있다.
    POP3 대화를 SSL과 같은 전송 계층 보안으로 마무리하면 이 두 가지 문제가 모두 해결된다. SSL 포장 POP3 세션은 처음부터 끝까지 암호화되기 때문에, 메시지, 사용자 이름 또는 비밀번호가 클리어텍스트에서 노출되지 않는다.
    옵션 POP3 명령, APOP는 표준을 대체한다. USER/PASS 질문-응답 인증 메커니즘을 통한 인증. 이렇게 하면 재사용 가능한 비밀번호 공개 문제는 해결되지만, 도청자가 검색되는 동안 사용자의 메일 메시지를 읽는 것을 막을 수는 없다고 말했다.
  3. ^ Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. doi:10.17487/RFC7817. RFC 7817.
  4. ^ Flickenger, Rob (2003). Linux Server Hacks: 100 Industrial-Strength Tips & Tools. O'Reilly Media. p. 146. ISBN 978-0596004613. In addition to providing remote shell access and command execution, OpenSSH can forward arbitrary TCP ports to the other end of your connection. This can be very handy for protecting email, web, or any other traffic you need to keep private (at least, all the way to the other end of the tunnel).
    ssh accomplishes local forwarding by binding to a local port, performing encryption, sending the encrypted data to the remote end of the ssh connection, then decrypting it and sending it to the remote host and port you specify. Start an ssh tunnel with the -L switch (short for Local):
    root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
    Naturally, substitute user with your username, and mailhost with your mail server's name or IP address. Note that you will have to be root on the laptop for this example since you'll be binding to a privileged port (110, the POP port). You should also disable any locally running POP daemon (look in /etc/inetd.conf) or it will get in the way.
    Now to encrypt all of your POP traffic, configure your mail client to connect to localhost port 110. It will happily talk to mailhost as if it were connected directly, except that the entire conversation will be encrypted.
  5. ^ "Is IMAP Right for Me?". IT Services. Stanford University. 4 March 2010. Retrieved 14 April 2013.
  6. ^ "User-Agent". Netnews Article Format. IETF. November 2009. sec. 3.2.13. doi:10.17487/RFC5536. RFC 5536. Some of this information has previously been sent in non-standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others
  7. ^ Cyrus Daboo (March 2011). Use of SRV Records for Locating Email Submission/Access Services. IETF. doi:10.17487/RFC6186. RFC 6186. Retrieved 17 April 2013.
  8. ^ Keith Moore; Chris Newman (January 2018). Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. IETF. doi:10.17487/RFC8314. RFC 8314. Retrieved 12 February 2018.


참고 문헌 목록