One of the most frustrating calls you can ever receive from the user is the one that begins and ends with the words: “We are constantly, constantly not getting our mail” – and its your task to prove to the user that you are not at fault (by locating the message). Over 99.9996% of the time the messages end up getting lost through server or client deployed antispam software that should be turned off in the first place. But let’s assume you checked that. Let’s assume you disabled Outlook Junk Filters, Let’s assume there is no IMF on the server. Let’s assume there is no SMTP inspection enabled on the firewall. Let’s assume you have no “security” appliances in your way.

What then?

With ExchangeDefender v3.1 we are giving you full access to our logs, down to the SQL level (more on this to follow). Let’s assume that a user tells you they never received a piece of email, you’re sure everything on their end is working perfectly.. how do we find out if ExchangeDefender messed up? Pretty easy, let’s see where the message went.

Login as the Service Provider

Login with your service provider account to our portal at https://admin.exchangedefender.com

Head over to the new tab, Mail Log.

Select the domain name you wish to run the report on. Search Criteria window will drop down and allow you to put in some basic information (such as the senders email address, subject). Everything except the “To:” field is optional, if you leave both the subject and the from address empty you will see a report of all mail received for that user. All searches are also partial and case insensitive, so you can try to narrow it down if the user isn’t sure of what they were expecting.

Hit find and you will be presented with a list of messages that matched the search criteria. These messages include SPAM, SureSPAM, clean messages, infected messages – basically you see everything we processed.

If you have a question about what may have happened with the particular message you can just click on the Details link (hold CTRL down to open in a new window if you have a few messages) and you will get the following screen with message details:

It is important to note a few things here. First, you are seeing the message details because we accepted and processed the message. If we didn’t, there would be nothing to show. If you encounter that situation, find out who the sender is and open up a trouble ticket. We send rejection notices (as per RFC) to all mail we do not process so if there was an error on our side the user would have received the notice.

Second, it is important to understand that this shows ALL mail processed by us – spam, clean, infected. If it is SPAM it will show a score higher than 0.00. If it is infected, it would say that as well. Also, if you see this message it means it was accepted, processed, and delivered to the user (or dispatched to the delivery queue). Anotherwords, fire up Message Tracking on their Exchange system and dig using the message identifiers noted in the Message Details screen above.

We will have SQL access layer completed by the end of next week which will allow you to see the transaction log down to the SMTP connection and remote queue id signs.

Looose e-mail in the cloud… with diamonds… (its what rings in my head when people tell me they didn’t receive their email)