Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain michiganspineandpain.com by michiganspineandpain.com.inbound10.mxlogic.net. [22.214.171.124].
The error that the other server returned was:
554 Denied [59bff925.0.2285250.00-1450.3684210.p01c12m011.mxlogic.net] (Mode: normal)
----- Original message -----
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
X-Received: by 10.50.66.180 with SMTP id g20mr4049681igt.29.1386216341232;
Wed, 04 Dec 2013 20:05:41 -0800 (PST)
Received: by 10.43.58.140 with HTTP; Wed, 4 Dec 2013 20:05:40 -0800 (PST)
Date: Thu, 5 Dec 2013 09:35:40 +0530
Subject: Fwd: Information
From: Suraj Kumar <email@example.com>
Content-Type: multipart/mixed; boundary=047d7bdc14e89ac0f104ecc1a436
When sending an email to a McAfee SaaS Email Protection client, the sender is receiving the bounce back message “554 Denied.”
Cause - The error message “554 Denied” means that we have rejected the message as spam. This is either due to the content of the message or the reputation of the sending IP address.
I don't know if Google is a common factor here. But I too am suffering from 554 messages.
In my case the domain protected by SaaS is not one which is used for day-to-day email (we maintain it so that we can assist customers with SaaS using our own account) so I am basically automatically forwarding a copy of each message I receive in my primary mailbox to an e-mail address in my SaaS. My primary e-mail domain is hosted by Google Apps. I find a number of messages (the Google Groups Spam digest message being one, and log/alert messages from a Firewall appliance) are rejected by SaaS and I end up with receiving a 554 failure in my Google mailbox.
I tried submitting examples to firstname.lastname@example.org, but these were rejected stating that there was information contained within which SaaS clearly considered to be Spam.
You could try editing your inbound policy and adding either the sender e-mail address or server IP address to the white list and this should then force SaaS to accept these messages.
So far, in my own experience this doesn't always appear to be the case and I am still receiving 554 failures for messages from e-mail addresses which I have now added to the white list in my inbound policy in SaaS.
If you continue to see messages rejected with a 554 Denied error after adding the sender to your allow list, please contact support and provide the message details (To/From/Date/Subject) so we can research the issue further. Also, we are happy to further research any false positive message that is less than 7 days old, even those that you have previously submitted to email@example.com.
System Support Specialist
McAfee SaaS Email and Web Protection Technical Support
System Support Specialist
SaaS Email and Web Security
McAfee.Part of Intel Security.
We are have a very simular problem were all emails being sent to mxlogic customers are being rejected with 554 Denied messages coming back to the sender. We had to change the IP address of our Exchange server and it appears that the reputation of the sending IP address is in question based on the information I'm finding on the Threat Center website. There appears to be no reason for this other than McAfee hasn't seen our new IP address before and is therefore dening us. Our previous IP address worked just fine but there is no going back. I've submitted requests to have this issue addressed from the Threat Feedback web page but so far it shows my IP address as High Risk for email. It does not provide a reason it's just high risk. We've has at least 50 messages rejected today.
I received the message below from SaaS_falsepositives@mcafeesubmissions.com a little while ago. Based on the response below all I have to do is contact all the people we have attempted to send emails to today and have them white list us and our problem will be solved. Why didn't I think of that?
Seriously, how do you fix this issue when the McAfee Threat Center has maked your mail server IP address as high risk for email? Submitting two requests to have it removed (last night and again this morning) has not helped as it still shows high risk.
Thank you for your submission to McAfee.
Messaging Security is currently experiencing longer than normal processing times for our Global Threat Intelligence updates. In the interim, please consider adding the sender to your allow list to ensure email delivery in the near future. We are working diligently to resolve this issue and apologize for the inconvenience.
I don't know for sure but I do know the internet service provider fairly well and believe they make very attempt to prevent such behavior.
I spoke with McAfee this morning about this. Below is the email they send me after the phone call.
Good morning again,
Thank you for taking the time to speak with me. I can appreciate your frustration, and assure you that we are working to resolve both the greater issue and yours as quickly as we can.
As we discussed, due to an issue in our Global Threat Intelligence systems, we are unable to update the IP reputation of your sending IP. It has been submitted, so is in a list of IP's that will be reviewed as soon as possible when the issue is resolved.
This does unfortunately mean that until the issue is fixed, the only method for delivery of your emails is for the recipient that is using the McAfee SaaS service to add your sender or domain to an allow list.
Thank you again for your patience.
It would be nice if McAfee put this information on their Service Alerts, as it currently says There are no service impacting events at this time.
As for the historical use of the IP, when it comes to use with email, that is different when the IP reputation is from a website.
Make sure the IP is not listed in any RBL lists, use a SPF record and make sure your IP has reverse DNS (rDNS) set up and not just from the provider. rDNS should have your mail server hostname listed. Notwithstanding the IP's reputation, by not protecting your IP using the best practices of SPF and rDNS use, you can still be blocked not only from McAfee but from any mail server.
I've been using MXToolbox.com to work through these issues to make sure everything is correct. I've alway's maintained reverse lookup on our mail servers. Reverse lookup on the new IP address for this mail server were in place a week ahead of the change.
We were not maintaining SPF records prior to this but took the suggestions by MXToolbox.com and others and they are now in place. I used another source to check these records and they should now be correct.
I do not see where our IP address has been blacklisted. I'm using MXToolBox.com to check this.
Thank you for contacting McAfee Messaging Security.
The Threat Center webpage is currently experiencing issues and does not accurately reflect the current reputation returned by McAfee Global Threat Intelligence servers. This is a known issue and is on the product roadmap to be addressed.
We apologize for this inconvenience.