假设您正在设计一个带有规则支持(如条件转发等)的高级电子邮件服务器。古老的电子邮件循环问题摆在了您的面前:
1)假设您设置了一个规则,将所有邮件转发到另一个地址。如果该地址不存在,并且该域的管理员向您发送消息告诉您这一点。当然,您的规则不会区分这些消息并将它们转发,从而创建一个循环。
2)另一种情况是两个用户使用此客户端设置彼此的地址的转发规则。我们只需要一个启动器消息,它们就会进入循环。
3)或者,考虑一种自动回复情况,其中客户端转发到一个自动回复的地址,从而引发另一个循环。
我不是这方面的专家,但似乎检测循环不起作用。我们可以想出一些启发式方法,但似乎不存在通用算法。
我一直在考虑的一个解决方案根本不涉及检测。相反,我们只需观察高邮件发送活动(或由规则引起的高发送活动)的帐户,并暂时禁用这些帐户的电子邮件/规则,直到他们纠正问题。但是,此解决方案必须在引起循环的帐户和仅接收大量邮件并将其转发到其他位置的帐户之间保持平衡。
我们还可以对所有帐户应用节流,并确保如果循环开始,它们不会占用大量带宽。但这无法阻止循环运行,直到邮箱填满为止。
我是否遗漏了任何好的解决方案?
1)假设您设置了一个规则,将所有邮件转发到另一个地址。如果该地址不存在,并且该域的管理员向您发送消息告诉您这一点。当然,您的规则不会区分这些消息并将它们转发,从而创建一个循环。
2)另一种情况是两个用户使用此客户端设置彼此的地址的转发规则。我们只需要一个启动器消息,它们就会进入循环。
3)或者,考虑一种自动回复情况,其中客户端转发到一个自动回复的地址,从而引发另一个循环。
我不是这方面的专家,但似乎检测循环不起作用。我们可以想出一些启发式方法,但似乎不存在通用算法。
我一直在考虑的一个解决方案根本不涉及检测。相反,我们只需观察高邮件发送活动(或由规则引起的高发送活动)的帐户,并暂时禁用这些帐户的电子邮件/规则,直到他们纠正问题。但是,此解决方案必须在引起循环的帐户和仅接收大量邮件并将其转发到其他位置的帐户之间保持平衡。
我们还可以对所有帐户应用节流,并确保如果循环开始,它们不会占用大量带宽。但这无法阻止循环运行,直到邮箱填满为止。
我是否遗漏了任何好的解决方案?
Delivered-To
和X-Loop
是比较流行的选项之一。 - undefined