전자우편 문서 원본 보기

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

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

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

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

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

==용어==
전자우편이라는 용어는 1975년부터 현대적인 의미로 사용되었으며, 더 짧은 이메일의 변형은 1979년부터 사용되었다.<ref name="Oxford English Dictionary 2012">{{웹 인용| title=email noun earlier than 1979 | website=Oxford English Dictionary | date=2012-10-25 | url=https://public.oed.com/appeals/email/ | access-date=2020-05-14 | archive-date=April 6, 2023 | archive-url=https://web.archive.org/web/20230406100025/https://public.oed.com/appeals/email/ | url-status=live }}</ref><ref name="Ohlheiser 2015">{{뉴스 인용| last=Ohlheiser | first=Abby | title=Why the first use of the word 'e-mail' may be lost forever | newspaper=Washington Post | date=2015-07-28 | url=https://www.washingtonpost.com/news/the-intersect/wp/2015/07/28/why-the-first-use-of-the-word-e-mail-may-be-lost-forever/ | access-date=2020-05-14 | archive-date=April 7, 2023 | archive-url=https://web.archive.org/web/20230407131904/https://www.washingtonpost.com/news/the-intersect/wp/2015/07/28/why-the-first-use-of-the-word-e-mail-may-be-lost-forever/ | url-status=live }}</ref>
* '''email'''은 현재 일반적인 형태이며 [[스타일 가이드]]에서 권장한다.<ref name="cmos"/><ref>{{웹 인용|url=https://styleguide.yahoo.com/word-list/e|title=Yahoo style guide|publisher=Styleguide.yahoo.com|archive-url=https://web.archive.org/web/20130509154006/https://styleguide.yahoo.com/word-list/e|archive-date=May 9, 2013|access-date=2014-01-09}}</ref><ref>{{웹 인용|url=https://www.huffingtonpost.com/2011/03/18/ap-removes-hyphen-from-em_n_837833.html|title=AP Removes Hyphen From 'Email' In Style Guide|website=[[허핑턴 포스트]]|location=New York City|date=March 18, 2011|url-status=live|archive-url=https://web.archive.org/web/20150512055628/https://www.huffingtonpost.com/2011/03/18/ap-removes-hyphen-from-em_n_837833.html |archive-date=May 12, 2015}}</ref> [[국제 인터넷 표준화 기구|IETF]] [[RFC|Requests for Comments]] (RFC) 및 워킹 그룹에서 요구하는 형태이다.<ref>{{웹 인용|url=https://www.rfc-editor.org/rfc-style-guide/terms-online.txt|publisher=IETF|title=RFC Editor Terms List|url-status=live|archive-url=https://web.archive.org/web/20131228152111/https://www.rfc-editor.org/rfc-style-guide/terms-online.txt|archive-date=2013-12-28}} This is suggested by the [https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt RFC Document Style Guide]  {{웹아카이브|url=https://web.archive.org/web/20150424002009/https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt |date=2015-04-24 }}</ref> 이 표기는 대부분의 사전에도 나타난다.<ref>{{웹 인용| url=https://www.askoxford.com/asktheexperts/faq/aboutspelling/email | title=What is the correct way to spell 'e' words such as 'email', 'ecommerce', 'egovernment'? | publisher=[[옥스퍼드 대학교 출판부]] | work=FAQ | access-date=4 September 2009 | author=AskOxford Language Query team | archive-url=https://web.archive.org/web/20080701194047/https://www.askoxford.com/asktheexperts/faq/aboutspelling/email?view=uk | quote=We recommend email, this is the common form | url-status=dead | archive-date=July 1, 2008}}</ref><ref>{{웹 인용|url=https://dictionary.reference.com/browse/email |title=Reference.com |publisher=Dictionary.reference.com |access-date=2014-01-09 |url-status=live |archive-url=https://web.archive.org/web/20131216094405/https://dictionary.reference.com/browse/email |archive-date=2013-12-16 }}</ref><ref name="cmos"/><ref>{{웹 인용|title="RFC Style Guide", Table of decisions on consistent use in RFC |url=https://www.rfc-editor.org/rfc-style-guide/terms-online.txt |url-status=live |archive-url=https://web.archive.org/web/20131228152111/https://www.rfc-editor.org/rfc-style-guide/terms-online.txt |archive-date=2013-12-28 |access-date=2014-01-09}}</ref>
* '''e-mail'''은 원래 편집된 출판물인 미국 영어 및 영국 영어 글쓰기에서 선호되는 형태였으며, 이전에는 일부 스타일 가이드에서 선호되었다.<ref name="cmos">{{웹 인용|title=From E-mail to Email: Is the Sky Falling? |url=https://cmosshoptalk.com/2017/10/11/from-e-mail-to-email-is-the-sky-falling/ |website=CMOS Shop Talk |publisher=[[시카고 매뉴얼 오브 스타일]] |access-date=18 September 2024 |date=11 October 2017}}</ref>
* '''E-mail'''이 때때로 사용된다.<ref>{{웹 인용|url=https://alt-usage-english.org/excerpts/fxhowdoy.html |title=How do you spell "e-mail"? |first1=Mark |last1=Israel |publisher=Alt-usage-english.org |access-date=2014-01-09 |url-status=live |archive-url=https://web.archive.org/web/20120403084841/https://www.alt-usage-english.org/excerpts/fxhowdoy.html |archive-date=2012-04-03 }}</ref> 1979년 6월, 원래 사용된 것은 [[일렉트로닉스 (잡지)|Electronics]] 저널에서 1970년대 후반에 개발되어 1980년대 초반에 운영된 [[미국 우정공단]]의 [[E-COM]]이라는 이니셔티브를 언급할 때였다.<ref name="Oxford English Dictionary 2012" /><ref name="Ohlheiser 2015" />
* '''EMAIL'''은 1981년 4월부터 [[컴퓨서브]]에서 사용되어 이 용어를 대중화시켰다.<ref>{{웹 인용|title=Did V.A. Shiva Ayyadurai Invent Email? |website= SIGCIS |author1=thaigh |date=2015 |url=https://www.sigcis.org/ayyadurai |access-date=2020-09-05 |archive-date=April 17, 2022 |archive-url=https://web.archive.org/web/20220417130400/https://www.sigcis.org/Ayyadurai |url-status=live }}</ref><ref>{{웹 인용|last=Masnick |first=Mike |title=Laying Out All The Evidence: Shiva Ayyadurai Did Not Invent Email |url=https://www.techdirt.com/articles/20190518/23370542236/laying-out-all-evidence-shiva-ayyadurai-did-not-invent-email.shtml |access-date=2020-09-05 |website=Techdirt. |date=May 22, 2019 |archive-date=January 27, 2022 |archive-url=https://web.archive.org/web/20220127173452/https://www.techdirt.com/articles/20190518/23370542236/laying-out-all-evidence-shiva-ayyadurai-did-not-invent-email.shtml |url-status=live }}</ref>
* '''EMail'''은 "Author's Address"에 대한 RFC에서 사용되는 전통적인 형태이다.

이 서비스는 종종 단순히 메일이라고 불리며, 단일 전자 메일은 메시지라고 불린다. 이메일 내 필드(예: "받는 사람", "보낸 사람", "참조", "숨은 참조" 등)에 대한 관례는 1975년 RFC-680부터 시작되었다.<ref>{{뉴스 인용|last=Pexton |first=Patrick B. |date=2012-03-01 |title=Origins of e-mail: My mea culpa |url=https://www.washingtonpost.com/blogs/omblog/post/origins-of-e-mail-my-mea-culpa/2012/03/01/gIQAiOD5kR_blog.html |url-access=subscription |access-date=2022-04-18 |newspaper=Washington Post |language=en-US |archive-date=May 19, 2022 |archive-url=https://web.archive.org/web/20220519192857/https://www.washingtonpost.com/blogs/omblog/post/origins-of-e-mail-my-mea-culpa/2012/03/01/gIQAiOD5kR_blog.html |url-status=live }}</ref>

인터넷 이메일은 봉투와 내용으로 구성된다.<ref>{{IETF 인용
 |       title = Simple Mail Transfer Protocol
 |         rfc = 5321
 |     section = 2.3.1
 | sectionname = Mail Objects
 |       quote = SMTP transports a mail object.  A mail object contains an envelope and content.
 |   publisher = [[국제 인터넷 표준화 기구|IETF]]
}}</ref> 내용은 헤더와 본문으로 구성된다.<ref>{{IETF 인용
 |       title = Simple Mail Transfer Protocol
 |         rfc = 5321
 |     section = 2.3.1
 | sectionname = Mail Objects
 |       quote = 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
 |   publisher = [[국제 인터넷 표준화 기구|IETF]]
}}</ref>

==역사==
{{앵커|Origin}}
{{본문|전자우편의 역사}}
동일 시스템 사용자 간의 컴퓨터 기반 메시징은 1960년대 초 [[시분할 시스템]]의 등장 이후 가능해졌으며, 1965년 [[매사추세츠 공과대학교|MIT]]의 [[호환 시분할 시스템|CTSS]] 프로젝트에서 주목할 만한 구현이 있었다.<ref>{{웹 인용|url=http://www.multicians.org/thvv/mail-history.html|title=The History of Electronic Mail|author=Tom Van Vleck|access-date=March 23, 2005|archive-date=December 2, 2017|archive-url=https://web.archive.org/web/20171202025034/http://www.multicians.org/thvv/mail-history.html|url-status=live}}</ref> 초기 [[메인프레임]] 및 [[미니컴퓨터]] 개발자 대부분은 유사하지만 일반적으로 호환되지 않는 메일 응용 프로그램을 개발했다. 1971년 첫 [[아파넷]] 네트워크 메일이 전송되었고, 현재 익숙한 [[골뱅이표|@]] 기호로 사용자의 시스템 주소를 지정하는 주소 구문이 도입되었다.<ref>{{웹 인용|author=Ray Tomlinson |url=https://openmap.bbn.com/~tomlinso/ray/firstemailframe.html |title=The First Network Email |publisher=Openmap.bbn.com |access-date=2019-10-05 |archive-date=May 6, 2006 |archive-url=https://web.archive.org/web/20060506003539/https://openmap.bbn.com/~tomlinso/ray/firstemailframe.html |url-status=dead }}</ref> 일련의 [[RFC]]를 통해 [[파일 전송 프로토콜]]을 통한 메일 메시지 전송 규칙이 정교화되었다.

독점적인 전자 메일 시스템이 곧 등장하기 시작했다. [[IBM]], [[컴퓨서브]] 및 [[제록스 스타|제록스]]는 1970년대에 사내 메일 시스템을 사용했으며, 컴퓨서브는 1978년에 IBM에, 1981년부터 제록스에 상업용 사무실 내 메일 제품을 판매했다.{{Refn|group=nb|IBM의 시스템은 공식 출시 이전에 고객에게 요청 시 제공되었다.}}<ref>{{서적 인용|last1=Gardner |first1=P. C. |year=1981 |title=A system for the automated office environment |journal=IBM Systems Journal |volume=20 |issue=3 |pages=321–345 |doi=10.1147/sj.203.0321 |issn=0018-8670 |postscript=none}}; {{웹 인용|date=2020-08-02 |title=IBM100 - The Networked Business Place |website=[[IBM]] |url=https://www.ibm.com/ibm/history/ibm100/us/en/icons/networkbus/ |url-status=live |archive-url=https://web.archive.org/web/20200802211021/https://www.ibm.com/ibm/history/ibm100/us/en/icons/networkbus/ |archive-date=2020-08-02 |access-date=2020-09-07}}</ref><ref>{{잡지 인용|author=Connie Winkler |date=October 22, 1979 |title=CompuServe pins hopes on MicroNET, InfoPlex |url=https://books.google.com/books?id=ChMAmfS1nEkC&dq=compuserve+Infoplex+1979&pg=PA69 |magazine=[[컴퓨터월드]] |volume=13 |issue=42 |page=69 |postscript=none}}; {{잡지 인용|author=Dylan Tweney |date=September 24, 1979 |title=Sept. 24, 1979: First Online Service for Consumers Debuts |url=https://www.wired.com/2009/09/0924compuserve-launches/ |magazine=[[와이어드 (잡지)|Wired]]}}</ref><ref>{{뉴스 인용|last=Ollig |first=Mark |date=October 31, 2011 |title=They could have owned the computer industry |work=Herald Journal |url=http://www.herald-journal.com/archives/2011/columns/mo103111.html |access-date=2021-02-26 |postscript=none |archive-date=February 27, 2021 |archive-url=https://web.archive.org/web/20210227062954/http://www.herald-journal.com/archives/2011/columns/mo103111.html |url-status=live }}; {{웹 인용|last= |date=15 February 2012 |title=Tech before its time: Xerox's shooting Star computer |url=https://www.newscientist.com/article/mg21328521-800-tech-before-its-time-xeroxs-shooting-star-computer/ |access-date=2022-04-18 |website=New Scientist |language=en-US |postscript=none |archive-date=April 18, 2022 |archive-url=https://web.archive.org/web/20220418181102/https://www.newscientist.com/article/mg21328521-800-tech-before-its-time-xeroxs-shooting-star-computer/ |url-status=live }}; {{웹 인용|title=The Xerox Star |url=http://toastytech.com/guis/star.html |access-date=2022-04-18 |website=toastytech.com |archive-date=July 18, 2011 |archive-url=https://web.archive.org/web/20110718030555/http://toastytech.com/guis/star.html |url-status=live }}</ref> DEC의 [[ALL-IN-1]]과 [[휴렛 팩커드]]의 HPMAIL (이후 HP DeskManager)은 1982년에 출시되었으며, 전자는 1970년대 후반에 개발 작업이 시작되었고 후자는 세계에서 가장 많이 팔린 이메일 시스템이 되었다.<ref>{{웹 인용|date=1998-01-30 |title=ALL-IN-1 |url=https://research.microsoft.com/en-us/um/people/gbell/Digital/timeline/1982-4.htm |work=DIGITAL Computing Timeline |access-date=April 20, 2022 |archive-date=January 3, 2017 |archive-url=https://web.archive.org/web/20170103002807/https://research.microsoft.com/en-us/um/people/gbell/Digital/timeline/1982-4.htm |url-status=live }}</ref><ref>{{웹 인용|title=HP Computer Museum |url=http://www.hpmuseum.net/divisions.php?did=10 |access-date=November 10, 2016 |archive-date=September 9, 2016 |archive-url=https://web.archive.org/web/20160909011243/http://www.hpmuseum.net/divisions.php?did=10 |url-status=live }}</ref>

[[간이 우편 전송 프로토콜|Simple Mail Transfer Protocol]] (SMTP)은 1983년 [[아파넷]]에 구현되었다. [[근거리 통신망|LAN]] 이메일 시스템은 1980년대 중반에 등장했다. 1980년대 후반부터 1990년대 초반까지 한동안 독점 상용 시스템 또는 [[X.400]] 이메일 시스템 (GOSIP (Government Open Systems Interconnection Profile)의 일부)이 지배적일 것으로 보였다. 그러나 인터넷을 통한 상업 트래픽 운반에 대한 최종 제한이 1995년에 해제되자,<ref>[https://merit.edu/research/nsfnet_article.php "Retiring the NSFNET Backbone Service: Chronicling the End of an Era"] {{웹아카이브|url=https://web.archive.org/web/20160101025735/https://merit.edu/research/nsfnet_article.php |date=2016-01-01 }}, Susan R. Harris, Ph.D., and Elise Gerich, ConneXions, Vol. 10, No. 4, April 1996</ref><ref>{{웹 인용| url= https://www.walthowe.com/navnet/history.html | title= A Brief History of the Internet | url-status= live | archive-url= https://web.archive.org/web/20150811053448/https://www.walthowe.com/navnet/history.html | archive-date= 2015-08-11 | bibcode= 1999cs........1011L | last1= Leiner | first1= Barry M. | last2= Cerf | first2= Vinton G. | last3= Clark | first3= David D. | last4= Kahn | first4= Robert E. | last5= Kleinrock | first5= Leonard | last6= Lynch | first6= Daniel C. | last7= Postel | first7= Jon | last8= Roberts | first8= Larry G. | last9= Wolf | first9= Stephen | year= 1999 | arxiv= cs/9901011 }}</ref> 여러 요인이 결합되어 SMTP, [[포스트 오피스 프로토콜|POP3]] 및 [[인터넷 메시지 접속 프로토콜|IMAP]] 이메일 프로토콜의 현재 인터넷 스위트가 표준이 되었다( [[프로토콜 전쟁]] 참조).<ref>{{학위논문 인용|last=Rutter |first=Dorian |title=From Diversity to Convergence: British Computer Networks and the Internet, 1970-1995 |date=2005 |degree=Computer Science |publisher=The University of Warwick |url=http://wrap.warwick.ac.uk/1197/1/WRAP_THESIS_Rutter_2005.pdf |access-date=December 23, 2022 |archive-date=October 10, 2022 |archive-url=https://ghostarchive.org/archive/20221010/http://wrap.warwick.ac.uk/1197/1/WRAP_THESIS_Rutter_2005.pdf |url-status=live }}</ref><ref>{{서적 인용|last1=Campbell-Kelly |first1=Martin |last2=Garcia-Swartz |first2=Daniel D |date=2013 |title=The History of the Internet: The Missing Narratives |url=https://papers.ssrn.com/abstract=867087 |journal=Journal of Information Technology |language=en |volume=28 |issue=1 |pages=18–33 |doi=10.1057/jit.2013.4 |ssrn=867087 |s2cid=41013 |issn=0268-3962|url-access=subscription }}</ref>

==작동 방식==
다음은 발신자 [[플레이스홀더 이름 (암호학)|앨리스]]가 수신자의 [[전자우편 주소]]로 지정된 [[이메일 클라이언트|메일 사용자 에이전트]] (MUA)를 사용하여 메시지를 전송할 때 발생하는 일반적인 일련의 이벤트이다.<ref>{{영상 인용|title=How E-mail Works|publisher=howstuffworks.com|year=2008|url=https://computer.howstuffworks.com/e-mail-messaging/email.htm|url-status=live|archive-url=https://web.archive.org/web/20170611181852/https://computer.howstuffworks.com/e-mail-messaging/email.htm|archive-date=2017-06-11}}</ref>

[[파일:email.svg|섬네일|이메일 작동 방식]]
# 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이다.<ref>[https://dnsdb.cit.cornell.edu/explain_mx.html "MX Record Explanation"] {{웹아카이브|url=https://web.archive.org/web/20150117204846/https://dnsdb.cit.cornell.edu/explain_mx.html |date=2015-01-17 }}, it.cornell.edu</ref>
# 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를 [[오픈 메일 릴레이]]라고 불렀다. 이것은 네트워크 연결이 불안정했던 인터넷 초기에 매우 중요했다.<ref>{{웹 인용|url=https://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci782509,00.html |title=What is open relay? |access-date=2008-04-07 |date=2004-07-19 |work=WhatIs.com |publisher=[[인디애나 대학교]] |archive-url=https://web.archive.org/web/20070824005337/https://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci782509,00.html |archive-date=2007-08-24 }}</ref><ref>{{서적 인용|author=Ch Seetha Ram|title=Information Technology for Management|url=https://books.google.com/books?id=0bHAGrUxqRsC&pg=PA164|year=2010|publisher=Deep & Deep Publications|isbn=978-81-8450-267-1|page=164}}</ref> 그러나 이 메커니즘은 [[스팸 메일|원치 않는 대량 이메일]] 발신자에게 악용될 수 있음이 입증되었고, 그 결과 오픈 메일 릴레이는 드물게 되었으며,<ref>{{웹 인용|url=https://www.imc.org/ube-relay.html |title=Allowing Relaying in SMTP: A Series of Surveys |access-date=2008-04-13 |last=Hoffman |first=Paul |date=2002-08-20 |work=IMC Reports |publisher=[[Internet Mail Consortium]] |archive-url=https://web.archive.org/web/20070118121843/https://www.imc.org/ube-relay.html |archive-date=2007-01-18 }}</ref> 많은 MTA는 오픈 메일 릴레이로부터 메시지를 수락하지 않는다.

이메일은 [[인스턴트 메신저]]보다 앞서며, 신뢰할 수 없는 네트워크 링크와 바쁜 서버(인터넷 초기에 더 흔했음)에 대처하기 위해 속도보다 신뢰성을 선호한다. 느린 배송의 이유는 다음과 같다.<ref name="luxsci">{{웹 인용|url=https://luxsci.com/blog/why-email-is-not-instantaneous-and-not-supposed-to-be.html|title=Why Email is Not Instantaneous -- and Not Supposed to Be|date=October 15, 2013}}</ref>
* 많은 수의 수신자에게 보내는 메시지는 더 많은 처리가 필요하다.
* 대용량 메시지(예: 대용량 첨부 파일 포함)는 네트워크를 통해 전송하는 데 더 많은 시간이 걸린다.
* 메시지는 여러 서버(때로는 같은 조직 내의 여러 서버)를 통과해야 한다.
* 하나 이상의 메일 서버가 과부하(아마도 [[스팸 메일|스팸]] 또는 [[서비스 거부 공격]]으로 인해)되어 수신 메일을 대기열에 넣거나 일시적으로 수신 연결을 거부한다.
* [[간이 우편 전송 프로토콜|SMTP]]는 여러 번의 왕복 통신을 요구하며, 이는 느린 네트워크나 손실된 패킷의 영향을 증폭시킬 수 있다.
* 발신자 또는 수신자가 일시적으로 네트워크에서 연결이 끊긴 경우(예: 노트북이 Wi-Fi 범위 밖에 있는 경우)
* 느린 DNS 응답
* 유지 보수 또는 오작동으로 인한 서버 다운

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

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

==메시지 형식 {{앵커|Internet Message Format}}==
이메일에 사용되는 기본 인터넷 메시지 형식<ref>인터넷 메시지 형식은 [[유즈넷|네트워크 뉴스]]에도 사용된다</ref>은 {{IETF RFC|5322}}에 의해 정의되며, 비-ASCII 데이터 및 멀티미디어 콘텐츠 첨부 파일의 인코딩은 RFC 2045부터 RFC 2049까지, 총칭하여 [[MIME|Multipurpose Internet Mail Extensions]] 또는 MIME으로 정의된다. [[국제 이메일]]의 확장 기능은 이메일에만 적용된다. RFC 5322는 2008년에 RFC 2822를 대체했다. 이전에 2001년에 RFC 2822는 수십 년 동안 인터넷 이메일 표준이었던 RFC 822를 대체했다. 1982년에 발표된 RFC 822는 초기 [[아파넷]]용 RFC 733을 기반으로 했다.<ref>{{웹 인용|first=Ken|last=Simpson|title=An update to the email standards|date=October 3, 2008|publisher=MailChannels Blog Entry|url=https://blog.mailchannels.com/2008/10/update-to-email-standards.html|url-status=live|archive-url=https://web.archive.org/web/20081006080735/https://blog.mailchannels.com/2008/10/update-to-email-standards.html|archive-date=October 6, 2008}}</ref>

인터넷 이메일 메시지는 "헤더"와 "본문"의 두 부분으로 구성된다. 이를 "콘텐츠"라고 부른다.<ref>{{IETF 인용
| rfc = 5321
| title = Simple Mail Transfer Protocol
| date = October 2008
| author = J. Klensin
| section = 2.3.1
| sectionname = Mail Objects
| quote = 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.
| mode = cs2
}}</ref><ref>{{IETF 인용
| rfc = 5598
| title = Internet Mail Architecture
| date = July 2009
| author = D. Crocker
| section = 4.1
| sectionname = Message Data
| quote = 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.
| mode = cs2
}}</ref> 헤더는 From, To, CC, Subject, Date 및 이메일에 대한 기타 정보와 같은 [[필드 (컴퓨터 과학)|필드]]로 구성된다. 시스템 간에 이메일 메시지를 전송하는 과정에서 SMTP는 메시지 헤더 필드를 사용하여 전송 매개변수 및 정보를 통신한다. 본문은 메시지를 비구조화된 텍스트로 포함하며, 때로는 끝에 [[서명 블록]]이 포함될 수 있다. 헤더는 빈 줄로 본문과 구분된다.

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

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

====헤더 필드====
이메일 헤더 필드는 여러 줄로 구성될 수 있으며, 각 줄은 78자를 넘지 않도록 권장되지만 제한은 998자이다.{{Ref RFC|5322}} RFC 5322에서 정의된 헤더 필드에는 [[US-ASCII]] 문자만 포함된다. 다른 세트의 문자를 인코딩하기 위해 RFC 2047에 지정된 구문을 사용할 수 있다.{{Ref RFC|2047}} 일부 예시에서 IETF EAI 워킹 그룹은 이전 실험적 확장을 대체하는 일부 표준 트랙 확장을 정의하므로{{Ref RFC|6532}}{{Ref RFC|6531}} [[UTF-8]]로 인코딩된 [[유니코드]] 문자를 헤더 내에서 사용할 수 있다. 특히, 이는 이메일 주소가 비-ASCII 문자를 사용할 수 있도록 허용한다. 이러한 주소는 구글 및 마이크로소프트 제품에서 지원되며 일부 정부 기관에서 홍보한다.<ref>{{뉴스 인용|url=https://economictimes.indiatimes.com/tech/internet/now-get-your-email-address-in-hindi/articleshow/53830034.cms|title=Now, get your email address in Hindi - The Economic Times|newspaper=The Economic Times|access-date=2016-10-17|url-status=live|archive-url=https://web.archive.org/web/20160828044631/https://economictimes.indiatimes.com/tech/internet/now-get-your-email-address-in-hindi/articleshow/53830034.cms|archive-date=2016-08-28}}</ref>

메시지 헤더에는 최소한 다음 필드가 포함되어야 한다.<ref>{{IETF 인용|rfc=5322|section=3.6 |title=Internet Message Format|sectionname=Field Definitions |date=October 2008 |access-date=2014-01-09  |editor-first1=P |editor-last1=Resnick  }}</ref><ref>{{IETF 인용|rfc=5322|section=3.6.4 |title=Internet Message Format|sectionname=Identification Fields  |date=October 2008 |access-date=2014-01-09  |editor-first1=P |editor-last1=Resnick  }}</ref>
* From: 발신자의 이메일 주소 및 선택적으로 이름. 일부 이메일 클라이언트는 계정 설정을 통해 변경 가능하다.
* Date: 메시지가 작성된 현지 시간 및 날짜. From: 필드와 마찬가지로, 많은 이메일 클라이언트가 전송 전에 이 정보를 자동으로 채운다. 수신자의 클라이언트는 시간을 현지 형식과 시간대로 표시할 수 있다.

RFC 3864는 [[IANA|Internet Assigned Numbers Authority]]에 메시지 헤더 필드 등록 절차를 설명한다. MIME, 유즈넷 및 HTTP에 정의된 필드를 포함하고 관련 RFC를 참조하여 [https://www.iana.org/assignments/message-headers/perm-headers.html 영구] 및 [https://www.iana.org/assignments/message-headers/prov-headers.html 임시] 필드 이름을 제공한다. 이메일에 대한 일반적인 헤더 필드는 다음과 같다.{{Ref RFC|5064}}
* 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 필드를 따른다.<ref>Microsoft, Auto Response Suppress, 2010, [https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx Microsoft reference] {{웹아카이브|url=https://web.archive.org/web/20110407033540/https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx |date=2011-04-07 }}, 2010 Sep 22</ref>
* [[메시지 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는 다음 두 필드를 사용하여 헤더에 저장된 메시지의 추적 정보를 정의한다.<ref>{{IETF 인용|title=Simple Mail Transfer Protocol|rfc=5321|author=[[존 클렌신]]|sectionname=Trace Information|section=4.4| date=October 2008 |publisher=[[국제 인터넷 표준화 기구|IETF]]}}</ref>
* Received: SMTP 서버가 메시지를 수락한 후, 이 추적 레코드를 헤더 상단에 삽입한다(가장 나중에 온 것이 가장 먼저 온다).
* Return-Path: 전달 SMTP 서버가 메시지를 최종적으로 전달한 후, 이 필드를 헤더 상단에 삽입한다.

수신 서버에 의해 헤더 상단에 추가되는 다른 필드는 추적 필드라고 불릴 수 있다.<ref>{{웹 인용|url=https://www.ietf.org/mail-archive/web/apps-discuss/current/msg04115.html|title=Trace headers|author=John Levine|date=14 January 2012|work=email message|publisher=[[국제 인터넷 표준화 기구|IETF]]|access-date=16 January 2012|quote=there are many more trace fields than those two|url-status=live|archive-url=https://web.archive.org/web/20120811135249/https://www.ietf.org/mail-archive/web/apps-discuss/current/msg04115.html|archive-date=11 August 2012}}</ref>
* Authentication-Results: 서버가 인증을 확인한 후, 이 필드에 결과를 저장하여 다운스트림 에이전트가 사용할 수 있도록 할 수 있다.<ref>이 확장 가능한 필드는 {{IETF RFC|7001}}에 정의되어 있으며, 이는 [[IANA|Internet Assigned Numbers Authority]]의 [https://www.iana.org/assignments/email-auth/ Email Authentication Parameters] 등록도 정의한다.</ref>
* Received-SPF: [[전송자 정책 프레임워크|SPF]] 확인 결과를 Authentication-Results보다 더 자세히 저장한다.<ref>{{IETF RFC|7208}}.</ref>
* DKIM-Signature: 메시지가 전송된 후 변경되지 않았음을 확인하기 위해 [[DKIM|DomainKeys Identified Mail]] (DKIM) 해독 결과를 저장한다.{{Ref RFC|6376}}
* Auto-Submitted: 자동 생성된 메시지를 표시하는 데 사용된다.<ref>Defined in {{IETF RFC|3834}}, and updated by {{IETF RFC|5436}}.</ref>
* VBR-Info: [[Vouch by Reference|VBR]] 화이트리스트를 주장한다.<ref>{{IETF RFC| 5518}}.</ref>

===메시지 본문===

====콘텐츠 인코딩====
인터넷 이메일은 7비트 ASCII용으로 설계되었다.<ref>{{서적 인용|title=TCP/IP Network Administration|year=2002|isbn=978-0-596-00297-8|author=Craig Hunt|publisher=[[오라일리 미디어]]|page=70}}</ref> 대부분의 이메일 소프트웨어는 [[8비트 클린]]하지만, 7비트 서버 및 메일 리더와 통신할 것이라고 가정해야 한다. [[MIME]] 표준은 문자 세트 지정자와 두 가지 콘텐츠 전송 인코딩을 도입하여 비 ASCII 데이터 전송을 가능하게 했다. [[Quoted-printable]]은 주로 7비트 콘텐츠에 범위 밖의 몇 문자가 있는 경우에 사용되며, [[베이스64]]는 임의의 이진 데이터에 사용된다. [[8BITMIME]] 및 [[BINARY]] 확장은 이러한 인코딩 없이 메일 전송을 허용하기 위해 도입되었지만, 많은 [[메일 전송 에이전트]]는 이를 지원하지 않을 수 있다. 일부 국가에서는 이메일 소프트웨어가 {{IETF RFC|5322}}를 위반하여 원시<ref group=nb>국제 이메일 또는 MIME을 사용하지 않음</ref> 비 ASCII 텍스트를 전송하며 여러 인코딩 체계가 공존한다. 결과적으로 기본적으로 비 라틴어 알파벳 언어의 메시지는 읽을 수 없는 형태로 나타난다(유일한 예외는 발신자와 수신자가 동일한 인코딩 체계를 사용하는 경우의 우연이다). 따라서 국제 [[문자 집합]]의 경우 [[유니코드]]의 인기가 높아지고 있다.<ref>{{웹 인용|title=What is unicode? |url=https://www.konfinity.com/what-is-unicode|access-date=2022-01-31|website=Konfinity |archive-date=January 31, 2022|archive-url=https://web.archive.org/web/20220131083432/https://www.konfinity.com/what-is-unicode|url-status=live}}</ref>

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

HTML의 장점은 인라인 링크 및 이미지를 포함하고, [[블록 인용]]으로 이전 메시지를 구분하고, 모든 디스플레이에서 자연스럽게 줄 바꿈하고, [[밑줄]] 및 [[이탤릭체]]와 같은 강조를 사용하고, [[글꼴]] 스타일을 변경할 수 있다는 점이다. 단점은 이메일 크기 증가, [[웹 버그]]에 대한 개인 정보 보호 문제, 피싱 공격 및 [[악성 소프트웨어]] 확산을 위한 벡터로서 HTML 이메일의 남용 등이 있다.<ref>{{웹 인용|url=https://advosys.ca/papers/mail-policies.html|title=Email policies that prevent viruses|archive-url=https://web.archive.org/web/20070512053927/https://advosys.ca/papers/mail-policies.html |website=Advosys Consulting | archive-date=2007-05-12|url-status=dead}}</ref>
일부 이메일 클라이언트는 `Content-Type: html` 헤더 필드가 없는 경우에도 본문을 HTML로 해석하며, 이로 인해 다양한 문제가 발생할 수 있다.

일부 웹 기반 [[메일링 리스트]]는 위에 언급된 모든 이유로 모든 게시물을 [[문자당 72자]] 또는 80자로 된 [[플레인 텍스트]]로 작성할 것을 권장하며,<ref>{{웹 인용|url=https://helpdesk.rootsweb.com/listadmins/plaintext.html |quote=When posting to a RootsWeb mailing list, your message should be sent as "plain  text." |publisher=RootsWeb HelpDesk |title=Problem Solving: Sending Messages in Plain Text |access-date=2014-01-09 |url-status=dead |archive-url=https://web.archive.org/web/20140219024856/https://helpdesk.rootsweb.com/listadmins/plaintext.html |archive-date=2014-02-19 }}</ref><ref>{{웹 인용|url=https://www.openbsd.org/mail.html |title= OpenBSD Mailing Lists |quote=Plain text, 72 characters per line |publisher=OpenBSD |access-date=2014-01-09 |url-status=live |archive-url=https://web.archive.org/web/20140208005706/https://openbsd.org/mail.html |archive-date=2014-02-08 }}</ref> [[Mutt]]와 같은 [[이메일 클라이언트 비교#텍스트 기반|텍스트 기반 이메일 클라이언트]]를 사용하는 상당수의 독자가 있기 때문이기도 하다.
이메일 및 [[유즈넷]] 게시물에서 플레인 텍스트를 마크업하기 위한 다양한 비공식 관례가 발전했으며, 이는 나중에 [[setext]] (c. 1992) 및 [[가벼운 마크업 언어|기타 여러 언어]]와 같은 공식 언어의 개발로 이어졌고, 그 중 가장 인기 있는 것은 [[마크다운]]이다.

일부 [[마이크로소프트]] 이메일 클라이언트는 독점적인 [[서식 있는 텍스트 포맷|Rich Text Format]] (RTF)을 사용하여 풍부한 서식 지정을 허용할 수 있지만, 수신자가 호환되는 이메일 클라이언트를 가지고 있다는 보장이 없는 한 이는 피해야 한다.<ref>{{웹 인용|url=https://support.microsoft.com/kb/138053 |title=Verhindern, dass die Datei "Winmail.dat" an Internetbenutzer gesendet wird |trans-title=How to Prevent the Winmail.dat File from Being Sent to Internet Users |publisher=Microsoft Support |date=2010-07-02 |access-date=2014-01-09 |url-status=dead |archive-url=https://web.archive.org/web/20140109193922/https://support.microsoft.com/kb/138053 |archive-date=2014-01-09 }}</ref>

==서버 및 클라이언트 애플리케이션==
[[파일:Mozilla Thunderbird 3.1.png|섬네일|[[모질라 선더버드|썬더버드]] [[이메일 클라이언트]]의 인터페이스]]
메시지는 [[메일 전송 에이전트]] (MTA)라고 불리는 소프트웨어 프로그램을 사용하여 [[간이 우편 전송 프로토콜|Simple Mail Transfer Protocol]]을 통해 호스트 간에 교환되며, [[메일 전달 에이전트]] (MDA, 때로는 로컬 전달 에이전트, LDA라고도 함)라고 불리는 프로그램에 의해 메일 저장소로 전달된다. 메시지를 수락하는 것은 MTA가 메시지를 전달해야 할 의무를 지게 하며,<ref>실제로는 수락된 일부 메시지가 수신자의 받은 편지함으로 전달되지 않고, 특히 기업 환경에서 수신자가 접근할 수 없는 스팸 또는 정크 폴더로 전달될 수 있다.</ref> 메시지를 전달할 수 없는 경우 해당 MTA는 문제점을 나타내는 [[반송 메시지]]를 발신자에게 다시 보내야 한다.

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

이메일을 열면 "읽음"으로 표시되며, 이는 일반적으로 클라이언트의 사용자 인터페이스에서 "읽지 않음" 메시지와 시각적으로 구분된다. 이메일 클라이언트는 읽은 이메일을 받은 편지함에서 숨겨 사용자가 읽지 않은 이메일에 집중할 수 있도록 할 수 있다.<ref>{{웹 인용|title=View only unread messages |url=https://support.microsoft.com/en-us/office/view-only-unread-messages-f2c8450c-9cd0-4037-a5d3-26f6946727ca |website=support.microsoft.com |access-date=November 13, 2021 |archive-date=November 13, 2021 |archive-url=https://web.archive.org/web/20211113164358/https://support.microsoft.com/en-us/office/view-only-unread-messages-f2c8450c-9cd0-4037-a5d3-26f6946727ca |url-status=live }}</ref>

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

많은 현재 이메일 사용자들은 MTA, MDA 또는 MUA 프로그램을 직접 실행하지 않고, [[Gmail]] 또는 [[Yahoo! Mail]]과 같은 웹 기반 이메일 플랫폼을 사용하여 동일한 작업을 수행한다.<ref>{{웹 인용|url=https://dir.yahoo.com/business_and_economy/business_to_business/communications_and_networking/internet_and_world_wide_web/email_providers/free_email/|title=Free Email Providers in the Yahoo! Directory|website=dir.yahoo.com|archive-url=https://web.archive.org/web/20140704154604/https://dir.yahoo.com/business_and_economy/business_to_business/communications_and_networking/internet_and_world_wide_web/email_providers/free_email/|archive-date=2014-07-04|url-status=dead}}</ref> 이러한 [[웹 메일]] 인터페이스를 통해 사용자들은 로컬 이메일 클라이언트에 의존하는 대신, 어떤 표준 [[웹 브라우저]]로든 어떤 컴퓨터에서든 자신의 메일에 접근할 수 있다.

===파일 확장자===
이메일 메시지를 수신하면 이메일 클라이언트 응용 프로그램은 파일 시스템의 운영 체제 파일에 메시지를 저장한다. 일부 클라이언트는 개별 메시지를 별도의 파일로 저장하는 반면, 다른 클라이언트는 집단 저장을 위해 다양한 데이터베이스 형식(종종 독점 형식)을 사용한다. mbox 형식은 역사적인 저장 표준이다. 사용되는 특정 형식은 종종 특별한 [[파일 확장자]]로 표시된다:
;<code>eml</code>
: [[노벨 그룹와이즈]], [[아웃룩 익스프레스|마이크로소프트 아웃룩 익스프레스]], [[Lotus notes]], [[윈도우 메일]], [[모질라 선더버드]], 그리고 Postbox를 포함한 많은 이메일 클라이언트에서 사용된다. 이 파일들은 이메일 헤더와 본문을 포함하는 [[MIME]] 형식의 [[플레인 텍스트]]로 이메일 내용을 포함하며, 여러 형식 중 하나 이상의 첨부 파일을 포함한다.
;<code>emlx</code>
: [[메일 (애플)|Apple Mail]]에서 사용된다.
;<code>msg</code>
: [[마이크로소프트 아웃룩|마이크로소프트 오피스 아웃룩]] 및 [[OfficeLogic|OfficeLogic Groupware]]에서 사용된다.
;<code>mbx</code>
: 오페라 메일, [[KMail]], 그리고 mbox 형식을 기반으로 한 [[메일 (애플)|Apple Mail]]에서 사용된다.

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

===URI 스킴 mailto===
{{본문|Mailto}}
IANA에 등록된 [[URI 스킴]]은 SMTP 전자우편 주소에 대한 <code>mailto:</code> 스킴을 정의한다. 비록 사용이 엄격하게 정의되어 있지는 않지만, 이 형식의 URL은 URL이 활성화될 때 사용자의 메일 클라이언트의 새 메시지 창을 열고, To: 필드에 URL에 정의된 주소를 채우도록 의도되었다.<ref>RFC 2368 section 3 : by Paul Hoffman in 1998 discusses operation of the "mailto" URL.</ref><ref name="Barnett 2011 p. 245" /> 많은 클라이언트는 제목 줄이나 참조 수신자와 같은 다른 이메일 필드에 대한 쿼리 문자열 매개변수도 지원한다.<ref>{{웹 인용|url=https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks|title=Creating hyperlinks § E-mail links|website=MDN Web Docs|language=en|access-date=2019-09-30|archive-date=August 18, 2019|archive-url=https://web.archive.org/web/20190818224233/https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks|url-status=live}}</ref>

==유형==

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

===POP3 이메일 서버===
[[포스트 오피스 프로토콜]] 3 (POP3)은 클라이언트 응용 프로그램이 메일 서버에서 메시지를 읽는 데 사용하는 메일 액세스 프로토콜이다. 수신된 메시지는 종종 [[서버]]에서 삭제된다. POP는 원격 사서함(POP RFC에서 메일드롭이라고 함)에 액세스하기 위한 간단한 다운로드-및-삭제 요구 사항을 지원한다.<ref>{{서적 인용| last = Allen | first = David | title = Windows to Linux | publisher = Prentice Hall | year = 2004 | page = 192 | url = https://books.google.com/books?id=UD0h_GqgbHgC&q=network%2B+guide+to+networks | url-status = live | archive-url = https://web.archive.org/web/20161226051835/https://books.google.com/books?id=UD0h_GqgbHgC&printsec=frontcover&dq=network%2B+guide+to+networks&ct=result&resnum=1 | archive-date = 2016-12-26 | isbn = 978-1423902454 }}</ref> POP3는 로컬 컴퓨터에 메시지를 다운로드하여 오프라인 상태에서도 읽을 수 있도록 한다.<ref>{{IETF 인용
 |         rfc = 1733
 |       title = DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
 |     section = 4.5.
 | sectionname = Implementation and Operation
  }}
</ref><ref>{{IETF 인용
 |         rfc = 5598
 |       title = Internet Mail Architecture
 |     section = 4.2.2.
 | sectionname = Message Store (MS)
  }}
</ref>

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

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

==용도==

===비즈니스 및 조직 사용===
이메일은 선진국의 기업, 정부 및 비정부 조직에 의해 널리 채택되었으며, 직장 통신에서 '전자 혁명'의 핵심 부분 중 하나이다(다른 핵심 부분은 고속 [[인터넷]]의 광범위한 채택). 2010년 직장 통신에 대한 후원 연구에 따르면 미국 지식 근로자의 83%가 이메일이 업무 성공 및 생산성에 매우 중요하다고 느꼈다.<ref>By Om Malik, GigaOm. "[https://gigaom.com/collaboration/is-email-a-curse-or-a-boon/ Is Email a Curse or a Boon?] {{웹아카이브|url=https://web.archive.org/web/20101204012735/https://gigaom.com/collaboration/is-email-a-curse-or-a-boon/ |date=2010-12-04 }}" September 22, 2010. Retrieved October 11, 2010.</ref>

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

====이메일 마케팅====
"[[옵트인]]"을 통한 [[이메일 마케팅]]은 종종 특별 할인 행사 및 신제품 정보를 보내는 데 성공적으로 사용된다.<ref>{{서적 인용| last1 = Martin | first1 = Brett A. S. | last2 = Van Durme | first2 = Joel | last3 = Raulas | first3 = Mika | last4 = Merisavo | first4 = Marko | year = 2003 | title = E-mail Marketing: Exploratory Insights from Finland | url = https://www.basmartin.com/wp-content/uploads/2010/08/Martin-et-al-2003.pdf | journal = Journal of Advertising Research | volume = 43 | issue = 3 | pages = 293–300 | doi = 10.1017/s0021849903030265 | url-status = live | archive-url = https://web.archive.org/web/20121021150626/https://www.basmartin.com/wp-content/uploads/2010/08/Martin-et-al-2003.pdf | archive-date = 2012-10-21 | issn=0021-8499}}</ref> 수신자의 문화에 따라<ref>{{웹 인용|url=https://www.computerworld.com/article/2467778/endpoint-security/spam-culture--part-1--china.html|title=Spam culture, part 1: China|first=Amir|last=Lev|url-status=live|archive-url=https://web.archive.org/web/20161110174233/https://www.computerworld.com/article/2467778/endpoint-security/spam-culture--part-1--china.html|archive-date=2016-11-10|date=2009-10-02}}</ref> 허가 없이 보낸 이메일(예: "옵트인" 이메일이 아닌 경우)은 환영받지 못하는 "[[스팸 메일]]"로 간주될 가능성이 높다.

===개인적인 용도===

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

====모바일====
이메일은 [[스마트폰]]과 모든 유형의 컴퓨터에서 사용되고 있다. 이메일용 모바일 "앱"은 집 밖에 있는 사용자의 매체 접근성을 높인다. 이메일 초기에는 사용자들이 데스크톱 컴퓨터에서만 이메일에 접속할 수 있었지만, 2010년대에는 집을 떠나서도, 다른 도시나 전 세계 어디에서든 이메일을 확인할 수 있게 되었다. 새로운 메시지가 오면 스마트폰이나 다른 기기로 알림을 보낼 수도 있다. 이는 이메일이 사용자 간에 더 빈번한 통신에 사용될 수 있게 해주었고, 하루 종일 이메일을 확인하고 메시지를 작성할 수 있게 해주었다. {{as of|2011}} 전 세계적으로 약 14억 명의 이메일 사용자가 있었고, 하루에 500억 통의 스팸이 아닌 이메일이 전송되었다.<ref name="Barnett 2011 p. 245">{{서적 인용|last1=Hansen |first1=Derek |last2=Smith |first2=Marc A. |last3=Heer |author-link3=Jeffrey Heer |chapter=E-Mail |chapter-url=https://books.google.com/books?id=fCfrCgAAQBAJ&pg=PA245 |editor1-last=Barnett |editor1-first=George A |title=Encyclopedia of social networks |publisher=Sage |location=Thousand Oaks, Calif |year=2011 |isbn=9781412994170 |page=245 |oclc=959670912}}</ref>

개인들은 종종 개인 및 업무 관련 메시지 모두를 위해 스마트폰으로 이메일을 확인한다. 미국 성인들은 웹을 탐색하거나 [[페이스북]] 계정을 확인하는 것보다 이메일을 더 많이 확인하는 것으로 나타났으며, 이메일은 스마트폰 사용자에게 가장 인기 있는 활동이 되었다. 연구 응답자의 78%는 스마트폰으로 이메일을 확인한다고 밝혔다.<ref>{{웹 인용|url=https://marketingland.com/smartphone-activities-study-email-web-facebook-37954|title=Email Is Top Activity On Smartphones, Ahead Of Web Browsing & Facebook [Study]|date=28 March 2013|url-status=live|archive-url=https://web.archive.org/web/20140429184034/https://marketingland.com/smartphone-activities-study-email-web-facebook-37954|archive-date=29 April 2014}}</ref> 또한 소비자의 30%가 스마트폰만으로 이메일을 확인하며, 91%는 스마트폰으로 하루에 최소 한 번 이상 이메일을 확인할 가능성이 높은 것으로 나타났다. 그러나 스마트폰에서 이메일을 사용하는 소비자의 비율은 국가마다 크게 다르다. 예를 들어, 미국 소비자의 75%가 사용하는 반면, 인도에서는 17%만이 사용했다.<ref>{{웹 인용|url=https://www.emailmonday.com/mobile-email-usage-statistics|title=The ultimate mobile email statistics overview|url-status=live|archive-url=https://web.archive.org/web/20140711160527/https://www.emailmonday.com/mobile-email-usage-statistics|archive-date=2014-07-11}}</ref>

====젊은층의 사용 감소====
{{as of|2010}}, 이메일 웹사이트를 방문하는 미국인의 수는 2009년 11월에 정점을 찍은 후 6% 감소했다. 12세에서 17세 사이의 경우, 이 수치는 18% 감소했다. 젊은 사람들은 [[인스턴트 메신저]], [[문자 메시지]] 및 [[소셜 미디어]]를 선호했다. 기술 작가 맷 리첼은 [[뉴욕 타임스]]에서 이메일이 [[VCR]], [[바이닐 음반]] 및 [[스틸 카메라|필름 카메라]]와 같으며, 더 이상 멋지지 않고 나이 든 사람들이 하는 것이라고 말했다.<ref>{{뉴스 인용|url=https://www.nytimes.com/2010/12/21/technology/21email.html |url-access=subscription |title=E-Mail Gets an Instant Makeover|last=Richtel|first=Matt|work=[[뉴욕 타임스]]|date=2010-12-20|access-date=2018-04-04|archive-date=April 5, 2018|archive-url=https://web.archive.org/web/20180405033137/https://www.nytimes.com/2010/12/21/technology/21email.html|url-status=live}}</ref><ref>{{뉴스 인용|url=https://www.theatlantic.com/technology/archive/2010/12/why-are-young-people-abandoning-email/339329/ |url-access=subscription |title=Why Are Young People Abandoning Email?|last=Gustini|first=Ray|work=[[디 애틀랜틱]]|date=2010-12-21|access-date=2018-04-04|archive-date=April 5, 2018|archive-url=https://web.archive.org/web/20180405024822/https://www.theatlantic.com/technology/archive/2010/12/why-are-young-people-abandoning-email/339329/|url-status=live}}</ref>

2015년 [[안드로이드 (운영체제)|안드로이드]] 사용자 설문조사에 따르면, 13세에서 24세 사이의 사람들은 45세 이상의 사람들보다 메시징 [[모바일 앱]]을 3.5배 더 많이 사용했으며, 이메일을 사용할 가능성이 훨씬 낮았다.<ref>{{뉴스 인용|url=https://techcrunch.com/2016/03/24/email-is-dying-among-mobiles-youngest-users/|title=Email is dying among mobile's youngest users|last=Perez|first=Sarah|work=TechCrunch |date=2016-03-24|access-date=2018-04-04|archive-date=April 5, 2018|archive-url=https://web.archive.org/web/20180405025214/https://techcrunch.com/2016/03/24/email-is-dying-among-mobiles-youngest-users/|url-status=live}}</ref>

==문제점==

===첨부 파일 크기 제한===
{{본문|첨부 파일}}
이메일 메시지에는 하나 이상의 [[첨부 파일]]이 있을 수 있으며, 이는 이메일에 추가되는 파일이다. 일반적인 첨부 파일에는 [[마이크로소프트 워드]] 문서, [[PDF]] 문서 및 스캔된 종이 문서 이미지가 포함된다. 원칙적으로 첨부 파일의 크기나 수에 대한 기술적 제한은 없다. 그러나 실제로는 이메일 클라이언트, [[서버]] 및 인터넷 서비스 제공업체는 파일 또는 전체 이메일 크기에 대해 다양한 제한을 구현하며, 일반적으로 25MB 이하이다.<ref>{{웹 인용|url-status=live |url=https://exchangepedia.com/2007/09/exchange-server-2007-setting-message-size-limits.html |title=Set Message Size Limits in Exchange 2010 and Exchange 2007 |archive-url=https://web.archive.org/web/20130212114611/https://exchangepedia.com/2007/09/exchange-server-2007-setting-message-size-limits.html |archive-date=2013-02-12 |first1=Bharat |last1=Suneja |website=Exchangepedia |date=September 10, 2007 }}</ref><ref>{{웹 인용|last=Humphries |first=Matthew |date=Jun 29, 2009 |title=Google updates file size limits for Gmail and YouTube |url=https://www.geek.com/articles/news/google-updates-file-size-limits-for-gmail-and-youtube-20090629 |url-status=dead |archive-url=https://web.archive.org/web/20111219141547/https://www.geek.com/articles/news/google-updates-file-size-limits-for-gmail-and-youtube-20090629 |archive-date=Dec 19, 2011 |website=Geek.com}}</ref><ref>[https://mail.google.com/support/bin/answer.py?answer=8770&topic=1517 "Maximum attachment size", Gmail Help.] {{웹아카이브|url=https://web.archive.org/web/20111015232245/http://mail.google.com/support/bin/answer.py?answer=8770&topic=1517 |date=October 15, 2011 }}.</ref> 또한, 기술적인 이유로 이러한 전송 시스템에서 보이는 첨부 파일 크기는 사용자가 보는 것과 다를 수 있으며,<ref>{{잡지 인용|last=Walther |first=Henrik |date=January 2009 |url=https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dd314394(v=msdn.10) |title=Mysterious Attachment Size Increases, Replicating Public Folders, and More |magazine=[[테크넷 매거진]] |via=[[마이크로소프트 독스]] |access-date=2021-11-07}} [https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc135877(v=msdn.10) Exchange Queue & A].</ref> 이로 인해 발신자가 이메일로 파일을 안전하게 보낼 수 있는지 여부를 평가할 때 혼란스러울 수 있다. 더 큰 파일을 공유해야 하는 경우 다양한 [[파일 호스팅 서비스]]를 사용할 수 있으며 일반적으로 사용된다.<ref>[https://support.office.com/en-us/article/Send-large-files-to-other-people-7005da19-607a-47d5-b2c5-8f3982c6cc83 "Send large files to other people"] {{웹아카이브|url=https://web.archive.org/web/20160807110751/https://support.office.com/en-us/article/Send-large-files-to-other-people-7005da19-607a-47d5-b2c5-8f3982c6cc83 |date=2016-08-07 }}, Microsoft.com</ref><ref>[https://www.makeuseof.com/tag/8-ways-to-email-large-attachments/ "8 ways to email large attachments"] {{웹아카이브|url=https://web.archive.org/web/20160702171053/https://www.makeuseof.com/tag/8-ways-to-email-large-attachments/ |date=2016-07-02 }}, Chris Hoffman, December 21, 2012, makeuseof.com</ref>

===정보 과다===
지식 근로자와 "화이트칼라" 직원에게 이메일이 보편화되면서 수신자들이 증가하는 이메일 양으로 인한 "[[정보 과다]]"에 직면하고 있다는 우려가 제기되었다.<ref>{{웹 인용|last=Radicati|first=Sara|title=Email Statistics Report, 2010|url=https://www.radicati.com/wp/wp-content/uploads/2010/04/Email-Statistics-Report-2010-2014-Executive-Summary2.pdf|url-status=live|archive-url=https://web.archive.org/web/20110901222039/https://www.radicati.com/wp/wp-content/uploads/2010/04/Email-Statistics-Report-2010-2014-Executive-Summary2.pdf|archive-date=2011-09-01}}</ref><ref>{{뉴스 인용|last=Gross|first=Doug|title=Happy Information Overload Day!|url=https://edition.cnn.com/2010/TECH/web/10/20/information.overload.day/index.html|work=[[CNN]]|date=October 20, 2010|url-status=live|archive-url=https://web.archive.org/web/20151023041454/https://edition.cnn.com/2010/TECH/web/10/20/information.overload.day/index.html|archive-date=October 23, 2015|access-date=March 24, 2019}}</ref> 모바일 기기 사용이 증가하면서 직원들은 기본적으로 근무 시간 외에도 업무 관련 이메일을 받을 수 있게 되었다. 이는 스트레스 증가와 업무 만족도 저하로 이어질 수 있다. 일부 관찰자들은 많은 이메일을 읽으려는 노력이 [[생산성]]을 감소시켜 상당한 부정적인 경제적 영향을 미칠 수 있다고 주장하기도 한다.<ref>{{뉴스 인용|url=https://www.nytimes.com/2008/04/20/technology/20digi.html|title=Struggling to Evade the E-Mail Tsunami|date=2008-04-20|newspaper=The New York Times|first=Randall|last=Stross|access-date=May 1, 2010|url-status=live|archive-url=https://web.archive.org/web/20090417094850/https://www.nytimes.com/2008/04/20/technology/20digi.html|archive-date=April 17, 2009}}</ref>

===스팸===
{{본문|스팸 메일}}
이메일 "스팸"은 원치 않는 대량 이메일이다. 이러한 이메일을 보내는 비용이 저렴하다는 것은 2003년까지 전체 이메일 트래픽의 30%가 스팸이었고,<ref>{{웹 인용|url=https://www.sitepronews.com/2015/05/04/seeing-spam-how-to-take-care-of-your-google-analytics-data/|title=Seeing Spam? How To Take Care of Your Google Analytics Data|website=sitepronews.com|access-date=5 September 2017|url-status=live|archive-url=https://web.archive.org/web/20171107005139/https://www.sitepronews.com/2015/05/04/seeing-spam-how-to-take-care-of-your-google-analytics-data/|archive-date=7 November 2017|date=2015-05-04}}</ref><ref>Rich Kawanagh. The top ten email spam list of 2005. ITVibe news, 2006, January 02, [https://itvibe.com/news/3837/ ITvibe.com] {{웹아카이브|url=https://web.archive.org/web/20080720071624/https://itvibe.com/news/3837/ |date=2008-07-20 }}</ref><ref>How Microsoft is losing the war on spam [https://dir.salon.com/story/tech/feature/2005/01/19/microsoft_spam/index.html Salon.com] {{웹아카이브|url=https://web.archive.org/web/20080629050141/https://dir.salon.com/story/tech/feature/2005/01/19/microsoft_spam/index.html |date=2008-06-29 }}</ref> 실용적인 도구로서 이메일의 유용성을 위협하고 있음을 의미했다. 미국의 [[CAN-SPAM Act of 2003]] 및 다른 지역의 유사 법률<ref>Spam Bill 2003 ([https://www.aph.gov.au/library/pubs/bd/2003-04/04bd045.pdf PDF] {{웹아카이브|url=https://web.archive.org/web/20060911062331/https://www.aph.gov.au/library/pubs/bd/2003-04/04bd045.pdf |date=2006-09-11 }})</ref>은 어느 정도 영향을 미쳤고, 현재는 효과적인 [[안티스팸 기술|스팸 방지 기술]]이 대부분의 사용자에게 스팸을 필터링하거나 거부함으로써 스팸의 영향을 크게 완화하고 있지만,<ref>[https://www.wired.com/2015/07/google-says-ai-catches-99-9-percent-gmail-spam/ "Google Says Its AI Catches 99.9 Percent of Gmail Spam"] {{웹아카이브|url=https://web.archive.org/web/20160916054313/https://www.wired.com/2015/07/google-says-ai-catches-99-9-percent-gmail-spam/ |date=2016-09-16 }}, Cade Metz, July 09 2015, wired.com</ref> 전송되는 양은 여전히 매우 높으며, 점차적으로 제품 광고가 아닌 악성 콘텐츠나 링크로 구성되어 있다.<ref>[https://securelist.com/analysis/quarterly-spam-reports/74682/spam-and-phishing-in-q1-2016/ "Spam and phishing in Q1 2016"] {{웹아카이브|url=https://web.archive.org/web/20160809154745/https://securelist.com/analysis/quarterly-spam-reports/74682/spam-and-phishing-in-q1-2016/ |date=2016-08-09 }},  May 12, 2016, securelist.com</ref> 예를 들어, 2017년 9월에는 스팸의 비율이 합법적인 이메일 대비 59.56%로 증가했다.<ref>{{웹 인용|url=https://usa.kaspersky.com/about/press-releases/2018_fifa-2018-and-bitcoin-among-2017-most-luring-topics|title=Kaspersky Lab Spam and Phishing report|date=May 26, 2021|access-date=July 17, 2018|archive-date=July 17, 2018|archive-url=https://web.archive.org/web/20180717183438/https://usa.kaspersky.com/about/press-releases/2018_fifa-2018-and-bitcoin-among-2017-most-luring-topics|url-status=live}}</ref> 2021년 스팸 이메일의 비율은 85%로 추정된다.<ref>{{웹 인용|url=https://www.thexyz.com/blog/2021-email-usage-statistics/|title=2021 Email Usage Statistics|date=October 5, 2021|access-date=October 5, 2021|archive-date=October 5, 2021|archive-url=https://web.archive.org/web/20211005234608/https://www.thexyz.com/blog/2021-email-usage-statistics/|url-status=live}}</ref>{{더 나은 출처|date=October 2021}}

===악성 소프트웨어===
이메일은 [[악성 소프트웨어]] 배포의 주요 벡터이다.<ref>{{웹 인용|last=Waichulis |first=Arin |date=2024-04-05 |title=Security Bite: iCloud Mail, Gmail, others shockingly bad at detecting malware, study finds |url=https://9to5mac.com/2024/04/05/security-bite-icloud-mail-gmail-others-shockingly-bad-at-detecting-malware-study-finds/ |access-date=2024-05-27 |website=9to5Mac |language=en-US}}</ref> 이는 종종 악성 프로그램을 메시지에 첨부하고 잠재적 피해자가 파일을 열도록 설득함으로써 달성된다.<ref>{{웹 인용|title=When are email attachments safe to open? |url=https://www.cloudflare.com/en-gb/learning/email-security/email-attachments/ |access-date=2024-05-27 |website=[[Cloudflare]]}}</ref> 이메일을 통해 배포되는 악성 소프트웨어 유형에는 [[웜]]<ref>{{웹 인용|last=Griffiths |first=James |date=2020-05-02 |title=How a badly-coded computer virus caused billions in damage {{!}} CNN Business |url=https://www.cnn.com/2020/05/01/tech/iloveyou-virus-computer-security-intl-hnk/index.html |access-date=2024-05-27 |website=[[CNN]] |language=en}}</ref> 및 [[랜섬웨어]]가 포함된다.<ref>{{웹 인용|last=French |first=Laura |date=2024-05-14 |title=LockBit ransomware spread in millions of emails via Phorpiex botnet |url=https://www.scmagazine.com/news/lockbit-ransomware-spread-in- लाखों-of-emails-via-phorpiex-botnet |access-date=2024-05-27 |website=SC Media |language=en}}</ref>

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

===메일폭탄===
{{본문|메일폭탄}}

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

===개인 정보 보호 문제===
{{본문|전자우편 개인 정보}}

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

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

위의 문제 중 하나 이상에 대한 해결책으로 사용할 수 있는 [[암호학]] 응용 프로그램이 있다. 예를 들어, [[가상 사설망]] 또는 [[토르 (네트워크)|토르 네트워크]]는 사용자 기기에서 더 안전한 네트워크로 트래픽을 암호화하는 데 사용될 수 있으며, [[GNU 프라이버시 가드|GPG]], [[PGP (소프트웨어)|PGP]], SMEmail,<ref>[https://www.arxiv.org/pdf/1002.3176 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.</ref> 또는 [[S/MIME]]은 [[엔드 투 엔드 원칙|종단 간]] 메시지 암호화에 사용될 수 있으며, SMTP STARTTLS 또는 [[전송 계층 보안|Transport Layer Security]]/Secure Sockets Layer를 통한 SMTP는 SMTP 클라이언트와 SMTP 서버 간의 단일 메일 홉에 대한 통신을 암호화하는 데 사용될 수 있다.

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

===법적 계약===
이메일 교환은 구속력 있는 계약을 형성할 수 있으므로, 사용자들은 이메일 서신을 통해 무엇을 보내는지 주의해야 한다.<ref>{{웹 인용|url=https://www.law.com/newyorklawjournal/almID/1202794877741/When-Email-Exchanges-Become-Binding-Contracts/|title=When Email Exchanges Become Binding Contracts|website=law.com|access-date=December 6, 2019|archive-date=June 19, 2019|archive-url=https://web.archive.org/web/20190619151252/https://www.law.com/newyorklawjournal/almID/1202794877741/When-Email-Exchanges-Become-Binding-Contracts/|url-status=live}}</ref><ref>{{서적 인용|last1=Catarina |first1=Jessica |last2=Feitel |first2=Jesse |title=Inadvertent Contract Formation via Email under New York Law: An Update |journal=[[시러큐스 로 리뷰]] |date=2019 |volume=69 |url=https://lawreview.syr.edu/wp-content/uploads/2020/01/K-Contracts-Article.pdf}}</ref> 이메일의 서명 블록은 계약의 서명 요건을 충족하는 것으로 해석될 수 있다.<ref>{{뉴스 인용|last1=Corfield|first1=Gareth|title=UK court ruling says email signature blocks can sign binding contracts|url=https://www.theregister.co.uk/2019/09/30/email_signature_legally_binding_contract/|access-date=6 December 2019|work=[[더 레지스터]]|archive-date=October 17, 2019|archive-url=https://web.archive.org/web/20191017063749/https://www.theregister.co.uk/2019/09/30/email_signature_legally_binding_contract/|url-status=live|date=30 September 2019}}</ref>

===악성 댓글===
[[악성 댓글]]은 어떤 사람이 화가 나거나 적대적인 내용을 담은 메시지(또는 여러 메시지)를 보낼 때 발생한다. 이 용어는 특히 격렬한 이메일 토론을 설명하기 위해 방화성이라는 단어를 사용한 데서 유래한다. 이메일 통신의 용이성과 비인격성은 대면 또는 전화를 통한 정중함을 장려하는 [[사회 규범]]이 존재하지 않아 정중함이 잊혀질 수 있다는 것을 의미한다.<ref>{{서적 인용|author1=S. Kiesler |author2=D. Zubrow |author3=A.M. Moses |author4=V. Geller |title=Affect in computer-mediated communication: an experiment in synchronous terminal-to-terminal discussion|journal=Human-Computer Interaction|volume=1|pages=77–104|year=1985|doi=10.1207/s15327051hci0101_3}}</ref>

===이메일 파산===
{{본문|이메일 파산}}
"이메일 피로"라고도 알려진 이메일 파산은 사용자가 읽고 답변하는 데 뒤처진 후 많은 이메일 메시지를 무시하는 경우를 말한다. 뒤처지는 이유는 종종 정보 과다와 모든 정보를 읽는 것이 불가능하다는 일반적인 느낌 때문이다. 해결책으로, 사람들은 때때로 이메일 받은 편지함이 가득 찼고 모든 메시지를 정리하는 중이라는 "보일러플레이트" 메시지를 보낸다. [[하버드 대학교]] 법학 교수 [[로런스 레시그]]가 이 용어를 만든 것으로 알려져 있지만, 그는 단지 이 용어를 대중화했을 수도 있다.<ref>{{뉴스 인용|title=All We Are Saying.|url=https://www.nytimes.com/2007/12/23/weekinreview/23buzzwords.html|newspaper=The New York Times|date=December 23, 2007|access-date=2007-12-24|first=Grant|last=Barrett|url-status=live|archive-url=https://web.archive.org/web/20090417094849/https://www.nytimes.com/2007/12/23/weekinreview/23buzzwords.html|archive-date=April 17, 2009}}</ref>

===국제화===
원래 인터넷 이메일은 완전히 ASCII 텍스트 기반이었다. 이제 MIME은 본문 콘텐츠 텍스트와 일부 헤더 콘텐츠 텍스트를 국제 문자 세트로 허용하지만, UTF-8을 사용하는 다른 헤더와 이메일 주소는 표준화되어 있음에도 불구하고<ref>{{웹 인용|url=https://registry.in/Internationalized_Domain_Names_IDNs|title=Internationalized Domain Names (IDNs) {{!}} Registry.In|website=registry.in|access-date=2016-10-17|url-status=live|archive-url=https://web.archive.org/web/20160513012539/https://registry.in/Internationalized_Domain_Names_IDNs|archive-date=2016-05-13}}</ref> 아직 널리 채택되지 않았다.<ref name=first>{{웹 인용|url=https://economictimes.indiatimes.com/tech/internet/datamail-worlds-first-free-linguistic-email-service-supports-eight-india-languages/articleshow/54923001.cms|title=DataMail: World's first free linguistic email service supports eight India languages|work=The Economic Times |url-status=live|archive-url=https://web.archive.org/web/20161022080739/https://economictimes.indiatimes.com/tech/internet/datamail-worlds-first-free-linguistic-email-service-supports-eight-india-languages/articleshow/54923001.cms|archive-date=2016-10-22}}</ref><ref>{{웹 인용|url=https://digitalconqurer.com/gadgets/made-india-datamail-empowers-russia-email-address-russian-language/|title=Made In India 'Datamail' Empowers Russia With Email Address In Russian Language - Digital Conqueror|date=7 December 2016|url-status=live|archive-url=https://web.archive.org/web/20170305005327/https://digitalconqurer.com/gadgets/made-india-datamail-empowers-russia-email-address-russian-language/|archive-date=5 March 2017}}</ref>
{{추가 정보|국제 전자우편|이메일 주소#국제화}}

===전송된 메일 추적===
원래 SMTP 메일 서비스는 전송된 메시지를 추적하는 제한된 메커니즘을 제공하며, 배달 또는 읽혔는지 확인하는 메커니즘은 전혀 제공하지 않는다. 각 메일 서버는 메시지를 계속 전달하거나 실패 통지(반송 메시지)를 반환해야 하지만, 소프트웨어 버그와 시스템 오류 모두 메시지 손실을 유발할 수 있다. 이를 해결하기 위해 [[국제 인터넷 표준화 기구|IETF]]는 [[Delivery Status Notification|배달 상태 알림]] (배달 확인) 및 [[Return receipt#Email|메시지 처리 알림]] (읽음 확인)을 도입했지만, 이들은 실제로 보편적으로 배포되지 않았다.{{Refn|group=nb|완전한 메시지 추적 메커니즘도 정의되었지만, 결코 인기를 얻지 못했다. RFC 3885<ref>RFC 3885, SMTP Service Extension for Message Tracking</ref>부터 3888<ref>RFC 3888, Message Tracking Model and Requirements</ref>을 참조하라.}}

많은 ISP는 스패머의 활동 때문에 고의적으로 배달 불가능 보고서(NDR)와 배달 확인을 비활성화한다.
* 배달 보고서는 주소가 존재하는지 확인할 수 있으며, 만약 그렇다면 스패머에게 스팸을 보낼 수 있음을 알려준다.
* 스패머가 위조된 발신자 이메일 주소([[이메일 스푸핑]])를 사용하는 경우, 사용된 무고한 이메일 주소는 스패머가 메일을 보내려고 시도했을 수 있는 많은 유효하지 않은 이메일 주소로부터 NDR로 범람할 수 있다. 이러한 NDR은 ISP에서 무고한 사용자에게 스팸([[백스캐터 (이메일)|백스캐터]])이 된다.

표준 방법이 없는 상황에서, [[웹 버그]] 사용을 기반으로 하는 다양한 시스템이 개발되었다. 그러나 이러한 시스템은 종종 은밀하거나 개인 정보 보호 문제를 제기하는 것으로 간주되며,<ref>{{뉴스 인용|url=https://query.nytimes.com/gst/fullpage.html?res=940CE0D9143AF931A15752C1A9669C8B63|title=Software That Tracks E-Mail Is Raising Privacy Concerns|author=Amy Harmon|newspaper=The New York Times|date=2000-11-22|access-date=2012-01-13}}</ref> HTML 렌더링을 지원하는 이메일 클라이언트에서만 작동한다. 많은 메일 클라이언트는 이제 기본적으로 "웹 콘텐츠"를 표시하지 않는다.<ref>[https://www.slipstick.com/outlook/email/microsoft-outlook-web-bugs-blocked-html-images "Outlook: Web Bugs & Blocked HTML Images"] {{웹아카이브|url=https://web.archive.org/web/20150218074718/https://www.slipstick.com/outlook/email/microsoft-outlook-web-bugs-blocked-html-images/ |date=2015-02-18 }}, slipstick.com</ref> [[웹 메일]] 제공업체는 이미지를 미리 캐시하여 웹 버그를 방해할 수도 있다.<ref>[https://arstechnica.com/information-technology/2013/12/gmail-blows-up-e-mail-marketing-by-caching-all-images-on-google-servers/ "Gmail blows up e-mail marketing..."] {{웹아카이브|url=https://web.archive.org/web/20170607090403/https://arstechnica.com/information-technology/2013/12/gmail-blows-up-e-mail-marketing-by-caching-all-images-on-google-servers/ |date=2017-06-07 }}, Ron Amadeo, Dec 13 2013, Ars Technica</ref>

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

== 내용주 ==
{{각주|group=nb}}

== 각주 ==
{{각주}}

==추가 자료==
{{참고 자료 시작}}
* Cemil Betanov, Introduction to X.400, Artech House, {{ISBN|0-89006-597-7}}.
* Marsha Egan, "[https://www.inboxdetox.com Inbox Detox and The Habit of Email Excellence] {{웹아카이브|url=https://web.archive.org/web/20160520091235/http://www.inboxdetox.com/ |date=May 20, 2016 }}", Acanthus Publishing {{ISBN|978-0-9815589-8-1}}
* Lawrence Hughes, Internet e-mail Protocols, Standards and Implementation, Artech House Publishers, {{ISBN|0-89006-939-5}}.
* Kevin Johnson, Internet Email Protocols: A Developer's Guide, Addison-Wesley Professional, {{ISBN|0-201-43288-9}}.
* Pete Loshin, Essential Email Standards: RFCs and Protocols Made Practical, John Wiley & Sons, {{ISBN|0-471-34597-0}}.
* {{서적 인용|last=Partridge|first=Craig|title=The Technical Development of Internet Email|journal=IEEE Annals of the History of Computing|volume=30|issue=2|date=April–June 2008|url=https://www.ir.bbn.com/~craig/papers/email.pdf|issn=1934-1547|doi=10.1109/mahc.2008.32|pages=3–29|bibcode=2008IAHC...30b...3P |s2cid=206442868|url-status=dead|archive-url=https://web.archive.org/web/20160602161643/https://www.ir.bbn.com/~craig/papers/email.pdf|archive-date=2016-06-02}}
* Sara Radicati, Electronic Mail: An Introduction to the X.400 Message Handling Standards, Mcgraw-Hill, {{ISBN|0-07-051104-7}}.
* John Rhoton, Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP, Elsevier, {{ISBN|1-55558-212-5}}.
* John Rhoton, X.400 and SMTP: Battle of the E-mail Protocols, Elsevier, {{ISBN|1-55558-165-X}}.
* David Wood, Programming Internet Mail, O'Reilly, {{ISBN|1-56592-479-7}}.
{{참고 자료 끝}}

== 외부 링크 ==
* [https://www.iana.org/assignments/message-headers/perm-headers.html IANA의 표준 헤더 필드 목록]
* [https://web.archive.org/web/20121118062543/https://emailhistory.org/ The History of Email]은 이메일 진화의 '중요한' 사건들의 순서를 포착하려는 데이브 크로커의 시도이며, 이 페이지도 인용하는 협력적인 노력이다.
* [https://www.multicians.org/thvv/mail-history.html The History of Electronic Mail]은 초기 이메일 시스템 구현자의 개인 회고록이다.
* [https://www.circleid.com/posts/20140903_a_look_at_the_origins_of_network_email/ A Look at the Origins of Network Email]은 주요 역사적 사실을 간결하면서도 생생하게 요약한 글이다.
* [https://www.fbi.gov/news/stories/2015/august/business-e-mail-compromise Business E-Mail Compromise - An Emerging Global Threat], [[연방수사국]]
* [https://explained-from-first-principles.com/email/ Explained from first principles], 100개가 넘는 RFC를 요약하려는 2021년 기사

{{이메일 클라이언트}}
{{전거 통제}}
{{위키데이터 속성 추적}}

[[분류:전자 우편| ]]
[[분류:전자 문서]]
[[분류:인터넷 용어]]
[[분류:인터넷의 역사]]
[[분류:페디버스]]