1. 论文基本信息 (Bibliographic Information)

• 标题 (Title): Automatic Insecurity: Exploring Email Auto-configuration in the Wild (自动化的不安全：探究野外的电子邮件自动配置)
• 作者 (Authors): Shushang Wen, Yiming Zhang, Yuxiang Shen, Bingyu Li, Haixin Duan, Jingqiang Lin
• 隶属机构 (Affiliations): 中国科学技术大学 (University of Science and Technology of China), 清华大学 (Tsinghua University), 北京航空航天大学 (Beihang University), 中关村实验室 (Zhongguancun Laboratory)
• 发表期刊/会议 (Journal/Conference): 论文格式和引用风格（如 [56], [8]）表明它很可能发表于顶级的网络安全会议，如 USENIX Security, ACM CCS, NDSS, or IEEE S&P。根据公开信息，该论文发表于 NDSS 2023 (Network and Distributed System Security Symposium)，这是网络与系统安全领域的四大顶级会议之一，具有极高的声誉和影响力。
• 发表年份 (Publication Year): 2023 (根据论文内容推断，实验数据收集于2024年，但公开版本发表于2023年，此处以发表年份为准)
• 摘要 (Abstract): 电子邮件客户端的自动配置功能极大地方便了用户，只需输入邮箱和密码即可自动获取服务器设置。然而，这些机制的安全性（无论是在实现层面还是部署层面）都缺乏系统性研究。本文首次对电子邮件自动配置的安全威胁进行了系统性分析和影响评估。研究总结了 10 种攻击场景，涵盖 17 个缺陷（其中 8 个为新发现）和 4 种不充分的客户端 UI 提示。这些攻击场景可能导致受害者连接到攻击者控制的服务器或建立不安全连接，从而泄露凭据。大规模测量显示，在野外部署中存在严重的安全问题：在服务器端，研究人员发现 49,013 个域名（包括 19 个 Top-1K 流行域名）存在错误配置；在客户端，29 个客户端中有 22 个 易受攻击。此外，27 个客户端存在至少一种 UI 提示缺陷，为静默攻击提供了便利。这些缺陷源于错误的配置、管理不善、有缺陷的实现以及兼容性问题。
• 原文链接 (Source Link): /files/papers/68f734a1b5728723472281fc/paper.pdf (此为本地/相对路径，非公开 URL)

2. 整体概括 (Executive Summary)

• 研究背景与动机 (Background & Motivation - Why):

  • 核心问题： 电子邮件客户端为了提升用户体验，广泛采用自动配置 (auto-configuration) 机制，该机制能自动获取服务器主机名、端口、加密方式等信息。然而，这些由微软 (Autodiscover) 和 Thunderbird (Autoconfig) 等厂商主导的、缺乏统一标准的机制，在方便用户的同时，也引入了新的、未被充分研究的安全攻击面。
  • 重要性与挑战： 尽管已有零星研究指出了 Autodiscover 实现中的缺陷，但学术界缺乏对整个电子邮件自动配置生态（包括多种机制、服务器端部署和客户端实现）的系统性安全分析。现有的讨论多集中在协议设计层面，缺少对真实世界影响的大规模评估。此外，许多厂商自定义的机制（如内置列表、启发式猜测）如同黑盒，其安全性更是一个未知数。
  • 切入点： 本文旨在回答两个核心问题：1) 电子邮件自动配置中存在哪些安全威胁？2) 这些威胁在真实世界中的影响有多广泛？研究团队从两个关键安全要素出发：① 配置信息传输的安全性 和 ② 配置参数设置的安全性，系统性地挖掘服务器端和客户端的潜在缺陷。

• 核心贡献/主要发现 (Main Contribution/Findings - what):

  • 系统性威胁分析： 首次对电子邮件自动配置进行了全面的安全分析，总结了 10 种攻击场景，涵盖 17 个具体缺陷，其中 8 个为新发现的缺陷。这些攻击可导致两大类危害：Type-I (连接到攻击者服务器) 和 Type-II (凭据泄露)。
  • 大规模实证研究：
    • 服务器端： 对超过 100 万个域名进行扫描，发现约 61.88% (49,013个) 支持自动配置的域名存在错误配置。其中，55.0% 的域名易受 Type-I 威胁（如通过明文 HTTP 传输配置），14.93% 的域名易受 Type-II 威胁（如配置了不安全的连接方式）。包括 Yandex 和 Onet 在内的 19 个 Top-1K 流行域名也受到影响。
    • 客户端： 测试了 29 款主流邮件客户端，发现 22 款 存在至少一种漏洞。更严重的是，27 款 客户端在 UI 设计上存在缺陷（如缺少关键警告），使得攻击可以“静默”进行，用户毫无察觉。
  • 揭示根本原因： 指出这些安全问题源于四大根因：错误配置 (Misconfiguration)、管理不善 (Mismanagement)、有缺陷的实现 (Flawed implementation) 和 兼容性问题 (Compatibility)。

