# 在电子邮件收件人中致敬“Resent-\*” **URL:** \ **Category:** Feature\ **Tags:** email\ **Created:** [2022年九月26日 20:04 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132 "2022-09-26T20:04:23Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Natureshadow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natureshadow/32/196090_2.png) [@Natureshadow](https://meta.discourse.org/u/Natureshadow)\ **Post date:** [2022年九月26日 20:04 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132/1 "2022-09-26T20:04:23Z")
我们有一个工作流程，其中使用 Discourse 作为电子邮件存档。我们有一个群组邮件地址，我们的座席在与客户开始电子邮件线程时会抄送该地址。 这在客户专门回复座席（忽略所有抄送甚至回复到标头）时效果很好。然后，座席应该将电子邮件退回（重新发送）到群组邮件地址。退回是这里的首选方法，因此 Discourse 会存档原始电子邮件，包括所有原始标头、时间戳等。 通过复制确切的消息并添加 `Resent-From` 和 `Resent-To` 标头来退回电子邮件。这些不幸被 `Email::Receiver` 忽略。它应该简单地将所有 `Resent-*` 追加到相应的常规字段。 我开始实施，并且已经达到了让 `create_incoming_email` 考虑字段的程度。然后，我可以在 Discourse 的传入电子邮件列表中看到邮件，包括来自 `Resent-To` 的收件人。 但是，我没有成功的是让 `get_all_recipients` 也遵守 `Resent-*` 字段。我将 `resent-to resent-cc resent-bb` 添加到邮件字段的 `%i()` 数组中，但它似乎仍然没有返回这些字段中的收件人。 欢迎任何帮助，以便我可以为此更改提交 PR！ ---
**Author:** ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)\ **Post date:** [2022年九月27日 03:09 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132/2 "2022-09-27T03:09:53Z")
这似乎是一项相当危险且容易被冒充的功能。您建议如何对重发器进行身份验证？ * * * 另外，Discourse 已经具备了处理转发邮件的现有机制。 ---
**Author:** ![Natureshadow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natureshadow/32/196090_2.png) [@Natureshadow](https://meta.discourse.org/u/Natureshadow)\ **Post date:** [2022年九月27日 06:31 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132/3 "2022-09-27T06:31:24Z")
“\> 这似乎是一项相当危险且容易被冒充的功能。您建议如何对重发者进行身份验证？ 使用 `Resent-From` 标头。但这实际上并不重要；有趣的部分是原始发件人是否可以被身份验证，而不是重发者。 > 另外，Discourse 已经对转发的电子邮件进行了现有处理。 仅适用于引用的转发。这有几个问题： - 它不存档原始邮件，只存档其正文的引用副本 - 不支持将消息作为附件转发（带有完整标头） - 它是残缺的（它依赖于主题中的一个特殊前缀来识别转发的邮件）” ---
**Author:** ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)\ **Post date:** [2022年十月4日 04:22 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132/4 "2022-10-04T04:22:41Z")
> [@Natureshadow](#): > > 使用 `Resent-From` 标头。但这实际上并不重要；有趣的部分是原始发件人是否可以被验证，而不是转发者。 那这到底是怎么发生的呢？如果转发者撒谎，完全伪造一封据称只发送给他们的电子邮件，那该怎么办？ ---
**Author:** ![Natureshadow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natureshadow/32/196090_2.png) [@Natureshadow](https://meta.discourse.org/u/Natureshadow)\ **Post date:** [2022年十月4日 06:05 UTC](https://meta.discourse.org/t/honouring-resent-in-email-receiver/240132/5 "2022-10-04T06:05:47Z")
“\>那具体是怎么发生的呢？如果重发者撒谎，完全捏造一封据称只发给他们的邮件怎么办？ 那样的话，他们可以直接省略所有的 `Resent-` 字段，直接伪造邮件，而不是声称邮件是先发给他们的。 我认为你对 `Resent-` 头部的作用存在误解——实际上它们_什么作用都没有_。邮件服务器在检查 SPF 或 DKIM 时也不会考虑它们，所以伪造一封重发邮件和伪造原始邮件一样困难。 在我的例子中，来自外部陌生人的重发邮件会因为 SPF 违规而被垃圾邮件过滤器阻止。我的代理重发邮件到 Discourse 的场景之所以可行，是因为在他们通过身份验证连接到我们的邮件服务器后，可以豁免这些检查。 因此，允许 Discourse 使用 `Resent-To` 头部仅仅是一个便利功能，因为常规邮件客户端就是这样创建他们之前收到的邮件的伪造副本的。这不会改变任何关于身份验证的事情。”