Better support for Auto-Submitted: auto-replied

Related to discussions like this:

Auto-response email replies to Digests are processed as new topic:

I just found 244,276 emails in the POP inbox which one of my non-hosted forum watches.

but the one I smelled as the best clue for discourse not to reply on is:

Auto-Submitted: auto-replied

The emails sent log is full of

postmaster@exchange.microsoft.com	email_reject_auto_generated  
discuss@domain.com			email_reject_auto_generated

How can we prevent the loop?

1 Like

Upgrading to latest (we were less than a week behind when it started) didn’t help

Apparently this has been going on for quite some time… the other email we see hundreds of is from discourse, to discourse,

We’re sorry, but your email message to [“discuss@forum.com”] (titled [Discussions] Email issue – Auto Generated Reply) didn’t work.
Your email was marked as “auto generated”, which we can’t accept. If you believe this is in error, contact a staff member.

Not sure what type of mail server you’re running, but can you set up some type of automation to delete auto-submitted bounces, etc., from the incoming POP3 inbox?

Ok, so postmortem almost complete:

the email address in Contact Email was set to be the same as the notification email and was also the forum’s primary email address.

If discourse wanted to check & warn admins this is a bad choice, this issue might have been avoided :wink:

PS We do not yet know why the microsoft server was involved in this loop.

That check is already in place.

uh, no, those emails should be silently dropped @techAPJ

1 Like

The check is in place now, but was not 4+ months ago, so it will not catch old sites that had a loop set up in their emails.

1 Like

We ran into this as well. The cause of the infinite loop is because we are sending an “Auto Generated Reply” back to email addresses that we detect as “no-reply” or “auto-generated”. If pop3_polling_username is similar to notification_email, the email that bounced will be polled for and we end up starting another cycle.

It does seem really weird to me that we reply to email addresses that we detect as “no-reply” so I opened a PR to stop doing that.

https://github.com/discourse/discourse/pull/4148

4 Likes

I worry though that we lose out on some of the feedback we have now, I wonder if we should allow the first one of these through and then stop the loop thereafter?

Poison the “reply” with a magic header, if you ever see this header you silently reject?

4 Likes

Yeah Sam has the right idea here we cannot lose this feedback. Put in a guid (a constant will work) and if you see it in the reply coming back to you, cancel your reply.

I added two additional checks:

  1. If there is a delivery status report in the email, we can detect if the rejection email bounced and not send a rejection email
  2. Add a custom header in the rejection email and we’ll look for that header when processing emails.

https://github.com/discourse/discourse/pull/4148

5 Likes