对于转发邮件服务器，SRS重写是否绝对必要？

我正在为我的域运行一个Postfix电子邮件服务器，例如mydomain.com。它主要充当转发电子邮件服务器：用户会收到一个电子邮件地址@ mydomain.com，但通常会选择将其地址转发到外部收件箱（Gmail，Yahoo等）。有数千个地址被转发，因此服务器处理相当大量的邮件流量。

过去，服务器不使用SRS重写。当然，这意味着转发的邮件将无法通过SPF检查，因为我的IP地址在技术上没有被授权代表原始发件人的域发送电子邮件。但是，据我看来，这似乎没有引起任何重大问题。通常，没有用户抱怨，例如Gmail，Yahoo等似乎足够聪明，可以忽略SPF故障并以任何方式传递邮件。

考虑到这一点，是否真的有必要启用SRS重写？我正在考虑启用它，但我主要担心的是，当垃圾邮件不可避免地被转发时，我的域将因为发送垃圾邮件而被列入黑名单。重写是否会使它看起来像我是垃圾邮件的发起者？（至少，这是我通过阅读Gmail的转发邮件服务器的最佳做法获得的理解）。

当然，我已经采取了一些建议的预防措施，例如使用SpamAssassin在转发前将“ SPAM”添加到可疑垃圾邮件的主题行中，而不是转发高置信度（15分以上）的垃圾邮件，以及使用spamhaus阻止列表，但是这些措施不是不够完美，垃圾邮件仍然可以毫无痕迹地溜走。

如果SRS重写增加了被错误标记为垃圾邮件发送者的风险，是否值得？还是仅保留它并忽略SPF故障会更安全吗？

postfix spam spamassassin

— tlng05
source

我从经验中知道，英国的某些ISP会拒绝声称来自其客户的入站电子邮件，但这些电子邮件并非来自其自己的邮件发送者。Gmail，Yahoo和AOL可能也是如此。这种情况只能通过重写发件人地址来解决。

— roaima

Answers:

在我看来，您的问题归结为“ 那里有多少个邮件服务器检查传入电子邮件上的SPF记录？ ”。如果是大多数，则SRS是转发服务器的绝对要求。如果它们都不是，那么您就不需要SRS。

不幸的是，我无法立即投入任何与此相关的学术工作。但是由于我检查了传入电子邮件的SPF，因此可以肯定地说某些邮件服务器会对其进行检查。-all除非您使用SRS，否则任何将您的服务器转发到我的服务器上的帐户的客户都将丢失从发送以SPF结尾的广告发件人发送的电子邮件（按他们的应有的话）。因此，我可以肯定地说，如果没有SRS，您的某些客户的电子邮件将不会发送。

我向Marc致歉，因为我不会读德语，所以我不能说他引用的PDF是否提出了令人信服的论点，但我可以重申，如果没有SRS，您的客户电子邮件中有一部分将无法发送。我不能说这个分数是多少，但它不是零-鉴于这个，我认为除了运行SRS之外，您别无选择。

我同意您的服务器不会通过转发SPAM来帮助自己，但是以我的经验，大多数声誉损失都是由其IP地址而不是信封发件人域造成的；无论使用SRS，都将完成此操作。

对于您的问题，更深层的回答是，在SPF及其（经过深思熟虑和破坏互联网的后续行动）DMARC之间，在我看来，邮件转发服务已经有了发展。我已经要求除一个用户外的所有用户都必须在服务器上进行最终交付，并且一个用户将必须在2016年更改或离开。如今，许多Webmail系统将允许通过使用以下方法收集服务器外邮件来集成多个邮箱IMAP或POP，许多邮件客户端允许多个IMAP或POP帐户显示为单个集成的INBOX，因此转发不再像以前那样集中于集中阅读。

简而言之，我想说您短期内需要SRS，长期而言需要新的业务模型。

— 疯了
source

事实是，SRS是解决SPF转发问题的解决方案。SRS将例如user @ A重写为A = user @ B，然后负责B的SPF记录。问题：B仍然可以伪造地址！因此，有些人将crypt哈希和时间戳添加到重写的地址。为了使它能够大规模运行，需要全球范围内的采用，而这还不存在。它也仅在转发了一次但不转发任何东西时才起作用。答案也是个问题。还请记住，SPF是一种保护您自己的滥用范围的技术，仅此而已。