3. 预备知识与相关工作 (Prerequisite Knowledge & Related Work)

本部分旨在为读者铺垫理解论文所需的前置知识。

• 基础概念 (Foundational Concepts):

  • 电子邮件协议族：
    • SMTP (Simple Mail Transport Protocol): 简单邮件传输协议，用于发送邮件。标准规定了不同的端口用于邮件中继 (Relay) (端口 25) 和用户提交 (Submission) (端口 587)。
    • IMAP (Internet Message Access Protocol) 和 POP3 (Post Office Protocol v3): 用于接收和访问服务器上的邮件。
  • 邮件连接加密方式：
    • STARTTLS: 一种“机会主义加密”机制，允许在原有的明文端口（如 587, 143, 110）上，通过发送 STARTTLS 命令将会话升级为加密的 TLS 连接。它的缺点是实现复杂，容易出错，且存在“命令注入”等历史漏洞（如 CVE-2011-0411），攻击者可在 TLS 握手前注入明文命令。
    • Implicit TLS (隐式 TLS): 一种“强制加密”机制，连接从一开始就必须是 TLS 加密的。它使用专门的加密端口（如 465, 993, 995），安全性更高，是目前推荐的实践。
  • 电子邮件自动配置机制 (Email Auto-configuration Mechanisms):
    • Autodiscover: 由微软提出，主要通过向特定 URL（如 https://example.com/autodiscover/autodiscover.xml）发送 HTTP POST 请求获取 XML 格式的配置文件。
    • Autoconfig: 由 Thunderbird (Mozilla) 提出，主要通过向特定 URL（如 https://autoconfig.example.com/...）发送 HTTP GET 请求获取 XML 格式的配置文件。
    • DNS SRV 记录: 一种通过 DNS 查询直接定位特定服务（如 _imaps._tcp.example.com）的标准化方法，无需像 Autodiscover/Autoconfig 那样探测 HTTP 端点。
  • 其他机制:
    • 内置提供商列表 (Built-in Provider Lists): 客户端内置一个流行邮件服务商（如 Gmail, Outlook）的配置清单。
    • 启发式猜测 (Heuristic Guessing): 客户端尝试使用通用前缀（如 imap.example.com, smtp.example.com）来猜测服务器地址。

• 前人工作 (Previous Works):

  • 邮件协议部署测量： 已有大量工作研究了邮件生态中其他安全协议的部署情况，如发件人认证 (SPF, DKIM, DMARC) 和传输加密 (TLS, DANE, MTA-STS)。这些研究普遍发现存在大量错误配置，削弱了协议的保护效果。
  • 邮件机制攻击： 先前的研究揭示了多种针对邮件协议的攻击，如认证绕过、凭据窃取 (STARTTLS 攻击)、签名伪造和加密内容解密等。特别是 Poddebniak 等人 [62] 对 STARTTLS 的系统性分析，揭示了其固有的脆弱性，并建议优先使用 Implicit TLS。

• 技术演进 (Technological Evolution): 邮件系统从最初的明文设计，逐步通过 STARTTLS 和 Implicit TLS 增加传输层安全性。为了简化用户配置，Autodiscover 和 Autoconfig 等机制应运而生，但它们本身又带来了新的配置和管理复杂性，从而产生了新的安全风险。

• 差异化分析 (Differentiation): 与之前的工作相比，本文的核心创新在于：

  1. 首次聚焦于“自动配置”这一特定攻击面，而不是泛泛地研究邮件传输安全。
  2. 系统性地整合了多种自动配置机制 (Autodiscover, Autoconfig, SRV, 内置列表等)，进行了全面的威胁建模。
  3. 同时考察了服务器端（部署）和客户端（实现），提供了端到端的安全视图。
  4. 开展了大规模的野外测量，用真实数据量化了问题的严重性，而不仅仅是理论上的分析。

