Honouring Resent-* in email receiver

We have a workflow where we use Discourse as an e-mail archive. We have a group mail address, and our agents Cc that address when starting a mail thread with a customer.

This works great until a customer replies to the agent specifically, ignoring all Cc and even Reply-To headers. The agent then should bounce the e-mail (resend) to the group e-mail address. Bouncing is the preferred method here, so Discourse archives the original e-mail including all original headers, timestamps, etc.

Bouncing an e-mail is done by copying the exact message, and adding the Resent-From and Resent-To headers. These are unfortunately ignored by Email::Receiver. It should simply append all Resent-* to the respective regular fields.

I started to implement that, and got as far as making create_incoming_email take the fields into account. I could then see the mails, including recipients taken from Resent-To, in the list of incoming e-mails in Discourse.

However, what I don’t succeed in is also getting get_all_recipients to honour the Resent-* fields. I added resent-to resent-cc resent-bb to the %i() array of mail fields, but it still doens’t seem to return the recipients from these fields.

Any help is welcome, so I can make a PR for this change!

This seems like fairly dangerous and impersonation-prone functionality. How do you propose the resender be authenticated?


Also, Discourse has existing processing for forwarded emails already.

This seems like fairly dangerous and impersonation-prone functionality. How do you propose the resender be authenticated?

With the Resent-From header. But that actually doesn’t matter; the interesting part is whether the original sender can be authenticated, not the resender.

Also, Discourse has existing processing for forwarded emails already.

Only for quoted forwards. This has several issues:

  • It does not archive the original mail, only a quoted copy of its body
  • There is no support for messages forwarded as attachment (with full headers)
  • It is incomplete (it relies on one special prefix in the Subject to recognize a forwarded mail)

And how exactly does that happen? What if the resender just lies and completely fabricates an email that was supposedly sent only to them?

And how exactly does that happen? What if the resender just lies and completely fabricates an email that was supposedly sent only to them?

Then they could just as well leave out all the Resent- stuff and just spoof the thing in the first place, without claiming it was first sent to them.

I think you have a wrong imagination of what the Resent- headers do - which in fact ist exactly nothing. They are not taken into account when mail servers check SPF or DKIM either, so spoofing a resent mail is just as hard as spoofing the original mail.

In my case, a resent mail from a stranger outside would be blocked by the spam filter for SPF violation. The reason my scenario with agents resending mail to Discourse works is that they are exempt from those checks after authenticating to our mail server.

Allowing Discourse to use the Resent-To header is thus nothing more than a convenience feature, because it is how regular mail clients create a spoofed copy of a mail they received earlier. It does not change anything about authentication.

1 Like