小型邮件服务器当前最佳实践

(这篇帖子最初是作为邮件邮件列表上的回复写的，但一位朋友让我把它变成博客帖子。我对其进行了编辑，大多数情况下添加了更多指向其他地方的链接，但这里也添加了一些内容。)。

背景：有人在德国一家在处理虐待报告方面享有极高声誉的设施中托管了一台邮件服务器，他在向使用Gmail的朋友发送电子邮件方面寻求帮助；他们有SPF，看不出DKIM的意义；他们使用CACert的证书为他们的邮件服务器设置了TLS。

有一篇来自谷歌2006年的pdf文档至今仍值得一读：布拉德利·泰勒(Bradley Taylor)的https://research.google.com/pubs/archive/45.pdf，，题为“大型网络邮件服务中的发件人声誉”。如今，任何使用邮件服务器的人都需要阅读这份文档。

如果你发送的电子邮件不多，那么谷歌可以评估你的IP声誉的唯一依据就是你的地址块的声誉，因此，身处一个“麻烦”的主机提供商将会对你造成很大的不利影响。在这一点上，如果你不离开，你需要试着用足够的积极因素来平衡负面分数，这样任何使用声誉评分的大型提供商都会接受这封邮件。

对于IPv6，使用正向和反向成对DNS比使用IPv4更重要；不管是好是坏，一些大型提供商已经决定，当人们部署更新得多的标准时，旧标准中针对旧行为的豁免不应该适用。所以你绝对需要一个MX记录，不能只依赖地址记录(A和AAAA)。

在基于IP的声誉不佳的情况下，您需要看看是否可以获得更好的基于域名的声誉。这就是DKIM发挥作用的地方：一旦您可以证明链接的消息确实来自给定域，那么即使您不发送太多邮件，您也可以从诸如“不在过时的域列表上”之类的东西中获益。但是有DKIM和DMARC记录确实有帮助(而且我不是DMARC的粉丝)。

对于邮件服务器的TLS：为了让它对你有利，而不是清洗，我强烈怀疑它需要一份发件人可以验证的证书。对于那些为“更好的TLS”打分的人，那些使用Dane的发送者会对你的CACert主播在DNSSEC中的TLSA记录感到高兴。但大型网络邮件提供商拒绝部署DNSSEC验证，因此推出了替代的MTA-STS。使用MTA-STS，您将被绑定到“任何您关心的大型发件人将信任的Casall子集”，然后将该CA用于MTA-STS Web服务器和您的邮件服务器的证书。请注意，您不需要实现MTA-STS的客户端逻辑(我认为它与开放的联合平台相反)，而只需要为使用它的发送者发布静态信息。在这一点上，CACert不会削减它。您需要尝试一下，让我们改为加密。

来自较大提供商的持续自然趋势是在大多数时间内偏爱支持他们的大多数用户想要的东西。有这么多人使用较大的提供商，他们自然倾向于与较大的发送者一起工作的东西，并且需要更多的环。这些额外的环为较小的提供商和自主者手工操作创造了更多的工作。

围绕这一切，我们需要更好的自动化工具。下面的内容将更清楚地说明原因。

因此，这里是我目前对当前最佳实践的理解，实际上不是IETF理想主义。这包括强制提供一些人坚持认为必须是可选的东西，因为现实地说，发送给一些大型供应商并不是可选的。此列表包含的功能可使您与欧盟(尤其是德国)的持续趋势兼容，强烈反对允许明文SMTP。

这假设您不是一个大的发件人，也应该设置反馈循环，学习如何“温暖”IP，考虑BIMI，邮局主管工具域验证，等等。

反向DNS与匹配的正向DNS；使用的名称不应与任何通用名称模式匹配，理想情况下应包括邮件或MX等的DNS标签。

精确的SPF；避免-所有在最后，因为，除了唯一的例外“此域名从不发送电子邮件”记录，较大的运营商有指标显示，使用-所有往往是过度热情的迹象，而不是现实，所以它会稍微对你不利；

记住，您的HELO主机名要有SPF记录，因为当您发送“退回”拒绝时，这是会重新连接的内容(因为<；>；中没有域名)。

DKIM设置，考虑到选择器名称空间。RSA2048密钥是一种有效的硬要求DNS TXT记录，由一个或多个DNS字符串组成，每个字符串限制为255个ASCII字符。对于这种大小的密钥，您最终需要在zonfile中使用两个DNS字符串。