4. 方法论 (Methodology - Core Technology & Implementation Details)

本部分是论文的核心，详细拆解了作者如何进行威胁分析和定义攻击场景。

• 方法原理 (Methodology Principles): 研究的核心思想是围绕自动配置过程中的两个关键阶段进行安全分析：(1) 配置信息检索 和 (2) 参数解析与应用。作者基于此定义了两种攻击目标：

  • Type-I: 连接到攻击者控制的服务器 (Connecting to attacker-controlled servers): 攻击者通过篡改配置信息，将邮件客户端重定向到自己控制的恶意服务器，从而可以窃取凭据或操纵用户邮箱。
  • Type-II: 泄露凭据 (Leaking credentials): 攻击者通过迫使客户端使用不安全的连接（如明文或有漏洞的 STARTTLS），在客户端与合法邮件服务器的通信路径上窃听，从而获取用户凭据。

• 方法步骤与流程 (Steps & Procedures): 论文系统性地梳理了自动配置的完整流程，并以此为基础构建威胁模型。

  该图像是论文中的示意图，展示了电子邮件客户端自动配置的流程，包括通过内置列表、启发式猜测和默认设置获取配置信息，以及客户端如何依次与Web服务器、DNS服务器和邮件服务器交互以完成配置。

  基于此流程，作者定义了不同能力的攻击者模型：

  • Type-I 攻击者能力：
    1. 篡改 TCP 数据包: 典型的中间人攻击者 (Manipulator-in-the-middle, MITM)，可以修改明文传输的配置数据。
    2. 域名抢注 (Domain squatting): 攻击者可以注册自动配置过程中可能查询到的、但未被管理员保护的域名。
  • Type-II 攻击者能力：
    1. 嗅探 (Sniffing): 路径上的攻击者可以窃听明文流量。
    2. 延迟或丢弃数据包: 路径上的攻击者可以干扰网络连接，迫使客户端回退到不安全的备用机制。
    3. 破解 STARTTLS (Hacking STARTTLS): 具备 篡改 TCP 数据包 能力的攻击者可以利用 STARTTLS 的漏洞（如命令注入）来窃取凭据。

