Apex Code Development You need to sign in to do that
Don't have an account?
thunksalot Gmail forward to Email-to-Case failing b/c "message violates our email policy"
We use Google Apps for our mail server. I have a support address that forwards to a SF email-to-case address. Recently, we've gotten several strange rejections. When Google reports the delivery failure it says it is getting a 582 error message from SF saying that "This message violates our email policy." Any idea what is going on? The sender's email looks pretty innocuous.
---------- Forwarded message ----------
From: Mail Delivery Subsystem <mailer-daemon@googlemail.com>
Date: Thu, Feb 10, 2011 at 12:05 PM
Subject: Delivery Status Notification (Failure)
To: person@ourdomain.org
Delivery to the following recipient failed permanently:
support@ourdomain.org
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient
domain. We recommend contacting the other email provider for further
information about the cause of this error. The error that the other server
returned was: 582 582 This message violates our email policy. (state 18).
Good questions. It is actually happening with multiple senders - both from inside the org and outside the org. I should have mentioned that I don't have email-to-case restricted to any group of domains or authorized senders and I don't have the advanced security checkbox checked. This email did have an attachment but some of the ones that have gotten rejected don't.
The good news is that I think I have proof now that this problem is occuring before Salesforce. My email admin was throwing these bounces in my lap because the error message reads like the rejection came from the host of the email-to-case address (Salesforce). When I came in this morning, someone had submitted a ticket with a similar 582 bounce error from an email in which Salesforce's email-to-case address was not a recipient at all. So, now I've thrown the issue back in my email admin's lap. ;)
From everything I read last night, I was coming to the conclusion already that even though the error message looks like it is caused by the host of the email-to-case address (SF), it is actually the result of some security filters that our email admin has set up in our mail server's "Content Manager" (I think she uses Postini for mail content security filters like that). Hopefully, we find the problem there and our story can be a guide to others who get this perplexing 582 error message!
All Answers
That is a weird one. Is it just one sender? What is he sending?
Oh did you check the security settings on your Email To Case? Maybe it's coming from a domain that's been disallowed, or the sender's domain does not match his key?
Good questions. It is actually happening with multiple senders - both from inside the org and outside the org. I should have mentioned that I don't have email-to-case restricted to any group of domains or authorized senders and I don't have the advanced security checkbox checked. This email did have an attachment but some of the ones that have gotten rejected don't.
The good news is that I think I have proof now that this problem is occuring before Salesforce. My email admin was throwing these bounces in my lap because the error message reads like the rejection came from the host of the email-to-case address (Salesforce). When I came in this morning, someone had submitted a ticket with a similar 582 bounce error from an email in which Salesforce's email-to-case address was not a recipient at all. So, now I've thrown the issue back in my email admin's lap. ;)
From everything I read last night, I was coming to the conclusion already that even though the error message looks like it is caused by the host of the email-to-case address (SF), it is actually the result of some security filters that our email admin has set up in our mail server's "Content Manager" (I think she uses Postini for mail content security filters like that). Hopefully, we find the problem there and our story can be a guide to others who get this perplexing 582 error message!