mattdm
(Matthew Miller)
1
该帖子因重复而被关闭 Email: mail headers should have tags in them，可能引用了 https://meta.discourse.org/t/customs-email-headers-and-or-subjects-tags/16873，但后者比较笼统，我想讨论我们遇到的一个具体问题：
我们使用标签作为各种项目子主题的几十个邮件列表的逻辑替代品。我们开始使用分类，但这变得难以管理——分类是笨重的，不允许轻松的交叉发布，并且由于许多其他原因，我们认为标签更合适。
然而……有一个问题。虽然可以在电子邮件通知模板中放置 %{optional_tags}，但 Gmail 非常有限的过滤功能对此无能为力——而且，即使对于老派邮件用户来说，编写一个解析主题行并进行解析的 procmail 规则也有些麻烦。
所以，最好将标签放在别处。对于 procmail 用户来说，自定义 X-Tags 标头就可以了，但 Gmail 不会关心，所以我们需要其他东西。
一个想法是实际使用标签作为 List-ID，但 我不确定 Gmail 是否会正确处理多个 List-ID 标签 不允许使用多个 List-ID 字段 。另一个想法，有点笨拙但我认为会奏效：将 tag@subdomain.example.org（以及可能还有 tag2@subdomain.example.org、tag3@subdomain.example.org 等）放在 CC 列表中。Google 可以 根据此进行过滤，并且大多数其他系统也具有处理 CC 作为多值字段的合理高级功能。而且，我们会将实际发送到这些地址的任何邮件重定向到虚空。
作为奖励，CC 方法还可以用作在传入邮件上添加标签的方法（参见 https://meta.discourse.org/t/add-tags-by-email/25796）。同样，有点笨拙，但话说回来，_所有电子邮件在 2022 年都是如此_。
2 个赞
mattdm
(Matthew Miller)
2
如果您有任何其他建议或想法，我都很乐意听取。没有这些，我们无法合理地建议大规模迁移到 Discourse。
你的具体用例是什么？
我想了解你为什么觉得需要帮助人们过滤来自你网站的电子邮件通知。Discourse 的预期用途是社区成员只需使用电子邮件通知来了解他们关心的活动，并在他们想参与讨论时点击链接登录。对于那些希望这样做的网站，可以启用通过电子邮件回复。但成员仍然应该习惯于登录到网站上继续讨论。
这样，每个人都可以从组织和管理网站上的讨论的协作努力中受益并做出贡献。而且你不会得到一堆过时的讨论，这些讨论被孤立在每个人的电子邮件文件夹中。当 Discourse 按预期使用时，收到的电子邮件通知可以被直接删除。
电子邮件出了名的难以正确处理，这不仅仅是 Discourse 的问题。你的社区成员越多登录并参与你的网站，你的社区就会越成功（并且越容易管理）。
也许 Discourse 不适合你的社区，或者你需要保留一些邮件列表，同时建立你的 Discourse 网站？我知道改变长期社区的习惯可能很难。
祝你好运！
2 个赞
pfaffman
(Jay Pfaffman)
6
我认为可能是对的。
你们还有 procmail 用户？还有 Gmail 用户和 Discourse 用户？让这三组人都满意将非常困难。
如果你们的预算是 2000-5000 美元，那么你们或许可以得到一个定制插件来完成你们的要求，但很难想象这能让任何人满意。一旦解决了现在已知的问题，你们也不知道还会出现什么其他问题。这让我想起了管理邮件列表，当时有一大群人使用不符合 RFC-822 标准的基于局域网的邮件网关（那是我还在使用 procmail 和 emacs rmail 的时候）。这个问题简直是无法解决的。
我建议就使用分类。或者，如果你们真的想要遵循几十年前惯例的邮件列表，那就坚持使用有效的方案。
2 个赞
Stephen
(Stephen)
7
如果这些功能已经存在于其他基于传统邮件列表模式的平台中，那么你在那里可能会更成功，而不是要求将它们改造到一个更具未来导向的产品上。
换句话说，如果这是一个决定性因素，为什么一开始要考虑 Discourse 呢？能否扩展 HyperKitty 来添加你需要的功能？
1 个赞
mattdm
(Matthew Miller)
8
目标
目前，Fedora 有数百个邮件列表， 其中约有 90 个有一定程度的活跃度，还有少数几个非常活跃。我想将所有这些整合到一个地方，包括成功地吸引我们的贡献者社区加入。如果比 Discourse 有更好的选择，那么目前还没有人创造出来。
简而言之
我为此积极努力了_三年_，并思考了_至少十年_。在与社区成员谈论阻碍他们的问题时，这个问题反复出现。
长篇大论：
差不多在 Discourse 出现的同时[^1]，我们创建了一个 Mailman3 的图形界面前端，名为 Hyperkitty，旨在成为一个现代化的 Web UI，供人们访问底层的邮件列表。您可以在Fedora Devel List上看到它的实际运行效果。
Hyperkitty 有一些不错的想法，但实际上并没有获得足够规模的资金来取得成功，最终以初始设计发布，并且没有提供改进和修复的计划。而且，它以电子邮件作为底层基础，这确实限制了我们[^2]——即使我们有资源，将其作为最大公约数[^3]也会成为一个令人沮丧的限制。
所以我理解您的处境。如果您通过 Wayback Machine 浏览discourse.org 的历史，您可以看到[^4]，Discourse 从论坛和邮件列表中吸取了经验教训，并试图取代两者……
……而且这在今天基本得以保留，尽管在各个页面上关于邮件列表的其他讨论有所减少。您经历了与我们如果拥有资源投资 Hyperkitty 时会经历的相同情况——电子邮件作为太低的最高基线问题——并得出了合乎逻辑的结论。我完全理解您现在明确表示将用户引导至网站是正确做法的出发点。
当前：
- 我们有几十个活跃的邮件列表
- 拥有数百名活跃参与者
- 以及数千名被动订阅者。
- 这些列表的历史可以追溯到_整整 20 多年_。
- 许多老派的开源人士_非常_依恋这种工作方式。
- 它很熟悉，
- 已经设置好了，并且
- 每天都会自动送达，无需添加“查看某个网站”
- 许多人活跃于项目的不同部分，但这种“足迹”非常个人化
但是：
一、这些列表的功能不如许多人想象的那么好：
- 几乎不可能进行版主管理（最多只能一刀切）
- 尽管付出了努力，人们并不总是遵守我们期望的标准
- 超长帖子不是好的讨论方式
- 很容易发起列表外的骚扰，并且我们无法控制
- 跨帖子发布很混乱，因为订阅不一致
- 除非你_投入_，否则不可能跟上
- 应该参与的人由于上述各种原因而没有参与
二、电子邮件不是未来
- 邮件列表在很大程度上对搜索引擎不透明，并且在大多数人看来不像是“真实的活动”
- 新人不想注册邮件列表。[^5]
- 邮件列表的“文化”现在已经不复存在了。[^6]
- 而且 Gmail 的网页界面对内联回复等传统约定非常不友好。
三、总的来说，电子邮件注定要失败
- 大型提供商有能力为自己“解决”垃圾邮件问题，现在他们_没有动力_在全球范围内解决它。
- 小型提供商可靠发送邮件的机会越来越小。
- 邮件列表本质上会重新发布，而所有的签名和验证基础设施实际上并不关心。
- 公司正在转向 Slack 等工具进行_功能性沟通_，将电子邮件用于公告和广播。
- 以及 Jira 和 Github 等工具用于_以工作流为中心_的交互。
- 同样，“普通”人不再使用它，除了接收他们是客户的公司的通知。它不再是个人通信的工具了。
但是仍然有需求
我们已经覆盖了实时对话[^7]，但我们仍然需要邮件列表提供的长篇、异步对话。聊天无法涵盖所有内容，在全球范围内以及与不同时间承诺的志愿者合作效果不佳。而工作流工具则过于狭窄。
Discourse 确实是最佳选择
-
邮件列表不是一个可行的未来。
-
Hyperkitty 停留在 2014 年。
-
我们拥有的东西太多，无法仅使用 Github / Gitlab。
-
其他可能性都不行：
-
Ponymail 存在同样的电子邮件作为 GCF 问题
-
Vanilla 不太好。我就不说了。 
-
Google Groups 是_最糟糕的一切_。
-
Discourse 的优点：许多其他开源社区正在围绕它进行整合。特别是：Python，GNOME……
引入卡珊德拉
不是数据库——我是说，预言厄运却无人相信。我听到很多“电子邮件没问题”，“我看不出邮件列表有什么问题”，当然还有“我讨厌论坛”，甚至具体地说“我不喜欢 Discourse”。
但是，我们确实需要改变。
所以……
我需要让一个庞大、活跃、重要的开源社区将其主要的项目沟通平台迁移到 Discourse，而许多人对此持怀疑态度。这是一个巨大的变化。我想尽可能地简化它，既是为了让那些怀疑但愿意尝试的人_更容易、更愉快_，也是为了让那些将电子邮件交互（包括过滤）视为个人障碍的人_有可能尝试_。
我认为_一旦他们到了那里_，许多人会调整他们的行为——我们会让更多人发现直接与网站互动并非那么糟糕。[^8]而且我们有自己的项目范围通知系统，我计划将其集成，并希望最终能为人们提供他们_真正需要_的东西。
但在此期间，_我_需要满足人们的要求。
[^1]：事实上，我当时曾试图建议 Discourse 作为一种替代方法，而不是自己开发。如果我有时光机，我可能会回去更用力地推动它。但那时我不在现在的职位上，而且大局已定……
[^2]：我认为这是从LUGNET学到的类似教训，LUGNET 是 90 年代最令人惊叹和最明智的论坛软件——但它依赖于 NNTP 作为后端。
[^3]：我知道这个习语是“最小公分母”，但这没有意义。就像“我本可以少关心一点”，但现在还加上了_数学_。
[^4]：我的意思是，如果你还不记得的话，当然！
[^5]：在韩国，电子邮件是给老年人用的已经降临到我们所有人身上了！
[^6]：我记不起上一次听到有人说“网络礼仪”是什么时候了。
[^7]：使用 Matrix，地址为https://chat.fedoraproject.org/……
[^8]：尽管如此，我们_绝对_有这个人，所以不是每个人都会接受。
5 个赞
写得很好！
您能否更详细地描述一下您所说的、人们在电子邮件中依赖的过滤功能？我也接触这个领域很久了，自己也运行过 mailman 列表，并且参与（现在仍然参与）许多邮件列表，但我从未遇到过使用标头进行自动过滤。在我看来，如果有人订阅了一个列表，并且他们想将其过滤到电子邮件中的某个文件夹，他们会自己逐个列表进行设置。您也可以使用 discourse 来做到这一点，对吗？
我认为类别可以很好地替代邮件列表，用户启用邮件列表模式或关注某些类别，这样他们就会收到每篇帖子的电子邮件。也许我们还需要更多地了解您为什么认为将讨论组织成标签更好，并且值得付出努力来实现与现有类别功能的对等。
编辑：我想起了我 2014 年关于这个问题的旧帖子！
1 个赞
mattdm
(Matthew Miller)
11
当然。Discourse 目前设置的标头如下（来自此主题的实际通知）：
List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/efed8ca1777379c660afc031464b98eb4e6fa2323a71fa12fa2269eeca5b0905>
X-Discourse-Post-Id: 1216779
X-Discourse-Topic-Id: 249982
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Discourse Meta | feature <feature.meta.discourse.org>
List-Archive: https://meta.discourse.org/t/headers-for-email-notifications-so-that-gmail-users-can-filter-on-tags/249982
Feedback-ID: meta:user_replied:discoursemail
如果不是 Gmail，添加类似这样的内容：
X-Discourse-Tags: some-tag, another-tag
请参阅 Customs email headers and/or subjects tags - #6 by mattdm — 如果 email custom headers 设置通过模板扩展传递，以便 X-Discourse-Tags: %{optional_tags} 能够工作，那么这部分就已经可以了。
对于 procmail 和其他老式邮件客户端用户来说，这将足够了。不幸的是，出于某种谷歌无法理解的原因，Gmail 无法过滤任意标签，而且（据我所知）仅限于 To:、From:、Cc: 和……幸运的是，还有 List-ID。由于这是最关键的因素，为了照顾这些用户，我能想到的最好的方法是按标签而不是类别（或两者结合？）设置 List-ID。
然而，RFC 2919 规定每条消息只允许一个 List-ID。所以剩下：
- 任意选择一个标签
- 生成包含所有标签的内容，例如
List-ID: firsttag_secondtag.discourse.example.org，然后让用户自己去弄清楚。
- 为每次通知生成多封电子邮件，每封电子邮件对应一个标签，并且仅在此标头中有所不同
- 让 List-ID 指向类别，而是使用 CC 的想法……
我并不真正喜欢其中任何一个。所以作为第一步，X-Discourse-Tags: 至少可以覆盖非 Gmail 用户。（这可能与抗网络用户有很好的重叠，所以我认为值得尝试看看能达到什么效果。）
3 个赞
sam
(Sam Saffron)
13
非常支持添加 X-Discourse-Tags 和 X-Discourse-Category（为了保持一致性）。
我想对于 Gmail 来说，我们可以添加一个用户选项：
- 请将此主题所属的所有标签添加到电子邮件主题标题中。
例如：
[Discourse Meta] [feature] [email] [notifications] 电子邮件通知的标题
或者，启用后可能是：
[Discourse Meta] 电子邮件通知的标题 … [feature] [email] [notifications]
5 个赞
mattdm
(Matthew Miller)
14
是的，这作为用户选项会很有趣。我们目前在全站范围内是这样做的：
%{optional_re}%{topic_title} [Fedora] %{optional_pm}%{optional_tags}
我们收到了强烈的反馈，认为将标签放在最后以外的任何位置都很烦人。还有一些反馈认为 Google 在根据部分主题行进行有效过滤方面并不聪明。
我不确定我们能在多大程度上“修复”Google（或者更确切地说，我 非常 确定，而且是“没多少”）。所以可能需要一些“就这样吧”的程度，我得说服人们接受。
4 个赞
sam
(Sam Saffron)
15
我们可以做一些小事情来改善现状。
目前我们是：
- 限制为 3（任意顺序）
- 不将标签包裹在
[ ] 中
我还在犹豫，但认为任意 3 的限制不太好，我们应该直接删除它。
此外 tags.map{|t| "[#{t}]"}.join(" ") 会更好，因为这样过滤器就可以针对 [tagname] 而不是 tagname，后者更有可能出现在 PM 标题中。
@martin 怎么看？
5 个赞
pfaffman
(Jay Pfaffman)
16
了解了历史，这更有意义了。听起来您有预算来完成这些事情，并且有一些好主意可以开始。我认为这会很困难，导入所有数据将是一个挑战。让所有人都满意仍然会很困难，而且 Sam 至少支持您的一些想法，所以它们将成为核心的一部分，而不会像插件那样在未来被破坏。
3 个赞
martin
(Martin Brennan)
17
我同意你的看法，不过我认为与其完全移除限制，不如利用 max_tags_per_topic 设置？我认为这样更安全。
不幸的是，在标签周围添加 [] 对 Gmail 搜索帮助不大，只是视觉上的，因为据我所知（例如，查看 https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character，链接的文档已不再存在，但仍然有效），Gmail 在搜索主题和其他地方时会移除特殊字符。尝试在 Gmail 中搜索 subject:(\"[support]\")，你会得到主题中所有包含 support 的内容，而不仅仅是带有方括号的。这有点说不通，因为 Google 是一家搜索公司（嗯，搜索和广告），但我们对此无能为力。
正如你所说 @mattdm，我们还应该能够在 MessageBuilder 中轻松地同时添加 X-Discourse-Tags 和 X-Discourse-Category，因为我们现在已经有了这些选项，而且这很好地覆盖了那些不常使用网络的用户：
如果你愿意，我可以接手这个任务？
5 个赞
martin
(Martin Brennan)
21
我刚刚合并了 @mattdm 的这个更改：
它对 Gmail 的帮助不大，但至少应该能帮助基于终端的电子邮件用户，让他们更容易地过滤这些邮件。
6 个赞
sam
(Sam Saffron)
22
请注意 @mattdm，我们确实尝试过，但 Gmail 太难处理了。它在分词时会剥离掉很多文本，你的选择非常有限。
我能想到的唯一解决方法是在邮件中让标签名称非常难看：
“这是一个演示主题。[Temail, Tnotifications]”（添加前缀 T 或 Gmail “喜欢”的其他字母序列）
但这确实是一个相当难看且不直观的解决方案。
3 个赞
mattdm
(Matthew Miller)
23
谢谢 Sam（以及各位！）。
感谢大家为此付出的努力。归根结底，我们能做的就是尽力应对 Google 难以理解的决定。
是的，说得对。我能想到的唯一能做的更多的事情是添加一个每个用户选项：
使电子邮件通知主题行包含标签名称，采用非常难看的格式，以便 Gmail 可以进行过滤。
：-/
5 个赞