• 攻击场景与关键细节 (Attack Scenarios & Key Details): 论文总结了 10 个攻击场景 (Attack Scenarios)，下表是论文 Table V 的转录和详细解读，这是本文方法论的核心产出。

  攻击目标	攻击场景	攻击者能力	攻击案例	适用机制¹	缺陷		相关但非必需的服务器缺陷
  					客户端缺陷	服务器缺陷
  Type-I: 连接到攻击者控制的服务器	A1: 客户端以明文请求配置信息	篡改 TCP 数据包	A1.1<br> A1.2<br> *A1.3 </td> <td> AC<br> AD<br> AC/AD </td> <td> 发送明文请求<br> 发送明文请求<br> - </td> <td> -²<br> -²<br> 重定向到 HTTP </td> <td> 返回明文响应³<br> 返回明文响应³<br> - </td>
  	A2: 客户端未执行 eTLD 验证	域名抢注	*A2.1	AC	eTLD 检查不充分	-	-
  	...
  Type-II: 泄露凭据	A3: 服务器仅设置明文连接类型	嗅探	A3.1	AC/AD	-	仅支持明文连接	-
  		嗅探 或 破解 STARTTLS⁴	A3.2	SR	-	-	仅支持明文或 STARTTLS 连接
  	A4: 客户端解析失败并回退到明文		*A4.1	AC/AD	解析错误时回退到明文	连接类型设置不正确	-
  	A5: 客户端自动配置失败并回退到明文	嗅探	A5.1	AC/AD/SR/BL	默认使用明文	-	-
  	A6: 客户端对 Autodiscover 的实现不充分		*A6.1	AD	忽略 `Encryption` 元素	-	-
  	A7: 客户端错误地确定 SRV 记录的优先级	嗅探 或 破解 STARTTLS⁵	*A7.1	SR	不合规的 SRV 排序	-	不安全的 SRV 优先级
  	A8: 客户端维护一个过时的内置列表		*A8.1	BL	过时的内置列表	-	-
  	A9: 服务器偏好不安全的连接类型	-	A9.1 A9.2	SR AC/AD	-	不安全的 SRV 优先级 不安全的连接优先级	-
  	A10: 服务器设置了不一致的连接类型	延迟/丢包 + (嗅探 或 破解 STARTTLS⁵)	*A10.1	AC/AD/SR/BL	-	连接类型不一致	-

  *新发现的案例。¹ AD: Autodiscover, AC: Autoconfig, SR: SRV Record, BL: Built-in List。² 客户端缺陷是攻击成功的充分条件。³ 服务器返回明文响应是缺陷，但非攻击成功的必要条件。⁴/⁵ 攻击者能力取决于降级后的连接类型：若为明文，则需嗅探；若为 STARTTLS，则需破解 STARTTLS。

  关键攻击场景详解：

  1. A1 (配置过程明文传输): Autodiscover 和 Autoconfig 的规范中都包含通过 http:// 发起请求的步骤。只要客户端遵循这些步骤，MITM 攻击者就可以拦截并篡改返回的配置，将 hostname 指向自己的服务器（Type-I 攻击）。

  2. A2 (eTLD 验证缺失的“回退”攻击): 这是针对 Autoconfig 的一个精巧攻击。Autoconfig 在探测失败后，会查询域名的 MX 记录，并尝试从 MX 记录的父域名（如 mx.provider.co.uk 的父域名 provider.co.uk）继续查找配置。如果客户端在构造新 URL 时，没有检查提取的域名是否是一个有效的顶级域名 (eTLD, e.g., .co.uk)，它可能会错误地向 autoconfig.co.uk 这样的地址发起请求。攻击者只需抢注这类域名，即可劫持大量使用该邮件提供商的用户的配置过程。

     该图像是图2的示意图，展示了回退查询攻击（A2）的流程。图中描述了受害者邮箱客户端如何通过DNS查询邮件服务器，因404未找到配置，触发回退机制，最终连接到攻击者控制的服务器，导致凭证泄露。

  3. A4 (解析失败降级): 如果服务器在配置文件中写了一个客户端不认识的加密类型值（例如，在 Autodiscover 文件里写了 Autoconfig 专用的 starttls 值），某些客户端会因解析错误而直接回退到最不安全的“明文”连接模式，造成凭据泄露风险（Type-II 攻击）。

  4. A10 (跨机制配置不一致的降级攻击): 一个域名可能同时支持 Autoconfig 和 Autodiscover。如果管理员为 Autoconfig 配置了安全的 Implicit TLS，却忘记更新 Autodiscover 的配置，使其仍为“明文”。攻击者可以通过选择性地丢弃发往 Autoconfig URL 的数据包，迫使客户端“回退”到使用 Autodiscover 机制，从而获取到不安全的配置，实现连接降级。

     

     不充分的 UI 提醒 (Inadequate UI Notifications): 除了协议和实现的缺陷，论文还强调了客户端 UI 设计的不足，这些不足使得攻击更隐蔽、更易成功。

  • UC (User Confirmation): 客户端在获取到配置后，不应立即使用，而应展示给用户确认。缺乏此步骤会导致静默攻击。

  • $W_P (Plain Warning)$: 当连接类型为不加密的 PLAIN 时，应有明确、醒目的警告。

  • W_AD (Autodiscover Redirect Warning): Autodiscover 规范中建议，当从不安全的 http:// GET 请求收到重定向时，应警告用户。

  • W_SR (SRV FQDN Warning): 当 SRV 记录的目标主机名与查询的域名不匹配时，应警告用户。

    该图像是一个邮件客户端自动配置的界面截图，展示了Thunderbird邮箱配置的UI通知，指出POP3和SMTP协议均无加密，存在安全风险。

5. 实验设置 (Experimental Setup)

• 数据集 (Datasets): 作者收集了来自五个不同来源的域名列表，以确保覆盖广泛性和代表性，总计 1,053,469 个独立域名。

  • Tranco1M: 包含全球最流行的 100 万个网站。
  • Top100Provider: 包含最受欢迎的电子邮件提供商域名。
  • GovDomain: 全球政府网站域名。
  • BankDomain: 全球银行域名。
  • FreeDisposableProvider: 免费和一次性邮件服务提供商域名。
  • 选择这些数据集能有效评估自动配置安全问题在不同领域（流行网站、关键基础设施、高风险服务）的影响范围。