— 马克·斯蒂默（MarcStürmer）

@MarcStürmer“ SRS是解决SPF转发问题的解决方案 ”：是的，这就是事实。众所周知，SPF打破了简单转发。如果您认为SRS不值得付出，就不要宣传SPF记录。“ 问题：B仍然可以伪造地址 ”：不能访问A的域或受适当SPF记录保护的任何其他域，否则邮件将被SPF拒绝；但是除此之外，是的，它可以，而且我认为这不是问题。“ SPF是一种保护您自己的滥用范围的技术，仅此而已 ”：我同意。

— MadHatter

@MarcStürmer：“它也仅在转发了一次内容的情况下有效，但不能转发更多。” 是错的。SRS在多个转发服务器上完全可以正常工作。仅当该行中有一个非标记服务器时，它才会受到影响。但这是与任何非标记服务器通常相同的问题，无论是前向还是后向。在SPF的世界中，您不需要SRS，只需要承担转发邮件的责任，并确保可以传递回弹邮件。SRS只是做到这一点的一种技术，例如Google使用了不同的东西。

— Adrian Zaugg

问题是，使用SRS会破坏DMARC对齐检查（即信封发件人！= From:-header），并且如果From:标头中的域包含p=reject在其DMARC策略中，则会使Gmail拒绝邮件。如果您也重写From:，则会根据您自己域的规则检查邮件。但是DKIM检查将失败，邮件客户端中显示的发件人将被破坏。

— mbirth '17

@mbirth afaik，你是对的。但是我个人认为DMARC完全是一场灾难，不仅因为它单方面破坏了邮件列表，而且（以我作为大型社区列表的管理员身份）只是建议人们不要使用任何发布p=reject策略的ISP 。如果SRS破坏了DMARC，那么对DMARC来说就很难。

— MadHatter

SRS在纸上似乎是一个不错的主意，但根据Heinlein支持人员的说法，实际上在实践中效果不佳（他们正在运行具有100000个帐户的中型邮件服务。）

他们的发言中有详细信息，尽管使用德语，但原因：https : //www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

主要原因是，SRS对于实际实现SPF的严重问题来说是一个小补丁，因为SPF不能很好地涵盖电子邮件的一些常见用例。为了使SRS有意义，尽管它需要部署在大型服务器上，这不太可能发生。因此，直到将其部署在庞大的服务器基础上，它才变得毫无意义。

大型邮件提供商的问题在于，如今它们确实拥有庞大的用户群，并且正在实施越来越多的技术（DMARC的后继产品已经在开发中），这对于普通邮件提供商而言越来越困难了。邮件服务器设置，以一种可靠的方式向他们发送邮件。

如果您希望更好地将邮件传递给Gmail，Hotmail等大型邮件提供商，则应至少实施DKIM和DMARC，但最好将其设置为软失败，并在邮件传递上实施某些限速机制将为您创造奇迹。

大型提供商的问题是为什么现在存在诸如Mailchimp，Mandrill或Returnpath之类的服务的原因。这些提供商确实向Google＆Co付款。以获得更好的交付质量。

— 马克·斯蒂默（MarcStürmer）
source

这里的问题是SPF而不是SRS。只要某些ISP确实使用SPF，您就需要实现SRS（或类似的东西）以使转发与所有它们一起使用。灰名单的问题有所不同，您应该“解压缩” SRS标记的发件人地址以进行灰名单（以及BATV标记的邮件）。

— Adrian Zaugg

我同意@MadHatter的每个词，但关于Google的重要事实！

如果您为gmail提供转发服务，那么您很有可能也提供SMTP访问，因此您的gmail用户可以代表您存储的地址从gmail发送邮件。

在这种情况下-gmail知道您是此电子邮件的转发者，即使SPF检查失败也不会将您的转发标记为垃圾邮件。

您可以从bill@microsoft.com向客户发送邮件。该消息将直接进入其收件箱，而不会发出任何警告！（Microsoft 在spf记录中确实有 -all）

检查并验证。附带示例。

此消息已转到收件箱。

— 耶
source