As mentioned previously, we are starting to tighten up the network backend before the UI overhaul of ExchangeDefender 4.0 takes place. In preparing for it we are trying to adjust our network to help reduce load as well as improve the quality of service and transparency.
First the problem: Message sent to user XYZ was not received, can you please check?
There are three possible outcomes to the question above:
1. Almost always the message was delivered properly but the remote users server either discarded it as SPAM or the user outright deleted it and just did not want to fess up to it. We have invested thousands of man hours with our partners where the message from customer A went to customer B and can be backed up with transaction logs of the sending server, ExchangeDefender and recipients mail server. It made it to the mailbox. Then it disappeared. That we can’t do much about but with LiveArchive we have made it possible for our own customers to retrieve those mysteriously undeliverable items.
2. The message was delivered but discarded at some point in the process (ExchangeDefender, third party mailer, broken DNS, etc)
3. Something that we aim to fix: Message was delivered to ExchangeDefender but did not get delivered to the remote server because the remote server uses greylisting, callbacks, long delays, internal content blacklists, guy in the basement writing SpamAssassin rules.
The Solution: Less time in the queue, faster alerts to the user that there is a problem.
Our current settings will retry to deliver the outgoing message for up to five days. Error reports are sent within 24 hours. That is clearly too long as the users complain of issues within hours of sending the email. We will be generating errors sooner than later to help the IT staff and IT Solution Provider explain to the customer that the issue is on the remote recipients server, not on their own or ExchangeDefender which will help with the endless troubleshooting requests over the proven infrastructure just to find out that the recipients server has a poorly configured mail server.
This change in policy will only affect outbound mail, inbound mail will remain the same.
Going forward we will be issuing non-delivery alerts within 3 hours. We will return the message to the sender if the message is not delivered within 24 hours. Based upon the advice of our IT Solution partners and our internal testing, we have concluded that this is an adequate amount of time to attempt to deliver the message and if the delivery fails this gives the sender an option of contacting the recipient through other means until their mail problems have been solved.
ExchangeDefender 4.0 will feature full access to the ExchangeDefender transaction logs both inbound and outbound but in the meantime we felt it was important to introduce this change due to the growing number of hosts that are without protection and just unable to properly handle the amount of inbound mail sent to them. Each undeliverable and unreported issue with the remote server unfortunately increases the cost of support and reduces the satisfaction with the mail delivery because users tend to start blaming their own IT staff first. We hope these errors help the users see where the issue is sooner than later so they can continue to communicate with the remote party through other means.