现代电子邮件可以由借来的部件构建而成
围绕基于 HTTP 等现代 Web 标准重构电子邮件的努力，重新点燃了关于垃圾邮件控制、身份和用户同意的长期争论。评论者探讨了首次联系审批、可选邮资或微支付以提高群发邮件成本，以及与聊天式消息更紧密集成等想法，同时指出强大的网络效应让 SMTP 继续占据主导地位，而大型提供商则凭借信誉系统拥有巨大权力。许多人仍然怀疑，任何技术上更优的替代方案若没有广泛的社区和行业支持都难以落地，尤其是在电子邮件已经深度嵌入且过去那些“终极”反垃圾方案都失败的情况下。
首次联系同意与“请求”收件箱
- 许多人喜欢这样的想法：未知发件人先进入“请求”区域，然后才进入收件箱，类似现代聊天应用。
- 也有人指出，类似模式其实已经存在：服务器上的灰名单、手动白名单、带确认链接或令牌的自动回复，以及 Hey/Spark 之类的服务。
- 报告中的用户反应褒贬不一：有人说人们“讨厌”额外步骤；也有人说几乎没人抱怨，而且人们愿意通过确认来联系到对方。
- 批评者认为这只是把问题移开了： “请求”文件夹会变成新的垃圾邮件文件夹，合法的首次联系会被埋没。
电子邮件 vs 直接消息
- 有人询问，改进后的电子邮件规范是否可以取代 WhatsApp 式消息；DeltaChat 被提及为连接电子邮件和聊天的例子。
- 也有人强调工作流不同：电子邮件像邮箱，而聊天则像无限线程；他们抱怨难以为法律工作之类的场景提取特定主题的线程。
垃圾邮件、邮资与同意
- 多项提案涉及“邮资”或按条消息计费，理想情况下在低量时极便宜，但随着规模增长而上升，以使群发垃圾邮件在经济上不划算。
- 微支付被广泛认为不切实际；身份轮换削弱了基于流量的定价。
- 其他建议包括：明确的“Automated: 0/1”头字段，并通过信誉机制执行；自动邮件必须获得强制同意；以及按发件人预先批准并隔离。
- 域名/IP 级别的信誉和黑名单被描述为当今反垃圾邮件的核心，而自建邮件服务器者往往很难应对。
协议、HTTP 与兼容性
- 有些人喜欢基于 HTTP 和现有工具（MTA-STS、JMAP、Web Key Directory）构建，在 SMTP 上做渐进演化，而不是彻底替换。
- 另一些人不喜欢“通过 HTTP 发送电子邮件”，更偏好 DNS/MX/SRV 和 DANE，并警告诸如内容寻址邮件会破坏邮件列表或未加密元数据之类的问题。
- 有人提出一种混合式“NewEmail”覆盖层：当双方都支持时自动升级传递（类似 iMessage 与 SMS），并认为向后兼容至关重要。
UX、可访问性与更广泛的怀疑
- 一些人认为真正的问题在于 UX 和客户端，而不是协议；另一些人则认为现有 GUI 已经足够好且各有不同。
- 文章网站上的可访问性问题和令人分心的界面也受到批评。
- 多条评论强调历史教训：无数“修复电子邮件”和“解决垃圾邮件”的方案都失败了；电子邮件已经根深蒂固，被大型提供商“捕获”，而且运作得还算足够好，因此激进改变不太可能。