• 评估方法 (Evaluation Methodology): 作者设计了一套系统的评估流程来衡量真实世界的影响。

  该图像是图5，展示了用于分析和评估服务器及客户端缺陷的方法论流程图，涵盖域名列表下载、配置信息收集、配置分析、客户端缺陷分析及安全影响评估。

  1. 服务器端测量 (Server-side Measurement):
     • 配置信息收集: 开发了一个基于 Golang 的爬虫，于 2024 年 3 月底从香港的服务器对所有域名进行扫描。爬虫根据 Autodiscover、Autoconfig 和 SRV 记录的规范，生成并请求所有可能的配置路径。
     • 配置信息分析: 对收集到的有效配置文件和 SRV 记录进行解析，并根据第 IV 节定义的攻击场景检查是否存在以下缺陷：
       • 不安全的响应: 如 HTTP 请求被重定向到 HTTPS，或 HTTPS 请求链中出现 HTTP。
       • 仅明文连接: 配置中只提供 plain 连接选项。
       • 参数设置不正确: 如 socketType 的值不符合规范。
       • 不安全的优先级设置: 如将 STARTTLS 或明文连接排在 Implicit TLS 之前。
       • 连接类型不一致: 同一域名在不同机制下的安全配置等级不同。
  2. 客户端测试 (Client-side Testing):
     • 客户端选择: 选择了覆盖 5 个操作系统平台（Windows, macOS, Linux, Android, iOS）的 29 款 电子邮件客户端。选择标准包括 RFC 草案中提及的、在线评测推荐的流行客户端。
     • 缺陷分析: 针对每个客户端，系统地测试其对 Table V 中定义的 10 种攻击场景的脆弱性。例如，通过搭建恶意服务器和 DNS 服务器，模拟中间人攻击和域名抢注攻击，观察客户端的行为。同时，检查客户端的 UI 是否提供了必要的安全警告。

• 对比基线 (Baselines): 本研究没有传统意义上的“基线模型”。其“基线”是安全协议的规范和最佳实践。实验通过将现实世界中服务器的部署情况和客户端的实现行为与这些“理想基线”进行对比，来量化偏差和缺陷。例如，RFC 8314 [50] 建议优先使用 Implicit TLS，这就构成了评估优先级设置是否安全的基线。

6. 实验结果与分析 (Results & Analysis)

注意： 由于提供的原文在 Select email clients 部分中断，此处仅能分析到原文结束前的内容，主要集中在服务器端测量结果的摘要。

• 核心结果分析 (Core Results Analysis):

  • 服务器端普遍存在缺陷:

    • 在超过 100 万的被测域名中，有 79,212 个支持至少一种自动配置机制。
    • 在这些支持的域名中，高达 61.88% (49,013 个) 存在错误配置，这是一个惊人的比例。
    • Type-I 威胁 (连接被劫持) 影响广泛: 55.0% (43,566 个) 域名存在导致 Type-I 威胁的缺陷。最主要的原因是通过明文 HTTP 传输配置文件 (对应攻击场景 A1)，允许中间人篡改配置，将用户重定向到恶意服务器。
    • Type-II 威胁 (凭据泄露) 同样严重: 14.93% (11,824 个) 域名受到 Type-II 威胁影响。这源于配置缺陷（如设置了不安全的连接类型）和管理缺陷（如不同机制间配置不一致）。
    • 高价值目标也受影响: 发现 19 个 Tranco Top-1K 的流行域名存在这些问题，包括像 Yandex 和 Onet 这样的知名服务商，说明这并非小众问题。

  • 客户端漏洞情况严峻:

    • 在测试的 29 款客户端中，22 款 (约 76%) 易受至少一种威胁的影响，包括大名鼎鼎的 Thunderbird 和 Outlook。
    • 13 款客户端 易受 Type-I 威胁，可能导致用户连接到攻击者服务器。
    • 19 款客户端 易受 Type-II 威胁，可能导致连接降级。
    • UI 设计普遍不足: 27 款客户端 (约 93%) 存在至少一种 UI 提示缺陷，最常见的是在自动获取配置后不寻求用户确认，为静默攻击大开方便之门。

  • 新发现漏洞的实际影响:

    • 论文发现的一个新漏洞（可能指 A2 或其他）影响巨大。例如，Nextcloud Mail 客户端在构造 URL 时不验证域名格式，这可能导致来自至少 24,149 个域名的用户被劫持到攻击者服务器。

