Over the last few mornings, we’d been having a problem with the SMTP Server Remote Queue Length. I had previously checked for an open relay, but (naturally) I became suspicious. Once again I checked for an open relay using spamhelp.org and still no open relay. To be on the safe side, I attempted a remote test using telnet as described in KB324958. Nope.

So here is the problem diagnosis and solution…

Symptoms
  • SMTP Server Remote Queue Length error in Server Performance Report.
  • ESM > Servers > My server > Queues shows many Small Business SMTP Connectors with typically spam likes names. Right click on them and finding messages shows one or more emails from postmaster@yourdomain.com.

It could be that this is a non-delivery report (NDR) attack (KB886208), or just that you’re receiving a lot of spam to addresses which are not recognised in your company.

Solution

A good description to fix this problem is given in KB886208. Basically, you want to pass the problem of creating delivery reports on from your receiving server to the spammer’s sending server. Full steps are given (this time quite clearly) in the KB article. By default, Exchange accepts the email, looks up an address in Active Directory and then sends a non-delivery report if that address is not found.

This approach prevents Exchange from accepting the mail in the first place, but makes the system more vulnerable from attacks intended on finding legitimate email addresses on your system. Therefore, it’s probably best to enable SMTP tar-pitting, as described in KB842851. Tar-pitting introduces a delay in the SMTP response to invalid requests and vastly increases the time necessary to gain access to valid email addresses. Unfortunately, it may also slow legitimate email.

Advertisements