Bounce emails create new conversations

[marksteward]

We just had an issue where the email provider for one of our users refused delivery of a spam message. The server replied with a DSN, which Freescout correctly identified as a bounce. However, Freescout also created a new conversation for this bounce, and then sent out notification emails to everyone on that mailbox, including the original user, containing the original message. This led to a loop where we ended up with an email subject like [#7254] Undeliverable: [#7253] Undeliverable: [#7252] Undeliverable: [#7251] Undeliverable: [#7250] ... [#7224] Undeliverable: Field yes spend letter writer sport left. clop-4.

It feels like Freescout shouldn't do this, but I can't see anything in the code to prevent it. Is the answer really to set up something with the Workflows module as suggested here? If so, is there a pattern we can copy?

Alternatively, would you accept a PR to refuse to create a new conversation for a bounce message, or is there a risk of the detection being too broad? Or would it be worth detecting frequent bounces from a user and temporarily refusing to send more emails to them, as Mailman does? That would help in situations like this.

We're using https://github.com/tiredofit/docker-freescout, with only official modules.

[freescout-help]

All incoming emails (including bounce emails) should be turned into conversations. Just like any other email client does not hide emails from you behind the scenes.

FreeScout does not send auto-replies to auto-responders: https://github.com/freescout-help-desk/freescout/blob/dist/app/Console/Commands/FetchEmails.php#L576

Can you share bounce emails' headers.

[marksteward]

That seems doomed to result in email loops. Perhaps it should be possible to at least prevent email notifications for a conversation created in such a way?

I don't know if I can share the full headers, but they included Content-Type: multipart/report; report-type=delivery-status;. They also included valid In-Reply-To and References headers (referencing the notify ID and latest conversation), and Auto-Submitted: auto-replied.

Are you trying to find some other heuristic Freescout could use? There are lots of reasons a mail server might generate a bounce, e.g. if someone's inbox is full.

[freescout-help]

Here is what you are talking about:

1. Support agent sends a message to the customer.
2. Mail server sends a bounce email to FreeScout and the new conversation is created.
3. Support agents are being notified of the new conversation and email notifications are being sent to support agents.
4. Mail server sends bounce messages to FreeScout for email notifications sent to support agents.

If someone have some ideas - feel free to submit a pull request.

[marksteward]

OK, so I'll take that as "PR welcome".

I think you've confused things with steps 1 and 2. There's no need for an agent to send a message, this will happen in response to a request from a customer, or a spam message as originally described. It's really:

1. Something causes an email notification from FreeScout (e.g. customer message, spam email, delivery failure)
2. Email notification is fanned out to support agents
3. Agent's mail server sends bounce message to FreeScout for one of the email notifications. Maybe the agent's inbox is full, maybe the encoding is unsupported, maybe the email triggers a spam rejection
4. FreeScout creates a new conversation for the bounce message, which triggers email notifications, go to step 2

My real worry is that this triggers a spam rejection from a provider like Google, which will result in dozens of new conversations for each original incoming email, and will take out our mail server as well as ruining our sending reputation. So I will create a PR.