There seem to be a lot of weird cases where email should NOT actually be rejected, but is rejected anyway. Which means that sometimes, users send support emails that we never see.
For instance, email sent to our support address from mac.com addresses is often rejected for having no body (Email::Receiver::NoBodyDetectedError). Those emails often do in fact have body text, so there might be a parsing issue.
But aside from fixing whatever is causing the errant rejections, I’d be happy if we could just get alerted when there are new rejections, so we could look at them and see if the rejection was appropriate.
That could take the form of an option to send alerts to staff on all rejections, or an option to simply CC all rejection emails to staff.
Otherwise, if we don’t want to miss any incoming support email, we have to continually poll the Rejected email list in the Discourse back end. This is tedious and unnecessary.
I think it’s better to focus on the specific example. You said “often” rejected, do you notice any patterns here in the email content? If it was a constant problem I would expect all mail from mac.com to fail.
Well… ‘often’ as in ‘often enough to be kind of annoying’. Our main concern is that we don’t want people getting angry about a perceived lack of response from our support team.
I have looked for patterns in the instances I’ve noticed. Originally I thought there might be a problem with the way mac.com was handling email, but I’ve since determined that we have about 30 users with mac.com addresses that don’t show any problems.
I also thought that if mac.com had a webmail client, it might be handling HTML email in a non-standard way. But I’m not even sure there is a mac.com webmail client.
I thought I had it figured out when I realized that the most recent incident involved email that contained only quoted lines in its body, but subsequent testing showed that Discourse parses such emails just fine.
I’ll review the logs to see just how often this kind of thing has happened, and of course look for patterns. I was just thinking that as long as the possibility exists that Discourse occasionally makes mistakes like this, an alert email seems a simple enough safeguard.
Thanks for the clarification. So basically anything going wrong with email from mac.com addresses should affect me.com and other iCloud addresses as well.
There’s no real pattern. There are 21 instances where the reason for rejection is not quite clear, or seems wrong.
1 x “Email can not be processed: Body is too similar to what you recently posted”
8 x “Email can not be processed: Email::Receiver::BadDestinationAddress” - these are somewhat mysterious; why are the addresses bad?
3 x “Email can not be processed: Email::Receiver::NoBodyDetectedError” - two seem to have body text that looks normal; one just says ‘no body’
1 x “Email can not be processed: Email::Receiver::TooShortPost”
6 x “Email can not be processed”
1 x “Email can not be processed: Sorry, new users can only put one image in a post.”
1 x “Uncaught Error: Syntax error, unrecognized expression: #xxxxxx-email:product at company dot com”
Several of those involved legitimate attempts at communication by customers. Whether the rejection email sent by Discourse went to the sender’s junk folder or was simply ignored remains unclear.
They sent to an address that you are not handling like suppport
To me, only the no body where you say there is one looks like something that might be a bug. A possibility is that it has to do with them using some old and broken mail client.
I checked a few of these (Email::Receiver::BadDestinationAddress), and many of them appear to be legitimate replies from customers, with the recipient being in this form: replies+longidentifier@discourse.site.com. The alert email Discourse sends to the sender suggests that their email was sent from an address other than the one associated with the referenced topic, which is probably the explanation, but in a case like this I would still like staff to be alerted.
It does look like a bug, but while I’d like to see that fixed, I feel that there will always be cases like this, so that in addition to chasing down possible email parsing bugs, an alert email to staff would allow us to provide timely support in the meantime.
That’s what I was thinking. Next time I see this, I’ll ask the customer which mail client they are using.
The point I’m trying to make is that when emails get rejected, it’s sometimes just people trying to get support, not anything malicious.
Sure, some of the time, the emails Discourse rejects really need to be rejected, but we don’t want to risk missing any support email, so we’re stuck with polling the Rejected list.
Meanwhile, confused senders are forced to find other means to reach us, such as the contact form on our web site.
For larger sites, email rejection alerts might be too numerous to handle, but for us, it would be a lot easier to handle those than deal with angry customers.
Also, while Discourse does send rejection email to the sender with potentially useful information, I think those emails end up in spam folders sometimes, further confusing affected customers.
If a user is responding from a different address than the one to which the email was sent, this is expected.
If we allowed replies to these emails from another email address, we open accounts up to being abused via email with others pretending to be another user. We run into this issue sometimes in our own support messages here on meta.
If contact email forms are in use, they usually send from an email and set the Reply-To header, which means we’re hitting the same problem as stated above.
I’m not sure of a great solution here personally – maybe someone else on the team has a thought.
Yes, as I said, it makes sense to reject these. But I would still like to be alerted when this happens.
I only mentioned contact forms because when customers are unable to reach us via the support email address (which Discourse processes), they are forced to look for alternatives, which is not ideal.
Neither do I, which is why I posted this as a feature request.
Yes, understood. But going to that page and pressing refresh every few minutes seems rather inefficient.
A plugin would be fine, but I’m not sure why this feature coudn’t just be added to Discourse. To me, it seems like a no-brainer. Discourse already sends various alerts to site admins and staff. Make the setting (alert on email rejection) default to disabled, which I guess would work for many sites.
Another example: a customer sent email to the support address, to report a problem they are experiencing with their purchase. Discourse rejected their email: [Email::Receiver::InactiveUserError].
I understand that it makes perfect sense for Discourse to reject email from inactive users, but if our support staff was alerted at the same time, they could immediately reach out to the customer, explaining what happened and what can be done about it.
Instead, unless we poll the Rejected list frequently, the customer is now faced with two problems, both of which are the result of automated systems, and of which our support staff would remain unaware. Human intervention at this stage is important, but there can be delays in response time, because again, we’re relying on manually checking the Rejected list.
Is there some technical reason why admins can’t be alerted of email rejections?
