MailingListEtiquette
目录
邮件列表礼仪
在大多数开源项目中，都使用一种非常特定的电子邮件发布风格。本文档旨在记录该风格的主要要点。
主题
一些高流量邮件列表建议在主题行前加上方括号中的主题标签，以便读者更快地对线程进行分类并决定是否阅读。例如，如果您要发送到 openstack-discuss 并想讨论 Nova 的未来开发工作，您的主题可以是 [dev][nova] Nova 应该改名为 Avon！。
特别是对于 openstack-discuss 列表，请参阅OpenStack 项目团队指南中关于开放社区的章节，其中记录了对主题标签的广泛使用。
格式
纯文本
请不要发送 HTML 电子邮件。请仅发送纯文本电子邮件。您确实不需要 HTML 允许的任何花哨格式。此外，HTML 电子邮件会弄乱您在电子邮件中引用的任何代码的格式。
如果您确实发送 HTML 电子邮件（请不要），至少将您的客户端配置为包含纯文本替代附件。
换行
行应换行在 72 个字符或更少的位置。也就是说，在您发送的纯文本电子邮件中，每行将在第 72 列或之前包含一个回车符。
例外情况是引用的文本——引用的文本不需要换行，特别是如果您在回复中引用了某人的补丁。对引用的散文进行换行是可以接受的，以提高可读性，只要其含义没有在此过程中丢失。
回复
我们使用交叉式回复风格。您将对特定要点的回复直接放在引用的文本中的这些要点下方。
> Red is my favorite color. Red sucks. > But yellow is nice sometimes. I agree. Yellow is nice.
回复级别指示
当在回复中引用先前的电子邮件时，我们使用 > 来区分引用的文本和我们的电子邮件。您可以以这种方式缩进多层回复级别。
> > > Red is my favorite color. > > > > Red sucks. > > Does not! Does too!
署名行
引用的文本前面也应该有一个署名行。
Bob wrote: > Jim wrote: > > Bob wrote: > > > Red is my favorite color. > > > > Red sucks. > > Does not! Does too!
这很重要，因为如果有人被抄送到一个对话中但缺少上下文，署名行可以帮助他们理解到目前为止的对话。
修剪
您不需要引用整个电子邮件来回复一个特定的要点。与其这样做
> Red is my favorite color. Red sucks! > But yellow is nice sometimes. > > I have a lot of opinions on colors.
您应该修剪引用的电子邮件中与您的贡献无关的部分。因此，这将是足够的
> Red is my favorite color. Red sucks!
此外，在修剪时稍微重新格式化原始电子邮件也是可以的。与其这样
> Red is my favorite color. But yellow is nice sometimes. I have a Yellow rocks!
不如这样做
> But yellow is nice sometimes. Yellow rocks!
但是，不要过度修剪。保留任何可能对稍后加入线程的人有用的上下文。
线程
电子邮件客户端插入一个 Message-ID: 标头，当您回复一封电子邮件时，该电子邮件的 ID 将包含在您的回复的 In-Reply-To: 标头中。这使得电子邮件客户端可以像这样显示线程
From Subject Date Joe Pizza! 13.00 Ray Re: Pizza! 13.25 Sue Re: Pizza! 13.15 Bob Colors 12.02 Jim Re: Colors 13.05 Bob Re: Colors 13.10 Mary Re: Colors 12.30
另请参阅这个关于邮件列表线程的很好的例子。
许多处理大量电子邮件的人严重依赖像这样的线程。例如，他们可以快速浏览一个线程并将其中的所有电子邮件标记为已读。
当人们使用不能正确处理线程的邮件客户端或劫持线程用于完全不同的主题时，事情就会变得烦人。因此，您可能会得到
From Subject Date Bob Colors 12.02 Joe Pizza! 13.20 Ray Re: Pizza! 13.25 Jim Re: Colors 13.05 Mary Re: Colors 12.30 Sue Re: Pizza! 13.15 Bob Re: Colors 13.10
这里发生的情况是 Joe 用他的 Pizza! 邮件劫持了 Colors 线程，而且 Bob 和 Sue 都使用了不能正确进行线程处理的邮件客户端。
这会让人抓狂！请确保您避免这两个问题。
更改主题
有时更改线程的主题是合适的，而不是开始一个新的线程。例如，您可能希望深入探讨原始线程的某个子集主题。一种惯例是
From Subject Date Bob Colors 12.02 Jim Red (was Re: Colors) 13.05 Bob Re: Red (was Re: Colors) 13.10 Mary Re: Colors 12.30
网络礼仪
上面的线程部分深入探讨了一个称为“网络礼仪”的主题。例如，劫持线程或以奇怪的方式格式化电子邮件被认为是不良形式（即不良礼仪）。
这是一个很大的主题，但让我们尝试涵盖最重要和最相关的项目。
避免交叉发布
交叉发布是将同一消息同时发布到多个邮件列表的行为。虽然这听起来像是接触更广泛受众的好方法，但它会给回复带来问题，因为并非所有人都能将回复发布回您发布到的每个邮件列表。这导致交叉的线程，根据您试图跟踪讨论的邮件列表，一些回复会丢失。
替代解决方案包括为您的消息选择一个主要的邮件列表，并在其他邮件列表上发布单独的指针指向该讨论，要求感兴趣的人在那里回复线程。或者在每个邮件列表上发布单独的消息，以创建单独的线程。
保持讨论在列表上
在回复讨论或开始新讨论时，您的本能应该是将讨论放在适当的邮件列表上。
避免将讨论脱离列表，确保您回复邮件列表而不是直接回复讨论参与者。
避免脱离列表开始讨论。如果您发现自己抄送了超过 2 或 3 个人，您可能应该改为发送到邮件列表。
在发布到邮件列表时避免抄送额外的地址，因为这可能导致非订阅者之间的讨论分裂以及列表订阅者的重复投递。如果他们想在不订阅的情况下跟踪讨论，请将感兴趣的人推荐到已发布的列表存档。
我们使用邮件列表是因为它为更广泛的受众提供了保持参与或了解情况的机会，它鼓励开放性，并且意味着讨论被存档以供将来参考。
是的，有时在邮件列表上讨论某些事情是不合适的。但这应该是例外，而不是规则。
我们的许多邮件列表避免更改发送给它们的邮件的原始 From 和 Reply-To 标头，但所有列表仍然提供 RFC 2369 List-* 标头，因此强烈建议使用具有 reply-to-list 功能的邮件阅读器。如果您不幸没有使用此类客户端，您可以通过使用 reply-to-all 然后删除任何不相关的地址（确保仍包含邮件列表的发布地址）来解决问题。
招聘信息
与 OpenStack 相关的招聘信息应发布到（免费的）OpenStack 招聘板，而不是邮件列表。
评审请求
请不要直接在邮件列表上发送评审请求，而应使用其他渠道，例如直接电子邮件或 IRC ping，请参阅 Thierry 关于此事的电子邮件
核心评审员已经收到关于他们应该评审的事项的电子邮件，并使用工具来确定他们的评审队列的优先级。如果您想让特定的人评审某些内容，请向他们发送电子邮件或在 IRC 上 ping 他们。如果您想让您的评审优先级提高，在相应的每周团队会议中插话应该效率高出一百倍。但是发送重复自动电子邮件通知的内容是无效的，并且会产生 ML 噪音（这对每个人来说都是一种痛苦）。
特定客户端说明
内核的Documentation/email-clients.txt 非常全面。
gmail
使用“纯文本模式”
- 点击 Gmail 左侧导航栏中的“撰写”（如果启用了键盘快捷键，您也可以按“c”）
- 点击电子邮件撰写弹出窗口中指向下方的“更多选项”三角形
- 确保“纯文本模式”被选中。
- 如果菜单中“纯文本模式”前面没有复选标记，请点击它。（否则，点击电子邮件正文中的任何位置以关闭“更多选项”菜单。）
- 此设置是持久的，因此您撰写的新电子邮件也将处于“纯文本模式”。但是，如果您（针对特定电子邮件）设置回“HTML 模式”（如果您使用某些格式选项，这会自动发生），那也将是持久的。因此，如果您发送了一封一次性的 HTML 邮件，您需要记住在此之后返回“纯文本模式”。
另请注意，gmail 在 78 个字符处换行纯文本消息，但在撰写器中不可见。
Outlook
不要使用它！
或者，试试这个QuoteFix 宏。
Zimbra
看来 Zimbra 电子邮件撰写器根本无法处理这些准则。
您可以通过“回复电子邮件时：包含原始消息”和“使用前缀 >”来接近，但仍然不够好。即使有这些设置，Zimbra 也不允许您使用漂亮的署名行，并且它会对引用的文本进行换行。
老实说，这看起来是徒劳的。对于您的大部分工作，请使用合适的电子邮件客户端，例如 Thunderbird。
Thunderbird
（此指南至少有些过时：它是在 2012 年之前编写的，并链接到一个早已消失的插件，用于解决当时观察到的 format=flowed 问题，这些问题很可能早已修复。）
要将其配置为发送纯文本电子邮件，请转到帐户，撰写和地址，然后取消选中“以 HTML 格式撰写消息”。
您还应该禁用 text/plain; format=flowed，否则您会看到换行问题。转到首选项，高级，配置编辑器并禁用 mailnews.send_plaintext_flowed。更新：此设置在最近版本的 Thunderbird 中似乎默认禁用。最好还是仔细检查一下！
或者您可以安装Asalted Patches 附加组件。“阻止您的补丁被攻击”。
Evolution
要将其配置为发送纯文本电子邮件，请转到首选项，撰写器首选项并取消设置“以 HTML 格式化消息”。此外，将回复样式设置为“引用”。在邮件首选项中，将纯文本模式设置为首选 PLAIN。
Kmail
有传言称它“默认情况下运行良好”。HTML 格式可以全局启用或按收件人启用。可以在“配置 Kmail > 撰写器 > 常规”中自定义换行
pine
这还常见吗？我不知道，但它应该运行良好。
显然，设置“quell-flowed-text”功能是一个好主意。
mutt
如果您正在使用 mutt，您可能已经知道所有这些了。它基本上默认执行了这里推荐的大部分操作，您可能会发现 reply-to-list（默认键绑定中的 L）功能特别有用。
