One of the things we have been doing as a courtesy for quite some time is tracking outbound delivery problems. If you have an issue delivering to a particular recipient naturally the first step to look at is your message tracking center. But if you see the successful handoff to outbound.exchangedefender.com your line of visibility ends there. So you open up a support request and we look into it.

What happens 99% of the time is that the recipients server (or content protection network) uses a process called greylisting. While this is a great way to combat SPAM, it is a horrible practice to be used in business that depends on a timely delivery of email. Here is how the process works in the nutshell and the cons and pros.

Before accepting an email the server checks the IP address of the remote SMTP server and looks inside its trusted database. If the IP address is not in the database the message is temporarily defered (not accepted) for a configurable amount of time, generally 15 minutes. Properly designed SMTP servers will accept this error code and retry on a regular schedule until the message is accepted.

There are two benefits to this implementation: One, it establishes whether or not the remote server is a spambot or an SMTP server. Spambot will not try to deliver again because it is just slamming port 25 and dumping data. SMTP server will retry. Likewise, by not accepting mail right away it allows the message checksums to be reported to DCC (distributed checksum clearing houses, networks that track the identical messages seen over and over again) and it becomes more likely that the server will correct identify the message as SPAM if these are bulk messages. The lead time of 10–15 minutes makes that possible.

Pro: Less SPAM, local trust database, only accepting mail from legitimate SMTP servers.

Con: Long delays in mail delivery, if misconfigured, mail never gets to the target server.

ExchangeDefender does not implement greylisting nor do we intend to, but we are seeing a rise in the amount of hosts that are trying to combat SPAM using this mechanism. So if you are hearing complaints from users that seem to have a hard time reaching the specific recipient over and over, telnet to the remote port 25 and see if you get the 45x error code with a reques to try again later.

Hope this helps your troubleshooting, though, knock on wood, the rate of bugs and issues being tracked for ExchangeDefender has nearly disappeared.