电子邮件身份验证对于自动发送的邮件至关重要，包括密码重置、发票和交易邮件。SPF 根据信封发件人域或 Return-Path 域授权发送服务器。DKIM 使用 DNS 中发布的域名对邮件进行加密签名，以验证邮件的真实性和完整性。DMARC 要求 SPF 或 DKIM 与可见发件人域对齐，并向接收方说明如何处理验证失败的邮件以及将报告发送到哪里。
请为专用发送子域配置这些记录。添加邮件服务提供商的 DKIM CNAME 记录，为自定义 MAIL FROM 域配置 SPF 和 MX 记录，并在 `_dmarc` 位置发布 DMARC 策略。开始时设置为 `p=none`，监控汇总报告；待所有合法发件方验证通过后，再调整为 `quarantine` 或 `reject`。
由于 SPF、DKIM 和 DMARC 检查的域各不相同，因此即使 SPF 和 DKIM 都通过验证，DMARC 仍可能失败。请确认保存的 DNS 名称正确，关闭 DKIM 记录的 Cloudflare 代理，避免创建重复的 SPF 记录，并通过生产应用程序的发送流程进行测试。身份验证有助于提高邮件送达率，但不能保证邮件进入收件箱；发件信誉、邮件内容、投诉率和发送模式也会产生影响。
每日HackerNews RSS
一则 Hacker News 讨论批评了一篇关于 SPF、DKIM 和 DMARC 的 MailFully 指南，称其内容像是由 AI 生成，整体方向基本正确，但不够完整。有经验的运维人员指出，生产环境中的邮件配置还需要正确设置 MTA 身份、正反向 DNS 和 PTR 记录，谨慎制定 SPF 策略，管理 DKIM 密钥，确保 DMARC 对齐并持续监控，配置可信 IP 地址，以及逐步部署。
发件声誉很大程度上取决于用户是否持续互动以及投诉率是否较低。AWS SES 可以简化基础设施配置，但无法自动解决发件声誉问题。
讨论者强调，SPF 验证的是 SMTP 信封发件人，即 `MAIL FROM`，而不是用户可见的 `From` 或 `Reply-To` 地址。因此，即使某个 SendGrid 子域名获得了 SPF 授权，也不能自动覆盖以主域名地址发送的邮件。
DMARC 有助于防止域名仿冒和钓鱼，但无法判断邮件是否为垃圾邮件；通过身份验证的邮件仍然可能是垃圾邮件。因此，仍需使用黑名单、贝叶斯过滤器、启发式规则和内容策略。拒绝所有未通过 DMARC 验证的邮件，也可能导致合法的转发邮件被拦截。
推荐的资料包括 OpenSPF、LearnDMARC、LinuxBabe 的配置指南，以及 Gmail 的“查看原始邮件”诊断功能。一位评论者提议，在发送给从未订阅过相关邮件的真人邮箱中加入异常的反订阅链接，将其作为垃圾邮件过滤器的蜜罐。
**目标标准** 多年来，Hacker News 给 AI 出了不少难题。AI 完成了哪些？ **投票结果** 此页面需要启用 JavaScript。 那是最后一条评论。 查看结果。 正在加载评论…… 这种情况发生过吗？ - 是 - 不确定 - 否
一则 Hacker News 讨论回应了“Goalposts”调查。该调查追踪历史上的 AI 预测和挑战是否已经实现。参与者普遍认为，记录这些说法很有价值，但对该项目提取具体主张的方式提出质疑：许多主张表述含糊、转述不准确，或被删去了“可靠地”“完全地”“不出现错误”等关键限定条件。
主要争议包括：
- **数学：** 据报道，AI 已经解决了一些开放问题，包括纳维－斯托克斯方程，但人类是否参与、相关工作是否尚未发表、证明是否真正有用，以及过程是否透明，仍有争议。
- **编程：** 前沿模型可以快速构建相当复杂的应用，但它们在无人监督下且不出现 bug 的可靠性仍存争议。
- **图灵测试：** 日常对话可能已经能骗过许多人，但更长时间、带有对抗性的交流仍会暴露 AI 的特征，并出现上下文理解能力下降。
- **创意和专业任务：** 对于连贯的长文写作、视觉理解、税务处理、业务自动化和创意多样性，意见存在分歧。
- **移动标准：** 一些人认为预测仍未实现；另一些人则认为，benchmark 的范围被人为扩大，或定义得不合理。
几名评论者建议采用更清晰的测试、公开推理记录，或设置金钱赌注，以增强问责。
arXivLabs 是一个框架，使参与者能够直接在我们的网站上开发并分享新的 arXiv 功能。参与 arXivLabs 的个人和组织均认同并接受了我们的价值观：开放、社区、卓越以及保护用户数据隐私。arXiv 致力于践行这些价值观，并且只与遵守这些价值观的合作伙伴合作。如果你有一个能为 arXiv 社区创造价值的项目创意，请进一步了解 arXivLabs。
Hacker News 上的讨论聚焦于一篇论文，该论文让大型语言模型（LLM）将上下文视为一个可编辑的文件，并学习随着时间推移应当保留、删除或总结哪些信息。
主要担忧在于 KV 缓存的效率。当较早的上下文发生变化时，传统的前缀缓存就会失效，因此不受限制地编辑上下文会产生高昂成本，尤其是在使用标准 API 时。据称，研究人员部分通过模型侧的缓存处理来解决这一问题，但评论者正在讨论复用过期缓存状态可能带来的影响。RoPE 位置编码会使任意插入和删除内容变得更加复杂，而不稳定的缓存内容可能只会对模型产生细微的引导或干扰，不一定会导致明显的失败。
人们提出的替代方案包括专门的上下文管理模型、固定的摘要区域、外部日志和文件系统产物、检索系统，以及“将上下文视为数据库”的设计。这些方案会带来额外的成本、复杂性或注意力开销。
一些怀疑者认为，这项工作只是给已有的智能体记忆或上下文压缩技术换上了更新的术语。另一些人则认为 jointly learning context management and cache-aware inference might represent a meaningful architectural advance. Ultimately, benchmarks and serving efficiency will determine whether it is genuinely novel.</mm:think>Hacker News 上的讨论聚焦于一篇论文。该论文让大型语言模型（LLM）将上下文视为可编辑的文件，并学习随着时间推移应保留、删除或总结哪些信息。
主要担忧在于 KV 缓存的效率。当较早的上下文发生变化时，传统的前缀缓存就会失效，因此不受限制地编辑上下文会产生高昂成本，尤其是在使用标准 API 时。据称，研究人员部分通过模型侧的缓存处理来解决这一问题，但评论者正在讨论复用过期缓存状态可能带来的影响。RoPE 位置编码会使任意插入和删除内容变得更加复杂，而不稳定的缓存内容可能只会对模型产生细微的引导或干扰，不一定会导致明显的失败。
人们提出的替代方案包括专门的上下文管理模型、固定的摘要区域、外部日志和文件系统产物、检索系统，以及“将上下文视为数据库”的设计。这些方案会带来额外的成本、复杂性或注意力开销。
一些怀疑者认为，这项工作只是给已有的智能体记忆或上下文压缩技术换上了更新的术语。另一些人则认为，将上下文管理与缓存感知推理结合起来学习，可能代表着一项有意义的架构进展。最终，它是否真正具有创新性，将取决于基准测试结果和服务效率。
轻量级 PDF 解析器，支持版面、表格、公式和边界框。 Lightweight PDF parser with layout, tables, formulas and bounding boxes
2 天前
**papero** 是一款采用 MIT 许可证、基于几何的文档提取工具，可将 PDF 及其他受支持的文件转换为结构化数据，无需机器学习模型或 GPU。它可在浏览器、Python、CLI 或 REST API 中本地运行，使 PDF 始终保留在用户的设备上。
其基于 PDFium 的引擎能够重建多栏阅读顺序、分离页眉和页脚、检测有边框及无边框表格、将公式转换为近似 LaTeX、裁剪图表，并保留边界框、字体、对齐方式、缩进和文本样式。Apache Tika 提供元数据、带标签的文档结构、OCR，以及对 DOCX、PPTX、XLSX、EPUB 和 HTML 的支持。
输出包括 Markdown、JSON、文本、保留布局信息的 HTML、CSV 表格、包含图像的 ZIP 压缩包、Word、Excel，以及按页面划分的块数据。Python API 提供对页面、块、表格、公式、图表和导出选项的访问；同时还提供 Docker 和交互式 API 文档。
其限制包括：复杂数学公式的线性化、紧密排列的无边框表格可能识别错误、服务器端 OCR，以及 Word/Excel 导出目前仅限于浏览器应用。报告的基准测试显示，在 54 篇测试论文中，每页的中位处理时间为 39 毫秒，且未出现失败。
一名开发者分享了一个开源轻量级 PDF 解析器。该工具在将文档转换为 Markdown、JSON、Excel 或 Word 时，能够保留阅读顺序、版面布局、表格、公式、图片及边界框。后续计划还包括进行结构感知的语义分块，以支持 RAG，并保留章节、页码及精确的视觉位置元数据。
初步反馈不一。一名用户表示，用它测试 MiniSat 论文时，结果极其糟糕；另一名用户则表示会将其与 Firecrawl 的 AnyDoc 进行比较。有评论者询问能否在转换前将 PDF 裁剪为特定区域，但这一点尚未得到解答。
对于加拿大银行对账单，`pdftotext -layout` 的效果明显优于该解析器。不过，该评论者也认为，可以使用脚本或本地 LLM 对提取的数据进行结构化处理，从而避免将敏感的财务记录发送到外部服务。另一名用户希望该工具能够与 Zotero 集成，以便从研究论文中提取表格和公式。开发者邀请大家就其架构、输出质量及应用场景提供反馈。
多个项目发现 ESP32 微控制器隐藏的 SDR 功能 Various Projects Find Hidden SDR Capabilities in ESP32 Microcontrollers
2 天前
ESPARGOS 团队发现了尚未公开的 ESP32 原始 IQ 信号采集功能，使受支持的开发板能够作为低成本 SDR 使用。其频率覆盖范围为 2.2–2.7 GHz，ESP32-C5 还支持 4.8–6.0 GHz；采样率最高可达 80 MS/s，模拟带宽约为 13–54 MHz。大多数型号只能导出信号快照，因此主要用于频谱分析。ESP32-S31 可通过千兆以太网以最高 16 MS/s 的速率连续传输数据，并计划支持 GNU Radio 和 gqrx。
相位相干采集如今使 ESPARGOS 能够对任意 2.4 GHz 信号进行测向，不再局限于 Wi-Fi 和蓝牙。其他项目也独立采用了类似技术：其中一个项目使用 ESP32-S3 加 FPGA，通过 USB 3 连续传输 IQ 数据，但与时钟相关的相位噪声问题仍未解决；C5VRX 则使用 ESP32-C5 在设备上直接解调 5.8 GHz FPV 视频。ESP-WebSDR 还支持在浏览器中刷写固件并实时查看频谱。
Hacker News 用户对一些项目感到兴奋，这些项目揭示了廉价 ESP32 芯片此前未公开的软件定义无线电能力。ESP32-S3 似乎可以将频率调谐到大约 2.2–2.8 GHz，从而接收 Wi-Fi、802.11p 车辆到基础设施通信，甚至可能接收卫星下行信号。较新的 ESP32-S31 可以通过 USB 传输每秒 2000 万采样的 8 位数据，以较低成本获取远超普通蓝牙和 Wi-Fi 使用范围的频谱。
爱好者认为，这为教育、业余无线电、传感器网络、交通监控和低成本实验带来了巨大机遇。不过，信号质量问题仍然存在，包括相位噪声、镜像和直流偏移。在一些地区，ESP32 开发板也已缺货。
随后展开了一场 lengthy 的监管讨论。参与者指出，各国的发射法规有所不同，而且经过 FCC 认证的硬件必须遵守严格的功率、频率和防篡改要求。尽管 ESP32 芯片已经可以通过 GPIO 技巧或调试接口生成射频信号，但故意滥用这些功能可能造成干扰，并引起监管部门的关注。总体而言，评论者认为，这些发现大幅降低了软件定义无线电实验的成本和复杂度。
ParadeDB 在 PlanetScale 的 TIN 扩展最初带来显著更高的 BM25 性能后，对自家基于 Tantivy 的文本搜索进行了优化。主要改进包括：将 fieldnorms 与 postings 一起存储，以提升内存局部性；为稠密的多词项析取查询增加 MAXSCORE 剪枝路径；以及进行多项惰性加载优化。在 Hacker News 数据集上，ParadeDB 的吞吐量达到 344.6 QPS，而 TIN 为 145.7 QPS。
ParadeDB 还发现了基准测试中的差异：TIN 只搜索一个字段，而 ParadeDB 实际上搜索了两个字段；此外，TIN 的稠密词项消除机制会跳过常见词的评分，因此生成的是近似 BM25 排名，而不是精确排名。在 StackExchange 数据集上使用精确 BM25 时，ParadeDB 的吞吐量为 81.9 QPS，而 TIN 为 35.5 QPS；启用停用词后，ParadeDB 的吞吐量提升至 161.9 QPS。
该文章否定了“ctid 标识符天然更优”的说法。稠密的 u32 ID 能够高效压缩，并且可以自然地映射到列式数据，而列式数据正是过滤、排序和分面聚合所需要的。ParadeDB 仍将继续使用 Tantivy，并计划在 0.26.0 版本中将这些向后兼容的优化提交到上游，不过届时需要重建索引。
ParadeDB 发布了一篇文章，介绍了其在基准测试暴露出高达八倍的性能下降后所做的搜索性能改进。团队对性能瓶颈进行了分析、优化并分享了相关成果；因其将竞争性基准测试视为提升工程水平的机会，而非单纯追逐榜单的做法，赢得了赞誉。
讨论还提到 ParadeDB 采用了 AGPL-3.0 许可证。该公司表示，此举旨在防止超大规模云服务商将社区割裂。维护者称，项目已有超过 150 名社区成员参与贡献；他们接受问题报告和拉取请求，但会严格拒绝质量低下或由 AI 生成的提交内容。
一些用户分享了生产环境中的使用经验，其中一个部署实例索引了超过 1 亿条记录，索引规模达到 4 TB。部分评论者仍对 ParadeDB 这种专注于特定搜索领域的产品能否实现可持续商业经营表示怀疑。
总体而言，这篇文章获得了 65 分和 10 条评论。
Git 3.0 即将默认采用 SHA-256，这将是一个代价高昂的错误。 Git 3.0's upcoming SHA-256 default will be a costly mistake
2 天前
作者认为，Git 3.0 计划从 SHA-1 切换到 SHA-256，将给整个生态系统带来巨大的成本，而实际安全收益却很小。尽管 SHA-1 在实际应用中存在碰撞弱点，但意外碰撞仍几乎不可能发生；现实中的攻击仍需要先攻破代码仓库、可信分发渠道，或实施精密的社会工程。在 Git 中，信任主要来自仓库来源、身份认证、代码审查和签名，而非内部的对象哈希算法。 默认采用 SHA-256 会造成仓库格式不兼容，并给托管服务、子模块、镜像、签名、URL、库、脚本和工具带来复杂性。现有仓库将面临艰难且需要多方协调的迁移，而许多组织最终也可能覆盖这一新默认值。 更好的替代方案是让 Git 的对象模型继续使用 SHA-1，同时为已签名的提交或标签独立计算并添加更强大的校验和。这样，验证时可以使用 SHA-256、BLAKE3 或多种算法，而无需重写历史记录。`git-evtag` 等现有工具已经采用了类似做法；基准测试也表明，即使面对非常大的仓库，生成校验和的速度依然很快。
Hacker News 的一则讨论围绕 Git 维护者、GitHub 联合创始人 Scott Chacon 的警告展开：在 Git 3.0 中将 SHA-256 设为默认哈希算法，可能是一个代价高昂的错误。他认为，Git 哈希主要用于标识内容；实际可行的碰撞攻击成本仍然极高，而真正的安全应来自可信的分发渠道。如果在整个仓库中替换哈希算法，就会重写每个提交 ID，从而使外部链接、CI 缓存、软件包锁定引用、溯源记录、签名以及代码托管平台的兼容性失效，尤其是子模块。因此，他主张改为提供可选的、独立的更强哈希和签名机制。
许多评论者不接受他的安全模型：人们经常使用提交哈希来验证来自不可信镜像的不可变快照，而 Git 的签名提交最终仍依赖其 Merkle 树哈希。他们指出，SHA-1 的碰撞安全性已经被突破，攻击成本因攻击者而异；Git 使用能够检测碰撞的 SHA-1DC，而合规要求也可能迫使项目迁移。另一些人把这次转变比作 Python 2 到 Python 3 的迁移：过程痛苦，但迁移是有道理的。尽管各方意见不一，许多人都认同，兼容性和长期支持通过旧哈希查找对象是不可或缺的。
启用 JavaScript 和 Cookie 以继续
《黑客新闻》的一则讨论帖围绕加拿大加快批准一条通往太平洋的输油管道展开。支持者认为，此举可以减少加拿大对美国的依赖，并使出口更多地面向亚洲市场。他们指出，该项目可能推动石油产量增长，降低对加拿大铁路运输和美国买家的依赖，增加财政收入，并支撑长期经济增长。批评者则质疑其气候代价、对原住民土地的影响、项目可行性，以及管道投资是否真正符合加拿大国家利益，而非仅仅服务于阿尔伯塔省或美国的政策。
更大的争议集中在不断恶化的美加关系。评论者认为，关税、吞并加拿大的言论、对相关机构的威胁，以及特朗普总统更广泛的贸易侵略行为，都在破坏加拿大对美国的信任。如今，许多加拿大人主张加强军事、科技和边境建设，并推动贸易关系进一步转向欧洲和亚洲。另一些人则认为，特朗普的现象反映了美国政治中更深层的问题，而且相关政策可能在未来历届政府中继续延续。
讨论还涉及《美墨加协定》是否仍然有效、加拿大乳制品保护措施的作用，以及与美国脱钩究竟是审慎之举，还是会作出不必要且难以逆转的决定。
Cloudflare 推出了 Clef 和 Clef-flash 决策模型，旨在为智能体工作流生成快速、一致且范围明确的结构化分类结果。与通用大语言模型不同，它们会返回受模式约束的答案及经过校准的概率，并且无需重新训练即可处理新类别。两种模型均支持图像输入和 64K 上下文窗口，其中 Clef 侧重准确性，Clef-flash 侧重低延迟。 在 Cloudflare 的网站分类测试中，Clef 用时 2.2 秒完成工作流，而 GPT-OSS-120B 用时 4.7 秒，同时 Clef 返回的分类结果更多。在 43 项基准测试中，Clef 系列模型也取得了较高的准确率，且整体延迟低于其他决策模型。 这些模型可通过 Workers AI 使用，并已在 Hugging Face 上以 Apache 2.0 许可证发布。它们完全兼容 Jev-API，并生成严格类型化的输出，便于集成。 Cloudflare 还将推出一项面向定制工作负载的强化学习微调服务。初期由驻场工程师提供支持，未来将转为自助服务。该服务将使用 Cloudflare 的 AI Gateway、Workers AI、Containers 和模型训练基础设施。潜在应用包括客户支持分流、信任与安全审查、威胁情报和机器人分类。
Cloudflare 发布了 **Clef**。这是一系列基于后训练 Qwen 模型的开放权重多模态决策模型，同时配有用于监督微调和强化学习微调的工具。Clef 能够输出结构化选项、评分和类置信度结果，可用于分类、内容审核、路由、智能体工作流及其他自动化任务。其模型权重已公开，但训练数据和完整训练方案并未公开，因此它属于开放权重，而非完全开源。
讨论主要围绕 Clef 与 Typesafe 的 **Jev** 展开。Cloudflare 表示 Clef 的基准测试准确率更高，但独立测试发现，在真实分类任务中，Clef 往往速度更慢、成本更高，偶尔准确性反而更低。其更大的模型规模和对视觉输入的支持，可能解释了其中一些取舍。
许多评论者认为，“决策模型”并不是新概念，只是换了新的包装：受约束的大语言模型输出、分类器、词元概率、后训练和概率校准都属于这一范畴。真正的难点在于校准、代表性数据、稳健的评估，以及判断模型输出何时可以安全地驱动自主行动。
总体而言，评论者认可 Clef 在低成本专用 AI 和本地推理方面的潜力，但也质疑其创新性、基准测试结果的泛化能力、可靠性，以及微调是否仍有必要。
turbopuffer 正在重新设计其存储架构（“v3”），以支持更多查询方案、更大的规模和更好的性能。 其原有架构将 ANN 向量索引作为主键：文档存储在基于聚类的 ANN 地址下，属性和全文检索倒排项则引用这些地址。这种方式对向量搜索非常有效，能够支持超过 1000 亿个向量的索引，在每秒超过 1000 次查询（QPS）的情况下实现 200 毫秒的 p99 读取延迟，但也带来了三个主要限制： - **存储放大：** 多向量文档会重复存储非向量数据。 - **写入放大：** ANN 负载均衡会迫使文档数据和二级索引一起迁移。 - **向量化受限：** 查询引擎受 ANN 聚类大小限制，无法使用更大、更高效的块。 turbopuffer v3 不再将 ANN 地址作为主键。文档改为独立存储，ANN 则像属性和全文搜索一样，成为二级索引。这样，每种查询方案都可以采用针对其执行模式优化的布局。 这次重新设计并不简单。尽管所有持续集成（CI）测试目前都已通过，但新架构最初导致生产环境性能明显下降，因为团队优先保证正确性和基础设计，而非性能调优。现在，团队已经开始进行性能优化，并计划在改进过程中持续发布基准测试结果。
Turbopuffer v3 放弃了以向量为主键的存储方式，转而采用更传统的设计：文档使用稳定的内部 ID，ANN 则作为二级索引。这类似于 PostgreSQL 与 InnoDB 之间的取舍：PostgreSQL 通过直接指向行来换取更快的读取速度，而 MySQL 则让二级索引指向稳定的主键，以提高写入效率。
支持者认为，这一改动减少了 ANN 重新平衡导致的高成本索引重写；批评者则质疑额外的一层查找是否会增加延迟，尤其是在冷存储的 p99 延迟方面。开发者表示，各集群可以在本地保留向量，因此只有获取结果时才会产生这层间接访问。
许多评论者认为，“向量数据库已死”只是夸大的营销说法。向量搜索正在成为更广泛检索系统中的一种查询原语，而传统数据库和搜索引擎也越来越多地支持它。独立的向量存储还会带来同步和运维复杂度。
另一个讨论分支则质疑，AI 生成的评论是否正在破坏 Hacker News 的讨论质量，以及采用邀请制准入的社区是否更能遏制垃圾信息。