Ed25519的密钥还没有得到广泛的支持，但是如果你有两个签名，现在不太可能主动破解，让事情变得更糟。这需要是不同的选择器。

请注意，出于各种好的原因，您应该将此设计为您经常旋转的对象。

DMARC记录；请参阅RFC 7489请考虑为报告设置一个接收器，这样当您发送到不重新签名的邮件列表时，您就可以看到DMARC报告在多大程度上侵犯了隐私。：-/。

MTA-STS Web服务器具有来自同一CA的HTTPS证书，并且相应的MTA-STS txt文件已就位；请在DNS记录正常运行时添加该记录。参见RFC 8461。

对于使用开源MTA中广泛支持的东西的独立邮件提供商，您应该查看DNSSEC，因为该模式不太容易受到寻租压力的影响：DNSSEC为您自己的域签名的区域使用CloudFlare当前使用的任何签名算法：这应该既是当前的加密算法，又得到了足够广泛的支持，如果某人的解析器不支持它，那么他们的问题就不仅仅是您的域了。

DNSSEC为您验证解析程序以查找其他人的记录(考虑使用未绑定或结点解析程序)。

您自己的域的Dane记录(DNS中的TLSA记录)请参阅RFC 6698以了解基本规范，而RFC 7218中的一些常见缩写使讨论它变得更容易。

告诉您的邮件服务器遵守Dane的规定，这样，如果DNSSEC验证的DNS中有TLSA记录，那么邮件服务器可以禁用回滚到明文以传递到MX(理想情况下，还可以验证TLS连接是否具有锚定在其中一个TLSA记录中的证书链)。

看看你能不能把你的IP放到一个开放的基于域名系统的允许列表(也叫“白名单”，但有些人正在远离这个术语)，比如https://www.dnswl.org/或Spamhaus的swl。

确保您不是从“ISP住宅地址空间”发送邮件，如果需要将您的邮件通过更好的地址空间中的主机向外发送(并更新SPF等以匹配)，请确保您的邮件不是从“ISP住宅地址空间”发送的。

为了您自己的理智，一定要确保您设置了Fail2ban或类似的设置，扫描您的邮件服务器日志，因为SMTP身份验证在线破解非常普遍。如果他们进入，您的投递能力将受到他们通过您的邮件服务器发起的垃圾邮件活动的负面影响。

用于提交的DNS SRV记录/IMAP/POP3/Sieve，即使仅用«0 0 0.»表示不支持也是如此。

如果您的通信基础包括通过电子邮件使用OpenPGP的用户，那么也可以设置WKD来发布您的域的OpenPGP密钥。我编写https://github.com/PennockTech/openpgpkey-control作为组织的管理框架；另一个/Standalone-Update-WebSite脚本被设计为可以嵌入到现有的站点构建工作流中，而不需要来自存储库的任何其他东西。

GnuPG项目提供了一些工具，可以将WKD布局作为电子邮件集成工作流进行管理，以便人们更新自己的密钥。

如果您的通信基础包括使用S/MIME的人，则在DNSSEC签名的DNS中设置SMIMEA记录。

当您开始指定“必须是TLS安全的”时，值得将CAA记录添加到DNS中，这样广受信任的证书颁发机构将拒绝为您的域颁发证书，除非您列出它们。每个证书颁发机构检查的表明其拥有权限的值都需要作为CA/Browser论坛的BaselineRequirements的一部分列在其CertificationPractice声明中。如果它丢失了，则浏览器不应该信任该CA。

对于域验证CA(如“让加密”)，请考虑将帐户信息添加到这些记录，以便将其与您的特定帐户绑定。有关详细信息，请参阅RFC 8657。

请注意，在撰写本文时，“让加密”只遵守其暂存环境中的帐户限制，而不是其生产设置中的帐户限制；这一点可能会发生变化。

用于某些MUA中的Gravata样式图像的https://wiki.libravatar.org/api/(出于隐私原因进行缓存)；这是固定模式的HTTPS布局和DNS记录。我想几乎没有人使用这个，但我没有使用数字。如果你有爪子使用者，也许吧？

在我的生产区破坏了DNSControl项目的转换器之后，可以在DNSControl项目的回归测试套件的一个示例DNS区域文件中找到上面的许多DNS项目。试图过度简化的DNS托管平台会使上面的一些项目变得困难。

我写这封信是为了回复，所以这是我现在能记住/发现的东西，所以我可能错过了一些重要的或“对我来说太明显”的东西。其他技术是存在的。