{
  "id": "email",
  "title": "电子邮件",
  "lang": "zh-Hans",
  "source_lang": "en",
  "summary": "电子邮件是一种以存储转发方式在用户与服务器之间传递消息的系统，自20世纪80年代起依托开放标准发展。",
  "category": "computer-science",
  "subcategory": "networks-security",
  "type": "concept",
  "aliases": [
    "电子信件",
    "email",
    "E-mail"
  ],
  "generated_at": "2026-10-08",
  "model": "pro/claude-haiku-5-5",
  "url": "https://aiwiki.page/zh/email/",
  "translations": {
    "en": {
      "url": "https://aiwiki.page/en/email/",
      "json": "https://aiwiki.page/en/email.json"
    }
  },
  "sections": [
    {
      "heading": "",
      "text": "电子邮件（英文 electronic mail，简称 email）是一种通过计算机网络在个人与组织之间交换数字消息的方式。邮件先在客户端程序中撰写，交给邮件服务器，再经互联网在多台服务器之间逐级转发，最后存入收件人的邮箱，直到被阅读为止。它是至今仍在日常使用的最古老的网络应用之一，依然是个人通信、商务往来、账户注册和官方通知的核心工具。同时，它也是常见的网络安全攻击渠道，并且是未经请求的商业信息的主要来源。\n\n电子邮件的发展更多地受开放技术标准塑造，而非由某一家公司主导。从互联网的投递协议到邮件格式，其基本架构在20世纪70至80年代的一系列文档中确立，此后经过数十年的修订。加密、发件人身份验证和反垃圾邮件过滤等后来加入的功能，都是在这一最初设计之上叠加而成的；而最初的设计假定网络规模较小且彼此信任。因此，理解电子邮件既需要审视其历史上的设计选择，也需要关注为使其更加安全可靠而持续进行的工作。\n\n本词条首先介绍电子邮件消息由哪些部分构成，以及地址的结构；随后追溯其在早期 ARPANET 实验中的起源，以及核心协议的标准化过程。接着说明邮件如何在服务器之间传递、用户如何收取邮件，以及邮件格式如何处理附件和多语言文本。最后讨论安全措施、垃圾邮件与网络钓鱼、电子邮件在社会生活和工作场所中的用途、适用于它的法律规定，以及它与新型通信工具的关系。"
    },
    {
      "heading": "消息结构与寻址",
      "text": "电子邮件最好理解为两层结构。两层总是一起传送，但并不总是一致。第一层是信封，即邮件服务器用于路由和错误报告的一组参数。在SMTP中，信封由 MAIL FROM 命令给出的逆向路径，以及一条或多条 RCPT TO 命令给出的正向路径组成。第二层是邮件本身，由一组头部字段、一个空行和正文组成，定义见RFC 5322。这两层有时会出现影响实际投递的差异。发给五个人的一封邮件，信封里有五条正向路径，但其中的收件人（To）和抄送（Cc）头部可能只列出其中一部分。密送（Bcc）收件人通常出现在信封中，而不会出现在其他收件人看到的头部里。信封发件人负责接收退信通知，它常常是一个技术性的回复地址，与用户看到的发件人（From）地址并不相同。\n\n地址的形式为 local-part@domain。本地部分标识域内的某个邮箱，由接收方系统解释，发件人无权决定其含义。RFC 5321允许本地部分最长64个八位组，域名部分最长255个八位组。由于RFC 5322允许本地部分使用带引号的字符串，因此其中可以出现引号包围的\"@\"，所以通常将地址中最后一个\"@\"视为分隔符。域名部分是一个DNS名称。投递邮件时，发送服务器会查询该域名的MX（邮件交换）记录，这些记录列出了接收该域邮件的主机，并附带优先级数值，数值越小越先尝试。如果不存在MX记录，RFC 5321规定退回到该域名的地址记录（A记录或AAAA记录）。随后，发送服务器通常通过25号端口与所选主机建立TCP/IP协议族连接，并通过互联网传输邮件。由于路由依赖于这一查询，域名系统区域配置错误可能导致整个域的邮件无法送达，即使其中所有邮箱都运行正常。\n\n头部字段的格式为\"名称: 值\"，其语法和含义由RFC 5322定义。只有From和Date两个字段是必需的，但几乎每封邮件还会包含To、Subject和Message-ID。Cc和Reply-To也很常见。当邮件代他人发送时（例如助理代高管撰写邮件），Sender字段会记录实际提交邮件的人。邮件客户端通常将From字段的值显示为发件人，但传输过程并不验证这一字段：信封发件人可以与之不同，邮件列表在转发过程中也可能改写From或Reply-To。这种用户可见的发件人与信封发件人之间的差距，正是接收系统需要单独进行身份验证检查的原因，相关内容见安全一节。\n\n回复、转发以及将邮件归入会话，都依赖标识符，而不是可见的文字内容。每封邮件都应携带一个Message-ID头部，它是由原始发送系统生成的、全局唯一的字符串，并用尖括号包围。用户回复时，客户端会把原邮件的Message-ID放入In-Reply-To头部，并把更早的标识符链依次追加到References头部中。客户端利用这些字段将邮件串成会话。如果这些字段缺失或被剥离（例如某些网关或自动化工具会这样做），客户端就会退而比较规范化后的主题行。这种方式可靠性较低：无关的邮件可能被误合并，真正的回复又可能被拆开。转发邮件通常会生成一封带有新Message-ID的新邮件，因此它不像回复那样自然地加入原有会话，它与原邮件的联系通常只体现在引用文本或附件中。"
    },
    {
      "heading": "早期联网消息传递的起源",
      "text": "在电子邮件跨越网络之前，人们就已经在计算机上互相留言了。分时系统在20世纪60年代初出现后，同一系统的用户之间便可以进行基于计算机的消息传递，其中一个颇具影响力的例子是麻省理工学院的分时系统 CTSS。1965年，诺尔·莫里斯（Noel Morris）和汤姆·范·弗莱克（Tom Van Vleck）为CTSS同时实现了一个电子邮件命令和一个文本消息功能。MAIL命令于1965年秋季安装，每个用户的消息都会被追加到名为 MAIL BOX 的、每用户一份的文件中。这种设计有明显的局限：两个版本都没有考虑隐私、身份验证或安全问题，任何用户都可以写入或查看其他用户的邮箱。这个想法是有用的，但它只能在单台机器内部运作。\n\n通往网络电子邮件的一步发生在贝尔纳克与纽曼公司（BBN），雷·汤姆林森（Ray Tomlinson）当时在那里研究阿帕网，这是互联网的前身之一。1971年，他将 SNDMSG 和 CPYNET 两个程序结合起来，开发出阿帕网的第一个网络电子邮件应用，使消息能够发送给其他计算机上的用户。SNDMSG 负责处理本地消息，CPYNET 负责机器之间的文件传输。汤姆林森的测试规模不大：他通过阿帕网从一台 DEC PDP-10 计算机向另一台发送了一条消息。汤姆林森后来表示，他已经记不清那条消息的内容，而且内容本身从来都不是重点。评论者通常将其视为第一封网络电子邮件，但这一限定很重要，因为它并不是历史上第一条电子消息。它的新颖之处在于能够寻址到另一台主机上的用户。\n\n这种地址方案源于实际需要。消息一旦能够抵达其他机器，系统就必须将用户名与计算机名区分开来。汤姆林森选用 @ 符号来区分邮件地址中的本地部分与全局部分。他选择这个符号是经过考虑的，因为该符号在名字中很少出现，并且含有“在……位置”的意思。由此形成的“本地部分 + @ 符号 + 主机名”的结构，至今仍是电子邮件地址的基本格式。\n\n从单一系统发展到由众多主机组成的网络，也暴露出兼容性问题。早期大型机和小型机的大多数开发者各自开发了相似但通常互不兼容的邮件应用。随着时间推移，一个由网关和路由系统构成的复杂网络把其中许多系统连接了起来。这一经验促成了后来对共享标准的需求，互联网工程任务组（IETF）及其前身机构在随后十年中着手解决这一问题。\n\n联网邮件也带来了未经请求的商业信息。1978年5月3日，数字设备公司（DEC）的营销代表加里·特尔克（Gary Thuerk）发出一封广告邮件，宣传DEC新计算机的开放日活动。他把邮件发送给393名收件人，即美国西海岸所有拥有阿帕网账户的用户。不同资料给出的数字有所出入：有一种说法认为约为400个账户，具体取决于各历史资料所采用的统计口径。这一举动引发了强烈的反感。阿帕网的管理人员训斥了特尔克，并明确表示大规模群发邮件不是网络的可接受用途。这一事件被广泛引用为后来所称“垃圾邮件”的最早案例之一，它表明，一旦向大量收件人发送邮件的成本下降，基于非正式规范运行的共享网络就可能被滥用。"
    },
    {
      "heading": "标准化与互联网工程任务组的作用",
      "text": "最早的正式主机间邮件传递规范是邮件传输协议，由S. Sluizer和Jon Postel于1980年9月在RFC 772中记录。该文件以征求意见的初稿形式发布，描述了发送进程如何打开一条通往接收进程的控制连接，并交换带编码的应答。该协议存续时间很短。1982年8月，Postel提出的简单邮件传输协议（RFC 821）取代了它，同时也取代了更早的1981年规范RFC 788。RFC 821引入了今天仍在使用的命令词汇，包括MAIL、RCPT和DATA，以及三位数字的应答码体系。它只假设存在一个可靠、有序的数据流，因此不依赖于任何特定的网络技术。\n\n邮件格式则另行标准化。RFC 822《ARPA互联网文本消息格式标准》的日期为1982年8月13日，由David H. Crocker修订。它取代了1977年的RFC 733，后者将ARPANET上已在使用的非正式惯例编纂成文。RFC 822将一封邮件分为信封和内容两部分：信封保存传输和投递所需的信息，内容则是交给收件人的材料。内容由一组首部字段和一个结构未作规定的正文组成。该文件有意容忍冗余，使用自由文本的字段名而非紧凑的编码，并且除文本行之外对其他内容的编码着墨不多。其首部语法成为后来互联网邮件的模板，并于2001年被RFC 2822取代，后者又于2008年被RFC 5322取代。\n\n此后的改进在扩展SMTP的同时并未破坏既有软件。扩展简单邮件传输协议（ESMTP）于1995年在RFC 1869中定义，允许服务器在对客户端问候的响应中列出其支持的扩展功能。随时间增加的扩展包括用于加密的STARTTLS、用于身份验证的SMTP AUTH、邮件大小声明、8位正文传输以及对国际化地址的支持。RFC 2821（2001年）澄清了1982年的规范，而由John Klensin撰写、于2008年10月发布的RFC 5321则整合了此前的各项文件。RFC 5321废止了RFC 821、RFC 974、RFC 1869和RFC 2821，并通过替换其中的邮件传输相关内容更新了RFC 1123。它保留了核心命令集和应答结构，这也是针对1982年协议编写的软件仍能与当前服务器互操作的原因。\n\n互联网工程任务组（IETF）通过开放的工作组制定这些标准，大部分起草工作都通过公开的邮件列表讨论完成。RFC 822的序言指出，其前身曾在ARPANET邮件系统上经过一年的改进。成果以编号的“请求评议”（RFC）文件形式发布。一份RFC通常在发布后不再编辑，而是由新文件取代它，从而形成一条清晰可见的修订链。SMTP的这条修订链依次为RFC 772、RFC 821，然后是RFC 2821，最后是RFC 5321。达到正式标准地位的文件会获得STD编号，如RFC 821（STD 10）和RFC 822（STD 11）。这一做法使分布在众多网络中的独立实现者能够就一个共同的、带版本的参考依据达成一致。"
    },
    {
      "heading": "投递架构与邮件路由",
      "text": "发送一封电子邮件需要多个程序相互配合。用户代理（例如桌面客户端、手机应用或网页邮箱）会把撰写好的邮件交给提交服务器，提交服务器只接受经过身份验证的用户提交的邮件，然后将其转入更广泛的传输网络。在该网络内部，邮件传输代理（MTA）使用简单邮件传输协议（SMTP）在服务器之间逐级转发邮件。每一次中转都采用存储转发的方式：服务器先接收完整的邮件，将其写入本地存储，然后才尝试下一跳。因此，服务器可能早在邮件抵达最终目的地之前就已接收它，而此时发件人的客户端通常收不到任何送达确认。\n\n邮件的路由依赖域名系统（DNS）。发送服务器取出收件人地址中的域名部分，查询其邮件交换（MX）记录。这些记录列出了负责接收该域名邮件的一个或多个主机，并各自附有优先级数值。服务器先尝试优先级数值最低的主机，若无法连接则依次尝试其他主机，这使域名天然具备冗余能力。随后，它与所选主机的25号端口建立TCP连接，并进行SMTP对话：先表明自身身份，再声明信封发件人和每个收件人，最后传输邮件内容。MX机制取代了早期的显式源路由。由于源路由操作繁琐，IETF于1989年宣布弃用它。因此，邮件到达目的地的路径现在由常规的DNS数据决定，而不是由发件人指定。\n\n当邮件抵达收件域的服务器时，最后一个MTA会将其交给邮件投递代理（MDA）。MDA把邮件写入收件人的邮箱存储，收件人的客户端随后通过另一种访问协议将其取回。投递失败通过SMTP应答码处理。4xx范围的应答表示临时性问题，发送服务器会推迟投递并稍后重试；5xx应答表示永久性拒绝，例如收件人不存在，此时发送服务器会向信封上的回复地址退回一封退信，也称为未投递报告。由于退信本身也是电子邮件，配置不当的系统可能因此形成循环，因此许多服务器会将退信的发件人地址留空，以防止这种情况发生。\n\n排队与重试机制使邮件能够经受住服务中断。如果目标服务器宕机或过载，发送方的MTA会将邮件保留在队列中，并以逐渐拉长的间隔重试。大多数实现只在经过一段固定时间后才放弃，这段时间通常以天计，之后生成退信。经由多个中间服务器中转进一步增强了可靠性，邮件列表、转发服务以及不同网络之间的网关也是以这种方式运作的。处理过邮件的每台服务器通常会在邮件头前添加一个Received字段，记录该跳的信息，这些字段共同构成了路由的追踪记录。\n\n正是这些特性使路径难以验证。中间服务器可能由不同的主体运营，Received字段可能被伪造或遗漏，邮件也可能在重新排队、改写或转发的过程中掩盖其真实来源。各跳之间的传输加密往往是机会性的，因此每一段链路的保护程度取决于两台服务器协商的结果。因此，接收系统通常无法确切得知邮件经过了哪条路由，只能依靠本文其他部分所述的身份验证与过滤机制来判断邮件的可信度。"
    },
    {
      "heading": "收取协议与访问方式",
      "text": "SMTP 的设计目的是传递邮件，而不是为用户保存邮件。它负责把邮件从客户端转交给其提交服务器，再在服务器之间中继，但收件人需要通过另外的协议来读取邮箱。两种历史悠久的收取协议是 POP3 和 IMAP。两者均由互联网工程任务组定义，都运行在 TCP 之上，通常在专用端口上以 TLS 封装。打开邮箱前，客户端都必须先进行身份验证。\n\nPOP3（邮局协议第 3 版）采用简单的模型。客户端连接服务器，下载待收邮件，并且在常见配置下会把这些邮件从服务器上删除。因此，邮箱更像是一个由设备清空的投递点。这种方式适合把单台计算机作为主要存档的场景，但在一台设备上已读的邮件不会在另一台设备上显示为已读，而从服务器删除的邮件则只存在于下载它的那台设备上。部分客户端可以在服务器上保留副本，但这是客户端的设置，而非协议模型的一部分，POP3 本身也没有服务器端文件夹的概念。\n\nIMAP（互联网消息访问协议）将服务器上的副本视为权威版本。客户端可以列出、创建和重命名文件夹，并能设置已读、已回复、已标记、已删除等标志。在一台设备上所做的更改会在下一次同步时传播到其他设备。IMAP 还可以只获取邮件头或某个特定的 MIME 部分，使手机能先显示预览、稍后再下载大附件，并允许在服务器上执行搜索。其代价是服务器必须保存完整的邮箱内容，因此服务商的存储配额和保留规则直接决定用户能保存多少邮件。\n\n并非所有用户都使用专门的程序。网页邮件在 网页浏览器 中运行，通过 HTTPS 与服务商通信；智能手机或平板上的移动应用也提供同样的功能。许多此类应用在内部使用 IMAP 或 POP3，但大型服务商和企业往往依赖专有接口。例如，微软的 Exchange ActiveSync 通过 HTTP 在 Exchange 服务器与设备之间同步邮件、日历和联系人，并支持推送投递，使新邮件无需设备轮询服务器即可到达。这些方式让用户无需安装任何客户端即可访问邮箱，但也使用户更紧密地依附于某一服务商的服务。第三方客户端只能使用服务商选择开放的访问功能。\n\n本地存储与服务器端存储之间的选择是最主要的实际权衡。本地存储（POP3 配置中的典型做法）支持离线访问，并能完全掌控所存文件，也不受服务商配额的限制。然而，它使多设备使用变得不便，并且除非进行备份，设备本身就成了单点故障源。服务器端存储（IMAP 和网页邮件的典型做法）让多设备使用无缝衔接，并将备份责任转移给服务商或管理员。其代价是许多操作依赖网络连接，以及用户的往来邮件集中于一处，这会引发安全和数据治理方面的问题。许多现代客户端折中两种方式：在本地缓存邮件，同时将权威副本保存在服务器上。组织通常还会增加独立的归档系统，以便无论用户选择哪种客户端，都能满足保留义务。"
    },
    {
      "heading": "消息格式、MIME与国际化",
      "text": "最初的互联网邮件格式是为很窄的字符集设计的。1982年的标准（传输部分为RFC 821，邮件内容部分为RFC 822）只允许每行不超过1000个字符的7位美国ASCII文本，因此邮件无法承载二进制文件、图像或大多数非英语文字。早期用户通过手动把附件转换为可打印字符来变通，互联网的快速发展又使这一问题更加突出。文本文件通常直接粘贴到邮件正文中。\n\n多用途互联网邮件扩展（MIME）在不取代SMTP的前提下解决了上述大部分问题。第一版MIME规范于1992年以RFC 1341发布，其后续版本RFC 2045于1996年出现。MIME定义了一组头部字段，其中最重要的是Content-Type（说明正文部分的媒体类型）和Content-Transfer-Encoding（说明该部分为便于传输而进行的转换方式）。一封邮件可以是多部分结构，每个部分各有自己的类型和编码，因此纯文本正文、HTML版本和附件可以通过边界字符串分隔，共存于同一封邮件中。RFC 2045定义了7bit、8bit、binary、quoted-printable和base64等传输值，但其中只有最后两种真正对数据进行了转换。前三种只是说明数据本身是什么，以及传输通道能否承载它。\n\n两种转换编码的用途不同。Quoted-printable能让以ASCII为主的文本保持可读，它把每个非ASCII字节表示为等号加两个十六进制数字，适合偶尔带有重音字母的欧洲语言文本。Base64将每三个输入字节映射为四个可打印字符，因此可以承载任何二进制内容，但输出体积约增大三分之一，且不解码便无法阅读。邮件客户端通常对附件选用base64，对文本选用quoted-printable。邮件头部中的非ASCII词语（例如日文主题或带变音符号的姓名）则由RFC 2047定义的“编码字”语法处理，它把文本包裹在字符集标签和编码载荷之中。\n\n国际化电子邮件是IETF在2000年代和2010年代开展的工作，它更进一步，允许地址和头部字段本身包含非ASCII字符。RFC 6531于2012年2月发布，定义了SMTPUTF8扩展。服务器在EHLO响应中声明支持该扩展后，信封地址即可包含UTF-8。RFC 6532允许大多数头部字段直接使用原始UTF-8，因此显示名称、主题以及地址的本地部分都可以用多种文字书写。在这些扩展被广泛部署之前，发件人可能需要使用Punycode把国际化域名转换为ASCII形式，而含非ASCII字符的本地部分只有在两端都支持SMTPUTF8时才能使用。一些服务器还要求先支持8BITMIME扩展，才会接受8位内容；另外，某些发送服务可能以会破坏8位正文的方式改写邮件。\n\n实践中的兼容性问题依然存在。尽管标准没有规定固定的最大邮件大小，各服务商仍会对总大小、附件数量和允许的文件类型设定各自的限制，而且这些限制因服务而异。一封在某个服务商处可以接受的邮件，在另一家可能被拒收、截断或被转换；发件人以为使用的字符集也未必被正确声明或解释。因此，即使已知收件人支持Unicode，许多开发者和机构仍把符合MIME、ASCII安全的编码作为默认选择。"
    },
    {
      "heading": "安全与发件人认证",
      "text": "服务器之间的加密通常通过 STARTTLS 协商。STARTTLS 是 SMTP 的一个扩展，RFC 3207 于 2002 年发布，用于把明文会话升级为 TLS 加密。这种升级是机会式的：服务器在能力列表中声明支持该选项，而这份列表在任何加密建立之前就已传送，因此路径上的攻击者可以删除这一声明，迫使使用明文投递。若发送服务器没有看到该声明，通常会以未加密方式投递邮件，而不是拒绝发送，因为送达的优先级高于安全。MTA-STS 和 DANE 等协议的设计目的，是让域名能够要求使用 TLS 并报告失败，但其采用程度参差不齐，许多邮件仍会在某些中继节点上未经强制加密地传输。\n\n发件人认证\n\nSMTP 最初允许任何主机在发件人字段中声称任意地址，因此认证机制是作为附加层加上去的。SPF（RFC 7208）允许域名发布一条 DNS TXT 记录，列出获准代表该域发信的服务器。接收服务器使用信封发件人域，将连接方地址与该列表比对。SPF 有实际限制：单次评估最多可触发十次 DNS 查询，而且转发常常使其失效，因为转发服务器并不在原域名的列表中。DKIM（RFC 6376）采用另一种思路：发送系统用私钥对选定的邮件头和正文签名，对应的公钥则以选择器（selector）的形式发布在 DNS 中。有效签名表明签名域对内容负责，且内容在传输途中未被篡改，但它并不能说明签名者是否可信。\n\nDMARC对齐与策略\n\nSPF 和 DKIM 检查的身份，用户通常看不到。SPF 检查的是信封回退路径，DKIM 检查的是签名中所指明的域名。DMARC（RFC 7489，2015 年以信息性文档形式发布）把这些结果与收件人所读到的 From 地址联系起来。其核心要求是标识符对齐：只有当 SPF 或 DKIM 通过，并且经认证的域名与 From 域名一致时，邮件才算通过。宽松模式下两者只需共享同一组织域名，严格模式则要求完全一致。若没有对齐要求，伪造者就可以用自己的域名通过 SPF 验证，同时显示他人的名字。域名所有者在 DNS 记录中发布其 DMARC 策略，可在 none、quarantine 和 reject 之间选择，并可请求汇总报告。可选的 percentage 标签可将策略仅应用于一定比例的失败邮件。后续草案进一步收紧了对采用 reject 策略的域名的建议，告诫它们不要只依赖 SPF，因为转发会削弱 SPF 的效力。\n\n内容加密及其局限\n\nPGP 和 S/MIME 可对邮件内容提供端到端保护：通过加密实现机密性，并通过收件人可验证的数字签名实现完整性。它们的应用范围仍然有限。用户必须自行管理密钥和证书；许多网页邮件服务对其支持较弱或根本不支持；而除非密钥被托管，加密内容既无法被服务商的搜索功能索引，也无法由管理员恢复。即便正文受到保护，元数据仍然暴露。每个中继节点都必须读取信封地址才能完成路由，服务商也能观察到谁在何时写信给谁。在常见配置中，主题行等外层邮件头通常也保持可读。因此，认证与加密保护的是内容以及发件人声称的身份，但它们无法向承载通信的基础设施隐藏通信模式。"
    },
    {
      "heading": "垃圾邮件、网络钓鱼与过滤",
      "text": "未经请求的批量电子邮件自20世纪70年代末以来一直是个顽固的问题。1978年5月3日，数字设备公司（Digital Equipment Corporation）的一名营销人员向数百名ARPANET用户发送了一封推广DECSYSTEM-20计算机开放日的邮件，垃圾邮件一般就追溯到这封邮件。据称它带来的销售额常被引用为约1300万美元，但这一数字难以核实。收件人普遍愤怒，网络管理员也警告发件人不要进行大规模群发。关于垃圾邮件在总流量中的占比，各方估计差异很大，从2017年的约60%到其他估计中的约90%不等，因为统计结果取决于如何计算邮件。其核心经济问题始终未变：多发一封邮件对发件人几乎没有成本，而处理它所需的时间和注意力却由收件人承担。\n\n过滤技术\n\n邮件服务商和管理员会综合使用多种防御手段。黑名单列出已知会发送不受欢迎邮件的IP地址或域名，接收服务器在接受邮件前会通过DNS查询这些名单。早期的公开名单，如MAPS黑洞列表，出现于1996年。信誉评分依据的是发件人的历史记录、发送量、投诉率和身份验证结果，而非单封邮件的内容。内容分析则检查邮件头、链接、附件、图片以及可疑措辞。\n\n统计分类器如今占据核心地位。朴素贝叶斯分类器将贝叶斯定理应用于单个词语或词元，估算每个词元出现在垃圾邮件和正常邮件中的可能性，再将这些估计合并为总体概率。该方法之所以称为“朴素”，是因为它假设各词元彼此独立。保罗·格雷厄姆（Paul Graham）在其2002年的文章《对抗垃圾邮件的计划》（\"A Plan for Spam\"）中推广了一种变体，只使用概率离中性最远的少数几个词元，因此在邮件中掺入普通文字的效果有限。这类过滤器会从用户的纠正中学习，因而具有自适应性，但其准确性也取决于所获反馈的质量。\n\n发件人也会随之调整。2005年发表的研究表明，加入更像正常邮件的词语，可能使垃圾邮件绕过朴素贝叶斯过滤器，这种手法常被称为贝叶斯投毒。依赖收件方服务器反馈（如退信消息）的攻击则更为有效，这也是邮件系统尽量不向发件人透露投递结果的原因之一。因此，过滤成为一场持续的博弈，而非已经解决的问题；分类器也越来越多地与其他机器学习模型和网络安全工具结合使用。\n\n网络钓鱼与商务电子邮件诈骗\n\n网络钓鱼使用模仿可信机构的邮件，常伪造显示名称、使用形似的域名，或附上指向仿冒登录页面的链接，以窃取密码或其他凭证。由于其目的是获取账户访问权限，而非推销商品，网络钓鱼邮件通常数量不多，并针对特定人员。\n\n商务电子邮件诈骗（BEC）是一种更具针对性的欺诈形式。攻击者冒充高管、供应商或熟识的联系人，要求员工转账、变更银行信息或发送工资数据。此类骗局依靠社会工程学而非恶意软件，因此能够绕过用于筛查恶意附件的技术管控。美国联邦调查局互联网犯罪投诉中心报告称，2023年商务电子邮件诈骗造成的损失接近30亿美元，2025年则超过30亿美元。其2025年报告还描述了涉及人工智能的案例：生成文本、语音克隆和伪造消息使冒充行为更具迷惑性。\n\n过滤的权衡\n\n任何过滤器都会出错。误报会把正常邮件送入垃圾邮件文件夹，或直接拒收；如果丢失的是密码重置邮件、合同或发票，后果可能十分严重。漏报则会让欺诈或有害邮件进入收件箱。管理员会根据自身的风险承受能力调整这些阈值，这意味着同一封邮件在一家服务商处可能正常投递，在另一家却被拦截。\n\n激进的策略也会影响谁能联系到谁。小型或新的发件人、信誉不佳的机构以及共享主机的用户，可能因与其自身行为无关的原因而被拦截；大型服务商则借此获得影响力，决定哪些邮件会被看到。黑名单的标准往往不透明，移出名单的争议也很难解决。因此，垃圾邮件控制不仅是技术问题，也关乎竞争和通信的可及性。"
    },
    {
      "heading": "社会、职场与商业用途",
      "text": "办公往来与记录保存\n\n20世纪80年代至90年代初，电子邮件逐渐进入办公室，主要在大型机构、高校和政府部门内部使用。早期的企业系统大多是专有系统，无法与外部网络互通，因此其价值取决于同一平台上有多少同事。史密森学会的经历清楚地反映了这一转变：1992年7月，其内部系统接入互联网并采用SMTP协议；1994年的一份名录列出了分布在十个不同系统中的约4800个地址。员工仍分散在互不兼容的平台上，据该机构自己的估计，当时只有大约一半到五分之三的员工拥有电子邮箱。互操作性实现之后，电子邮件开始取代商务活动中的备忘录、传真和大部分邮政信件。电子邮件的记录性质也随之改变：人们最初视为非正式的消息，开始被保存下来，作为决策和协议的凭证。\n\n1990年代还出现了商业化的邮件服务和处理大量邮件的工具。Hotmail（1996年）和Yahoo Mail（1997年）等网页邮件服务让人们无需工作单位账户也能使用电子邮件，Microsoft Outlook则成为商务场景中常见的桌面客户端。收到大量客户来信的公司开始需要专门的软件和受过培训的人员。一个例子是1994年推出的EchoMail平台，用于分析和分类收到的邮件，此后几年被大型零售商和电信公司采用。\n\n礼仪与职场惯例\n\n人们对电子邮件应如何撰写和使用的期待，与其普及同步形成，这些惯例通常被统称为“电子邮件礼仪”。其内容包括邮件的语气、主题行的长度与清晰度、期望多快回复，以及何时应抄送给更多收件人（这种做法可能分散责任，也可能使邮件的传播范围扩大）。这些规范也因机构和文化而异，关于不必要的抄送、深夜发送邮件或“全部回复”引发的纠纷，一直是职场中反复出现的摩擦来源。由于电子邮件是异步的，其礼仪往往围绕如何在及时回应与持续消息带来的打扰之间取得平衡展开。这一矛盾后来推动了部分人转向其他工具，即本文“替代方案”一节所讨论的内容。\n\n邮件列表、电子通讯与事务性邮件\n\n电子邮件在网络交易中至关重要，因为它承载着两类截然不同的消息。邮件列表和电子通讯由已订阅的群体接收，用于营销、社区讨论和信息传播。事务性邮件则不同：它由某个特定操作触发，例如购买、注册或重置密码的请求，其主要目的是确认该操作或传达与之相关的信息。典型例子包括订单确认、购买收据、发货通知、双因素验证码和账户提醒。许多网络零售商和服务商的运营都依赖这些邮件，因此邮件投递问题可能直接影响业务。由于这类邮件具有时效性，发送方通常会将其与营销邮件区分开来，常见做法是使用不同的发件域名，这样一次针对促销活动的投诉就不会影响密码重置邮件的投递。\n\n作为账户标识符的电子邮件\n\n电子邮件地址已成为网络账户的常用标识符，也是找回账户的常用途径。重置密码时，通常会向注册邮箱发送一个有时效的链接；服务方还利用该地址确认身份、发送安全通知并验证新设备。因此，对某个邮箱地址的控制权，可能成为打开众多其他服务的钥匙。如果一个人因忘记密码、订阅到期或账户被盗而失去对邮箱的访问权，他可能无法找回与之关联的购物、银行或社交网络账户。同样的依赖关系也使电子邮箱成为网络安全攻击的热门目标，因为控制收件箱后，攻击者就可能重置其他服务的密码。因此，对用户而言，邮箱地址的可靠性和安全性往往比其作为通信渠道的原始用途更为重要；而电子邮件在电子商务和数字身份中的作用日益增强，也使此类故障的后果更加严重。"
    },
    {
      "heading": "法律、监管与隐私层面",
      "text": "反垃圾邮件法是对电子邮件最直接的监管形式。在美国，2003年颁布的《CAN-SPAM法案》是规范商业电子邮件的主要联邦法律，由联邦贸易委员会负责执法。与欧洲和加拿大的隐私法规不同，《CAN-SPAM法案》采用\"选择退出\"（opt-out）框架：发送商业电子邮件无需事先取得同意，但收件人必须能够通过清晰、可用的方式拒绝继续接收。实践中，发件人可以持续发送邮件，直到收件人提出反对为止。该法案还对邮件内容作出规定：商业邮件不得包含虚假或误导性的信头信息，必须标明其为广告，并须包含有效的实际邮寄地址。退订请求必须在10个工作日内处理，这一期限包括周末和节假日。收据和账户通知等交易性邮件基本豁免于《CAN-SPAM法案》的要求，但仍须包含真实信息。此外，该法案也适用于企业对企业（B2B）邮件，因为法案并未对B2B邮件设置豁免。\n\n数据保护法的思路有所不同，它将电子邮件地址本身视为与个人相关的信息。根据欧盟的《通用数据保护条例》，个人数据是指能够被直接或间接识别的在世自然人的相关信息。只要某个电子邮件地址能够识别特定的自然人，例如firstname.lastname@company.com，它在《通用数据保护条例》下就属于个人数据。而info@company.com这类通用地址通常不属于个人数据，因为它指向的是某个机构，而非某一个人。保护范围还延伸至邮件内容和元数据：邮件正文、附件、主题行，甚至时间戳、IP地址等元数据，都可能包含敏感信息。处理此类数据的机构必须确立合法的处理依据，制定保留和删除规则，并妥善处理个人行使权利的请求。这意味着电子邮件系统通常需要在合法依据、透明度、安全性、保留与删除以及用户权利处理等方面配备相应的控制措施。《通用数据保护条例》第32条要求采取适当的技术和组织措施保护个人数据，在电子邮件场景中，这通常意味着加密和访问限制。其他法域也持类似观点。根据《通用数据保护条例》和《加州消费者隐私法》（CCPA），电子邮件地址属于个人可识别信息（PII）。\n\n由于电子邮件记录了谁进行了沟通、知悉了什么信息以及何时采取了行动，它通常被当作证据使用。作为商业沟通的主要媒介，电子邮件既可以证明某人的认知与动机，也可以证明行为和商业交易的时间与意图。在诉讼中，当事方必须通过电子证据披露程序识别并保全相关的电子存储信息。保全义务通常在诉讼可被合理预见时即已产生，最常见的保全手段是法律保全令（legal hold）。在此之后销毁证据被称为证据毁损（spoliation），可能招致制裁。在2020年的一起案件中，纽约南区联邦地方法院认定，被告在删除相关电子存储信息时负有保全义务，而这一删除行为发生在诉讼开始一年之后。法院还指出，被告未能暂停其常规的文件保留与销毁政策。常规删除本身并不违法。依据书面的政策，机构可以销毁电子邮件，但一旦发生可能引发诉讼的事件，销毁行为必须立即停止。保留政策还可能影响证据的可采性。它有助于证明某封邮件是在正常业务过程中生成并保存的，这与传闻证据规则中的业务记录例外相关。受监管行业面临额外的要求：金融服务、医疗、公共部门及其他受监管行业通常对电子邮件的保全和访问提出更多要求，包括特定的审计日志、保留期限、加密标准以及数据泄露通知时限等。\n\n雇主和政府也可能监控或归档电子邮件，这引发了关于隐私和监控界限的问题。机构通常拥有员工所使用的系统和账户，许多机构会为合规、安全和调查目的而归档邮件。关于阅读或保存员工邮件的规则，包括告知义务和允许审查的范围，在不同法域之间差异很大。公共机关可以通过法律程序向服务提供商调取电子邮件，内容和元数据都可能成为调取对象。对于此类访问应延伸到何种程度，争论仍在继续，尤其是涉及大规模批量收集，以及使用令服务提供商无法读取内容的加密技术的情形。这些问题将电子邮件与更广泛的人权和数据隐私议题联系在一起。"
    },
    {
      "heading": "替代方案、竞争与未来发展",
      "text": "相互竞争的沟通形式\n\n在许多非正式和实时的场景中，电子邮件已经失去了原有的地位，但它并未被取代。即时通讯和团队协作平台现在承载了许多过去通过电子邮件进行的快速交流。一份比较指南把电子邮件描述为正式在线商务信息的默认渠道，同时也指出 Slack 作为团队沟通平台仍在持续增长（Email is the global standard for online messages (particularly in business) and of the many email management systems, Gmail is probably the most widely used. Even so, Slack continues to grow as a popular platform for communication among teams.）。批评者认为，这一转变并非毫无保留的进步。2025 年的一篇评论指出，原本被认为会取代电子邮件的聊天工具，反而带来了一种与持续沟通相关的新型负担。\n\n电子邮件剩余的优势主要来自其结构特点。邮件线程可以事后搜索和回溯，邮件还能留存正式记录，这也是许多机构仍把电子邮件保留给决策、合同和对外往来的原因。各来源对每日邮件总量的估计差异很大。一家供应商称每天发送的电子邮件超过 3760 亿封，另一家则报告每天发送超过 3470 亿封。这种差异源于统计方法的不同，而非规模上的真实变化，两个数字也都未经独立核实。\n\n电子邮件为何延续\n\n电子邮件之所以长期存在，是因为它开放、去中心化且具有互操作性。任何机构都可以架设邮件服务器，并与其他任何机构交换邮件，因此没有哪一家厂商能够控制整个网络。电子邮件作为通用账户标识符的角色进一步强化了这一点。由于邮箱地址被广泛用于众多服务的登录、找回密码和收据发送，即使某个新工具在特定任务上更为便捷，个人和企业要摆脱电子邮件的成本依然很高。\n\n服务商竞争与互操作性\n\n各服务商目前主要在存储容量、搜索质量、垃圾邮件过滤以及与日历和办公软件的集成方面展开竞争。这些功能可以让服务更加实用，但它们往往依赖专有扩展或封闭的生态系统。当某项功能只能在某一套件内顺畅运行时，用户和管理员可能会发现它无法干净地迁移到其他客户端或域名下，这就削弱了使电子邮件经久不衰的互操作性。\n\n身份验证与加密\n\n近来最具体的变化是对发件人要求的收紧。2024 年 2 月，Gmail 和 Yahoo 开始对高频发件人执行新规则。谷歌将批量发件人定义为每天向个人 Gmail 账户发送约 5000 封邮件的任何发件人。这些发件人必须使用 SPF、DKIM 和 DMARC，将垃圾邮件投诉率保持在 0.3% 以下，并提供一键退订选项。这些机制的细节见电子邮件身份验证。执行已超出警告的范畴：一家供应商报告称，谷歌的规则已于 2025 年 11 月起正式执行，不合规的邮件将面临临时和永久性的拒收。此前，据 Mailgun 称，Gmail 在 2022 年提出身份验证要求后，Gmail 用户收到的未验证邮件减少了 75%。传输加密在实践中也得到了加强；谷歌公布的要求包括，发往谷歌的邮件投递应通过加密的 TLS 连接进行。不过，端到端加密仍远不如传输加密普遍。\n\n生成式人工智能与自动化邮件\n\n生成式人工智能改变了垃圾邮件和钓鱼邮件的运作成本，而相关统计数据存在争议。一家安全行业来源估计，目前超过 51% 的垃圾邮件由人工智能生成；另一项研究者的估计则认为，到 2026 年初，约 82.6% 的钓鱼邮件由人工智能生成或借助人工智能完成。这些数字来自供应商和二手研究，其定义也各不相同，因此应当被视为参考性数据，而非精确结论。实际的担忧在于，人工智能使欺诈邮件更加流畅、更具个性化，从而削弱了过去\"留意语法错误\"这一防骗建议的作用。\n\n自动化发件人也带来了新的问题。2026 年 9 月，有报道称一个 AI 智能体平台的服务正在向收件箱大量发送无人请求的服务推销邮件。过滤系统正在转向不再依赖内容关键词，而是分析发件人行为、互动信号和内容语境。关于如何标注代表他人由软件发送的邮件、收件人如何核实其来源，以及现有身份验证标准是否足够，仍存在许多未解决的问题。这些答案很可能会塑造下一代标准的修订，而这些标准自 20 世纪 80 年代以来一直支撑着电子邮件的运行。"
    }
  ],
  "links": [
    "internet",
    "cybersecurity",
    "domain-name-system",
    "web-browser",
    "smartphone",
    "data-governance",
    "naive-bayes-classifier",
    "bayes-theorem",
    "machine-learning",
    "e-commerce",
    "general-data-protection-regulation",
    "cryptography",
    "human-rights",
    "data-privacy"
  ],
  "sources": [
    {
      "title": "History of email",
      "url": "https://en.wikipedia.org/wiki/History_of_email"
    },
    {
      "title": "(PDF) Electronic Mail and Text Messaging in CTSS, 1965-1973",
      "url": "https://www.researchgate.net/publication/254062000_Electronic_Mail_and_Text_Messaging_in_CTSS_1965-1973"
    },
    {
      "title": "Electronic Mail and Text Messaging in CTSS, 1965 - 1973",
      "url": "https://www.multicians.org/thvv/anhc-34-1-anec.html"
    },
    {
      "title": "Timeline of Early Email - Matt Rickard",
      "url": "https://blog.matt-rickard.com/p/timeline-of-email"
    },
    {
      "title": "Official Biography: Raymond Tomlinson - Internet Hall of Fame",
      "url": "https://www.internethalloffame.org/official-biography-raymond-tomlinson/"
    },
    {
      "title": "The First Email Was Sent in 1971",
      "url": "https://www.missedhistory.com/article/the-first-email-was-sent-in-1971"
    },
    {
      "title": "Ray Tomlinson and the Invention of Networked Email (1971)",
      "url": "https://ineedthatbadge.com/ray-tomlinson-inventor-of-email/"
    },
    {
      "title": "On This Day: Birth of Email Spam",
      "url": "https://yourstory.com/2023/05/origin-email-spam-digital-communication"
    },
    {
      "title": "Gary Thuerk’s 1978 ARPANET email still explains the spam problem",
      "url": "https://webiano.digital/gary-thuerks-1978-arpanet-email-still-explains-the-spam-problem/"
    },
    {
      "title": "Ray Tomlinson",
      "url": "https://en.wikipedia.org/wiki/Ray_Tomlinson"
    },
    {
      "title": "The First Mass Unsolicited Commercial E-mail, i.e. Spam - This Day in Tech History",
      "url": "https://thisdayintechhistory.com/05/03/the-first-mass-unsolicited-commercial-e-mail-i-e-spam/"
    },
    {
      "title": "Email spam",
      "url": "https://en.wikipedia.org/wiki/Email_spam"
    },
    {
      "title": "RFC 772: Mail Transfer Protocol",
      "url": "https://www.rfc-editor.org/rfc/rfc772"
    },
    {
      "title": "datatracker.ietf.org",
      "url": "https://datatracker.ietf.org/doc/rfc821/"
    },
    {
      "title": "RFC 821 - Simple Mail Transfer Protocol",
      "url": "https://tools.ietf.org/html/rfc821"
    },
    {
      "title": "Standard for the Format of ARPA Internet Text Messages",
      "url": "https://www.ietf.org/rfc/rfc822"
    },
    {
      "title": "RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES",
      "url": "https://www.rfc-editor.org/info/rfc822/"
    },
    {
      "title": "RFC 5321: Simple Mail Transfer Protocol",
      "url": "https://www.rfc-editor.org/info/rfc5321/"
    },
    {
      "title": "RFC 5321 SMTP Standard: Developer's Complete Reference",
      "url": "https://resources.mailertogo.com/glossary/rfc-5321-simple-mail-transfer-protocol"
    },
    {
      "title": "RFC 821: Simple Mail Transfer Protocol (obsoleted by ...",
      "url": "https://smtpedia.com/rfc-821/"
    },
    {
      "title": "RFC 5321 SMTP Protocol: Commands, Reply Codes, ESMTP Extensions",
      "url": "https://smtpedia.com/rfc-5321/"
    },
    {
      "title": "Email",
      "url": "https://en.wikipedia.org/wiki/Email"
    },
    {
      "title": "Sender Rewriting Scheme",
      "url": "https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme"
    },
    {
      "title": "Mail Transfer Agent - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/mail-transfer-agent"
    },
    {
      "title": "What Is an Email MTA? A Guide to Mail Transfer Agents - Transactional Email API Service For Developers",
      "url": "https://www.mailgun.com/blog/email/what-is-mta/"
    },
    {
      "title": "Mail Transfer Agent: What Is an MTA And How Does It Work",
      "url": "https://boostinbox.com/blog/mail-transfer-agent"
    },
    {
      "title": "What is an MX record? - Zoho Mail Glossary",
      "url": "https://www.zoho.com/mail/glossary/mx-records.html"
    },
    {
      "title": "Mail transfer agent guide: MTA mail server and testing",
      "url": "https://www.mailslurp.com/blog/mail-transfer-agent/"
    },
    {
      "title": "RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
      "url": "https://tools.ietf.org/html/rfc2045"
    },
    {
      "title": "RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
      "url": "https://www.rfc-editor.org/info/rfc2045/"
    },
    {
      "title": "Quoted-printable",
      "url": "https://en.wikipedia.org/wiki/Quoted-printable"
    },
    {
      "title": "MIME",
      "url": "https://en.wikipedia.org/wiki/MIME"
    },
    {
      "title": "Email attachment",
      "url": "https://en.wikipedia.org/wiki/Email_attachment"
    },
    {
      "title": "RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies",
      "url": "https://datatracker.ietf.org/doc/html/rfc1341"
    },
    {
      "title": "Really simple mail transport protocol",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/7103635"
    },
    {
      "title": "Sending raw email using the Amazon SES API v2 - Amazon Simple Email Service",
      "url": "https://docs.aws.amazon.com/ses/latest/dg/send-email-raw.html"
    },
    {
      "title": "Enhanced electronic mail system including methods and apparatus for identifying mime types and for displaying different icons",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/6546417"
    },
    {
      "title": "RFC 6531: SMTP Extension for Internationalized Email",
      "url": "https://www.rfc-editor.org/rfc/rfc6531.html"
    },
    {
      "title": "RFC 6532",
      "url": "https://www.mailertogo.com/rfc/6532"
    },
    {
      "title": "RFC 6531 SMTPUTF8: Internationalized Email Address Extension",
      "url": "https://smtpedia.com/rfc-6531/"
    },
    {
      "title": "Email Address Internationalization - ICANNWiki",
      "url": "https://icannwiki.org/Email_Address_Internationalization"
    },
    {
      "title": "RFC 3207",
      "url": "https://www.mailertogo.com/rfc/3207"
    },
    {
      "title": "RFC 3207: STARTTLS — DMARC Analyzer",
      "url": "https://dmarc-analyzer.net/rfc/3207/"
    },
    {
      "title": "(PDF) SMTP Require TLS Option",
      "url": "https://www.researchgate.net/publication/337570859_SMTP_Require_TLS_Option"
    },
    {
      "title": "Opportunistic TLS",
      "url": "https://en.wikipedia.org/wiki/Opportunistic_TLS"
    },
    {
      "title": "RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)",
      "url": "https://datatracker.ietf.org/doc/html/rfc7489"
    },
    {
      "title": "RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)",
      "url": "https://www.rfc-editor.org/info/rfc7489/"
    },
    {
      "title": "What Is DMARC Alignment, And How Does It Work",
      "url": "https://dmarcreport.com/blog/what-is-dmarc-alignment-and-how-does-it-work/"
    },
    {
      "title": "DMARC RFC Explained: The Foundation Of Email Authentication",
      "url": "https://powerdmarc.com/dmarc-rfc-standard/"
    },
    {
      "title": "DMARC Policy Guide: SPF, DKIM & Rollout - DKs Enterprises",
      "url": "https://dkent.net/resources/technologies/dmarc-policy-a-complete-guide-to-implementation-configuration-and-monitoring/"
    },
    {
      "title": "Email Authentication Mechanisms: DMARC, SPF and DKIM",
      "url": "https://www.nist.gov/publications/email-authentication-mechanisms-dmarc-spf-and-dkim"
    },
    {
      "title": "SPF vs DKIM vs DMARC: Email Authentication Explained",
      "url": "https://www.adaptivesecurity.com/blog/spf-vs-dkim-vs-dmarc"
    },
    {
      "title": "DMARC, SPF and DKIM Setup Guide: Get to p=reject Safely",
      "url": "https://consilien.com/news/dmarc-spf-dkim-guide"
    },
    {
      "title": "SPF, DKIM, and DMARC Explained",
      "url": "https://cli.nylas.com/guides/email-spf-dkim-dmarc-explained"
    },
    {
      "title": "History of email spam",
      "url": "https://en.wikipedia.org/wiki/History_of_email_spam"
    },
    {
      "title": "May 3: Earliest Known Case of Spam",
      "url": "https://www.computerhistory.org/tdih/may/3/"
    },
    {
      "title": "40 years on from the first spam email, what have we learned? Here are 5 things you should know about junk mail",
      "url": "https://www.weforum.org/stories/2018/05/its-40-years-since-the-first-spam-email-was-sent-here-are-6-things-you-didnt/"
    },
    {
      "title": "The History of Spam Email: Origins, Evolution, and Impact",
      "url": "https://www.spaceship.com/blog/spam-email-history-origin/"
    },
    {
      "title": "Naive Bayes classifier",
      "url": "https://en.wikipedia.org/wiki/Naive_Bayes_spam_filtering"
    },
    {
      "title": "23. Practical: A Spam Filter",
      "url": "https://gigamonkeys.com/book/practical-a-spam-filter"
    },
    {
      "title": "Paul Graham on Fighting Spam - Slashdot",
      "url": "https://developers.slashdot.org/story/02/08/16/1428238/paul-graham-on-fighting-spam"
    },
    {
      "title": "Bayesian poisoning",
      "url": "https://en.wikipedia.org/wiki/Bayesian_poisoning"
    },
    {
      "title": "Key Takeaways from the 2023 FBI IC3 Report: Business Email Compromise Losses Jump to Nearly $3 Billion",
      "url": "https://abnormal.ai/blog/2023-fbi-ic3-report-takeaways"
    },
    {
      "title": "Cybersecurity is everyone's job: the human layer your fund can't automate",
      "url": "https://www.ecsoffice.com/cybersecurity-is-everyones-job-the-human-layer-your-fund-cant-automate/"
    },
    {
      "title": "Bank of America cites $20.8 billion in FBI-reported 2025 internet crime losses - The Money Overview",
      "url": "https://themoneyoverview.com/bank-of-america-cites-208-billion-in-fbi-reported-2025-internet-crime-losses"
    },
    {
      "title": "FBI's 2025 Annual Cybercrime Report Shows U.S. Losses Reach Nearly $21 Billion; BlackCloak Addresses Top Two Issues of Investment Fraud and Business Email Compromise",
      "url": "https://www.prweb.com/releases/fbis-2025-annual-cybercrime-report-shows-us-losses-reach-nearly-21-billion-blackcloak-addresses-top-two-issues-of-investment-fraud-and-business-email-compromise-302736207.html"
    },
    {
      "title": "FBI Issues Warning About The Business Email Compromise",
      "url": "https://www.forbes.com/sites/steveweisman/2024/11/09/fbi-issues-warning-about-the-business-email-compromise/"
    },
    {
      "title": "When Did Email Become Popular? A Brief History of Email's Rise to Dominance",
      "url": "https://mailfloss.com/history-of-email-popularity/"
    },
    {
      "title": "The History of Email at the Smithsonian",
      "url": "https://siarchives.si.edu/blog/history-email-smithsonian"
    },
    {
      "title": "Email @ 50 Series: A Brief History",
      "url": "https://via.studio/journal/email-50-series-a-brief-history"
    },
    {
      "title": "The History of Email Marketing: 1971 to the AI Inbox",
      "url": "https://knak.com/blog/history-of-email-marketing/"
    },
    {
      "title": "Email management",
      "url": "https://en.wikipedia.org/wiki/Email_management"
    },
    {
      "title": "What is a Transactional Email?",
      "url": "https://mailchimp.com/marketing-glossary/transactional-email/"
    },
    {
      "title": "Everything You Need to Know About Transactional Emails",
      "url": "https://www.benchmarkemail.com/blog/transactional-emails/"
    },
    {
      "title": "Transactional Email Guide: Best Practices & Setup",
      "url": "https://www.brevo.com/blog/transactional-emails-guide/"
    },
    {
      "title": "Top Transactional Email Examples to Boost Your Business",
      "url": "https://truelist.io/blog/transactional-email-examples"
    },
    {
      "title": "Email marketing",
      "url": "https://en.wikipedia.org/wiki/Email_marketing"
    },
    {
      "title": "CAN-SPAM Act Requirements: 7 FTC Rules Every Email Marketer Must Follow to Avoid $53,088 Fines",
      "url": "https://www.adaptivesecurity.com/blog/can-spam-act-requirements"
    },
    {
      "title": "The CAN-SPAM Act: A complete 2026 compliance guide",
      "url": "https://transcend.io/blog/can-spam-act"
    },
    {
      "title": "Is an Email Address Personal Data Under the GDPR?",
      "url": "https://lawandmore.eu/email-data-protection-under-gdpr/"
    },
    {
      "title": "Data protection and email: 7 steps to ensure GDPR compliance",
      "url": "https://www.ftapi.com/en/blog/data-protection-in-emails"
    },
    {
      "title": "GDPR email compliance requirements for product teams",
      "url": "https://www.mailslurp.com/about/gdpr-email-requirements/"
    },
    {
      "title": "Are Email Addresses Personal Data?",
      "url": "https://termly.io/faq/are-email-addresses-personal-data/"
    },
    {
      "title": "What is eDiscovery in Microsoft Office 365?",
      "url": "https://www.mimecast.com/content/office365-ediscovery/"
    },
    {
      "title": "System and method to optimally apply local retention in a remote repository",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/10713218"
    },
    {
      "title": "Tag:Email - Electronic Discovery Law",
      "url": "https://www.ediscoverylaw.com/tag/email/"
    },
    {
      "title": "Email archiving",
      "url": "https://en.wikipedia.org/wiki/Email_archiving"
    },
    {
      "title": "BY ADAM I. COHEN DAVID J. LENDER ELECTRONIC DISCOVERY PRACTICE GUIDELINES",
      "url": "https://www.weil.com/~/media/files/pdfs/EDPGWHOLE.pdf"
    },
    {
      "title": "E-Discovery Email Security: How to Protect Sensitive Case Emails in Litigation",
      "url": "https://trustifi.com/blog/secure-e-discovery-email-communications-legal-teams/"
    },
    {
      "title": "Email Anti Spam Laws",
      "url": "https://www.foundersworkbench.com/build/operate/anti-spam-rules"
    },
    {
      "title": "Anti-Spam Guidance",
      "url": "https://www.fairfield.edu/about/offices-and-departments/marketing-and-communications/anti-spam-guidance/"
    },
    {
      "title": "The CAN-SPAM Act: Compliance Guide with Best Practices",
      "url": "https://usercentrics.com/knowledge-hub/can-spam-compliance/"
    },
    {
      "title": "When to Use Email vs. Slack? 7 Team Communication Tips",
      "url": "https://gmelius.com/blog/email-vs-slack"
    },
    {
      "title": "Chat has replaced email, and it's even worse",
      "url": "https://www.duperrin.com/english/2025/06/03/chat-worse-email/"
    },
    {
      "title": "2026 Guide: Avoid AI Spam Filters with Smart Email Sequences",
      "url": "https://reply.io/blog/ai-spam-filter/"
    },
    {
      "title": "Yahoogle: New Bulk Sender Requirements in 2024 - Transactional Email API Service For Developers",
      "url": "https://www.mailgun.com/state-of-email-deliverability/chapter/yahoogle-bulk-senders/"
    },
    {
      "title": "New Google and Yahoo Email Requirements for 2024: Explained - BuzzStream",
      "url": "https://www.buzzstream.com/blog/google-yahoo-email-requirements/"
    },
    {
      "title": "Google And Yahoo Email Authentication Requirements 2026",
      "url": "https://powerdmarc.com/google-and-yahoo-email-authentication-requirements/"
    },
    {
      "title": "Gmail And Yahoo Inbox Requirements & What They Mean For Senders - Transactional Email API Service For Developers",
      "url": "https://www.mailgun.com/blog/deliverability/gmail-and-yahoo-inbox-updates-2024/"
    },
    {
      "title": "The new Gmail and Yahoo requirements for email delivery (2024)",
      "url": "https://dmarcwise.io/blog/gmail-yahoo-new-requirements-2024"
    },
    {
      "title": "AI-Generated Email Detection: The New Spam Filter Front Line and What It Means for Your Inbox Security",
      "url": "https://www.getmailbird.com/ai-generated-email-detection-spam-filter/"
    },
    {
      "title": "AI Now Writes 82% of Phishing Emails Hitting Inboxes",
      "url": "https://www.gblock.app/articles/ai-phishing-82-percent-email-attacks-2026"
    },
    {
      "title": "AI Agent Platform Reinvents Spam, Floods Inboxes Worldwide",
      "url": "https://www.404media.co/ai-agent-platform-reinvents-spam-floods-inboxes-worldwide/"
    },
    {
      "title": "New Bulk Sender Requirements from Gmail and Yahoo",
      "url": "https://www.emailonacid.com/blog/article/industry-news/gmail-yahoo-new-requirements/"
    },
    {
      "title": "Slack vs Email - Talking To Your Customers",
      "url": "https://www.m.io/blog/slack-vs-email"
    }
  ],
  "license": "https://creativecommons.org/licenses/by/4.0/"
}