实际上，DMARC与邮件列表合作（2018）

在网上有一个常见的信念，DMARC是一种防守网络钓鱼技术，防止了电子邮件列表的适当运行。要绕过感知的问题，许多文章以打破SMTP规范的方式建议重新配置ListServ软件。

然而，存在一种配置，允许邮件列表完全工作，并且仍然能够在DMARC的存在下中继消息。在描述之前，让我们直接得到一些术语。

（A.K.A.返回路径。）SMTP消息的“信封”中的记录，称在交付失败时要联系。在到达目的地之前，电子邮件可以在多个跳中传输到服务器，从服务器转发到服务器。在运输过程中，RFC5321.MailFrom报头包含发送沿当前跃点的消息的服务器的电子邮件地址。

消息本身内部的标题，希望跨越啤酒花。这是电子邮件客户端显示的“来自”字段，它应该是负责电子邮件的人的电子邮件地址。

一个不太常见的电子邮件标题，它表示代表其他人写入或发送消息的中介。 RFC 5322给出了秘书（发件人）的例子，他代表BOSS（来自）发出并发送消息。

发件人策略框架。一个TXT DNS记录，它发布允许为（子）域发送或中继消息的邮件服务器的地址。接收邮件服务器可以检查RFC5321.Mailfrom并反弹消息如果它与SPF记录中列出的服务器不匹配。

DomainKeys已识别邮件。 DKIM是TXT DNS记录，每个记录都包含允许加上密钥的公钥签署正文，以及应在签名中涵盖哪些电子邮件标题的列表。发送服务器必须知道私钥才能登录邮件，并且接收邮件服务器可以检查对公钥的电子邮件以确保它通过。这可确保只有授权服务器可以为域发起邮件，并且还原中继服务器无法修改消息。

基于域的消息身份验证，报告和一致性。一个TXT DNS记录，它发布了域的策略，了解接收邮件服务器应该如何对SPF或DKIM失败作用。操作包括忽略问题，将消息发送到垃圾邮件文件夹，或者彻底弹跳消息。 DMARC Record包含其他一些设置，例如邮件服务器的电子邮件地址，以报告他们收到的任何不合格邮件。

托管一个名为反射器的特殊地址的继电器邮件服务器。邮件列表将发送到其反射器发送到列表订阅者的地址的任何消息。邮件列表用于组讨论，包括协作软件开发。

虽然PGP等早期方法已经存在于揭示邮件伪造，但DMARC已成为最受欢迎的选择，并在所有主要邮件服务器上获得荣誉。但是，域名雇用DMARC的人无法通过传统配置的邮件列表发送消息。在DMARC在Gmail和雅虎等主要领域采用期间，邮件列表开始具有广泛的问题。

有些人称为DMARC的破碎标准。他们未能为邮寄列表行为实施优雅的调整，并使用贺卡变通方法来解决问题。

让我们来看看消息如何通过或失败DMARC，然后了解如何修复列表。如果SPF或DKIM通过，则传递消息，并且仅在SPF和DKIM失败时才会失败。这样，仅限SPF和DKIM的消息都可以通过DMARC，但没有SPF / DKIM的消息将始终失败。

对于DKIM，这意味着该消息具有一个有效的DKIM签名，“d = rfc5322.from”。

邮件列表将为使用DMARC和SPF但不是DKIM的任何域都有一个艰难的时间中继消息。考虑此消息：

但是，如果mailinglist.org不在dmarcomain.com的SPF记录中，则Destination.com将拒绝此消息。此外，良好的SPF记录是不够的，因为返回路径和来自对齐（它们指定不同的域）。

处理这种情况是导致贺卡变通方法的原因。列表必须使用从营地或MIME消息包装等技术来获取邮件。

返回路径：＆lt; [email protected]& gt;来自：＆＃34;莎莉发件人通过有趣的列表＆＃34; ＆lt; [email protected]& gt;回复 - 至：＆＃34;莎莉发件人＆＃34; ＆lt; [email protected]& gt; to：＆＃34; roger读者＆＃34; ＆lt; reader @ destination.com& gt;主题：每个人都有hihi

收件人只需检查将通过的MailingList.org的DMARC。然而，这是电子邮件的使用差，因为它是歪曲谁发起了消息。此外，电子邮件客户端通常具有与回复标头的劣化接口。它通常在消息列表中不可见，不用于排序，而不是添加到地址簿中。

如果发送域使用DKIM，它会避免从营地或其他黑客攻击。它在列表不修改消息的情况下工作。

正如我们之前看到的那样，SPF将失败，因此DMARC将尝试DKIM检查。没有修改，受试者和身体，所以它们将被正确签署。 DKIM检查RFC5322之间的对齐。来自和签名的域，也将匹配。 DKIM通过，消息交付。

应该是完美的，对吗？嗯，除了列表中，除了传统上添加了中继消息的主题和主体中的额外信息，并且修改的字段不会通过DKIM检查。来自传统邮件列表的消息通常如此如此：

返回路径：＆lt; [email protected]& gt;来自：＆＃34;莎莉发件人＆＃34; ＆lt; [email protected]& gt;发件人：＆＃34;有趣的名单＆＃34; ＆lt; [email protected]& gt; to：＆＃34;罗杰读者＆＃34; ＆lt; reader @ destination.com& gt;主题：[有趣] Hihi Everys - 您订阅了Fun列表，到Unsubscribevisit https://mailinglist.org/unsub/123

主题行标记通常用于将消息对在电子邮件客户端中的用户定义规则之后的单独邮箱中。身体中的取消订阅链接是便利（并避免政府罚款违反CAN-SPAM法案。）

我们需要为客户提供一种方法来排序邮件，取消订阅等，而无需修改DKIM签名的消息的部分。幸运的是，有rfcs。 RFC2369于1998年和RFC2919从2001年开始，两者都是预测DMARC机械。首先介绍列表信息和控件的标题字段。

对于我们的示例，RFC2369允许我们添加列表 - 取消订阅：＆lt; https：//mailinglist.org/unsub/123>它还介绍了List-help，list-subscribe，list-post，list-owner和list-arprive的标题。更重要的是，许多邮件客户理解这些标题。在检测到列表 - 取消订阅时，Gmail将取消订阅按钮添加到Web界面。

第二个RFC提供了一种方法来识别包含另一个标题的列表，如列表ID：有趣列表＆lt; fun.mailinglist.org＆gt ;.邮件客户端规则可以查询此标题，而不是检查主题字段是否包含[有趣]。

现在是合理的，要求域使用DMARC的邮件列表用户也启用DKIM。事实上，列表软件可以在订阅时间检查发件人的域，如果域域使用DMARC，则会引发错误，但不是DKIM。

列表应保持来自地址，主题和消息完全不变。它们应该添加一个发件人标题来指示其继电器角色，并至少设置邮箱规则和订阅管理的列表ID和列表 - 取消订单。

此配置将允许邮件列表在DMARC时代的函数中作为正确的SMTP公民。