• 消融实验/参数分析 (Ablation Studies / Parameter Analysis): 本文的性质是测量和安全分析，而非提出新模型，因此没有传统的“消融实验”。但是，其对 10 种攻击场景的分类和对服务器/客户端缺陷的独立统计，起到了类似的作用，让我们能够清晰地看到每一种缺陷（如明文传输、配置不一致、UI 缺失）分别造成了多大的影响。例如，报告指出 55% 的域名受 Type-I 威胁影响，其主要原因是明文传输配置，这凸显了 A1 场景是当前最大的风险点。

7. 总结与思考 (Conclusion & Personal Thoughts)

• 结论总结 (Conclusion Summary): 该论文首次对电子邮件自动配置的安全性进行了系统性的、大规模的实证研究。研究发现，无论是服务器端的部署还是客户端的实现，都普遍存在严重的安全缺陷。作者总结了 10 种攻击场景，并用数据证明了这些威胁在真实世界中影响广泛，甚至波及顶级流行域名和主流邮件客户端。这些缺陷的根源在于错误的配置、管理疏忽、有缺陷的实现和为了兼容性牺牲安全。论文的发现敲响了警钟，呼吁社区重新审视并加强电子邮件自动配置的安全性。

• 局限性与未来工作 (Limitations & Future Work):

  • 作者指出的局限性 (从论文 VIII-D 可推断):
    1. DNS 安全: 论文没有考虑 DNS 投毒或劫持等针对 DNS 系统的攻击，因为这些攻击是通用性的，不特定于邮件自动配置。
    2. 攻击的普遍性: 尽管发现了大量漏洞，但评估它们在现实中被利用的频率超出了本文范围。
  • 未来工作方向:
    1. 开发更安全的自动配置标准: 目前 Autodiscover 和 Autoconfig 等事实标准存在设计缺陷（如允许 HTTP 回退）。社区需要一个统一的、安全优先的新标准。
    2. 开发自动化检测工具: 为系统管理员和开发者提供工具，用于检测服务器配置和客户端实现中的安全漏洞。
    3. 提升安全意识: 向邮件服务提供商和客户端开发者普及这些安全风险，推动他们修复漏洞并采纳安全最佳实践。

• 个人启发与批判 (Personal Insights & Critique):

  • 启发:
    1. “便利性”与“安全性”的经典权衡: 电子邮件自动配置是提升用户体验的典型例子，但这篇论文深刻地揭示了，在缺乏严格安全设计和审查的情况下，这种便利性会直接转化为巨大的安全风险。
    2. “事实标准”的脆弱性: 像 Autodiscover 这样由大公司主导、广泛应用但非正式 RFC 的“事实标准”，其演化和实现过程中的安全考虑可能不足。当多个不兼容的“事实标准”并存时，问题会更加复杂，正如 A10 攻击场景所示。
    3. 生态系统安全研究的重要性: 单独分析一个协议或一个软件是不够的。这篇论文的成功之处在于它将服务器、客户端、多种协议和用户界面作为一个完整的生态系统来考察，从而发现了单一视角下难以察觉的“跨组件”漏洞（如配置不一致）。
  • 批判/可改进之处:
    1. 攻击者能力的假设: 论文中的 Type-I 和 Type-II 攻击大多需要攻击者处于网络路径上 (MITM)。虽然这在公共 Wi-Fi 等场景下是现实的，但其威胁等级可能低于可以远程、大规模利用的漏洞。对漏洞的危险等级进行更细致的划分会更有价值。
    2. 解决方案的探讨可以更深入: 论文在指出问题方面做得非常出色，但在提出具体、可落地的解决方案方面着墨不多。例如，除了呼吁制定新标准外，是否可以为现有的 Autoconfig/Autodiscover 设计一个向后兼容的安全扩展（类似 HTTPS 对 HTTP 的升级），可能会更具短期现实意义。
    3. 原文不完整声明: 需要注意的是，本次分析基于不完整的论文文本。完整的论文可能包含更多关于客户端测试的细节、对策讨论以及更详尽的附录，这些都可能影响对论文的全面评价。