Thursday, August 30, 2012 8:31 PM
We are a hosted email provider. It appears any messages from any of the domains we host are marked as spam by Forefront when sent to users on Office 365.
It is from multiple users with multiple domains on our end, to users on several different domains on the Office 365 end.
We are not listed on any black lists that we are aware of. I am sure it is some problem with our server configuration, since the action is so broad.
I am looking at the headers of on of our messages received by an Office 365 user and marked as junk. I can see the X-SpamScore, x-FOSE-spam, and X_Forefront_Antispam-Report. While information in these headers makes it clear it is identified as spam, I am unable to tell why. Is there any way I can determine from these headers WHY Forefront is marking it as junk?
If it is a global issue with our servers, I would really like to resolve it on our end. I am happy to share header details privately if it would help.
Monday, September 03, 2012 7:42 AMModerator
Thank you for the post.
You may analyze the FSEAgentLog to see why these messages are blocked. If you ensure these messages are not spam, this could will be a case of false positives. You should report this to Cloudmark itself as documented on this KB: http://support.microsoft.com/kb/924951/en-us.
Nick Gu - MSFT
- Marked As Answer by Nick Gu - MSFTMicrosoft Contingent Staff, Moderator Friday, September 07, 2012 3:18 AM
Thursday, September 20, 2012 1:31 PM
"You may analyze the FSEAgentLog to see why these messages are blocked" - I'm sorry, but this is not information sufficient. In fact, the only info on the log tells that it was blocked, about the same amount of detail as the mail log itself (except here you can see the other transactions).
What I'm also finding (have asked separately) is that the cloudmark is reporting almost everyone that has an email signature or company disclaimer in some few cases, as spam. If you remove signature, and signature only then it is fine. When you then follow the KB to submit the request, no confirmation comes back and the issue continues.
We really need more information in the log than is currently provided, or at the very least move this message to the spam mailbox defined already so that we can submit it for analysis. It's usually impossible to get the original email that causes the block because the mere action of sending blocks the message altoghether - you have to use a third party email like gmail, which works perfectly I might add. Or even add as an incident for further analysis??