The forward_dns function now checks that valid_hostname is enabled and that the valid_hostname test passed.

As far as the DNS timeout, I think we're thinking about it in entirely different ways. You're considering it as a connection filter (DENY[SOFT]) whereas I'm only interested in forward_dns as a heuristics input. I wish to collect that heuristic in a what that minimally impacts legit users. Especially Windows PCs behind a NAT on a dynamic IP that will eventually SMTP-AUTH. If they "EHLO MY-PC.LOCAL" or "MY-PC.provider.net" and the DNS doesn't work out, that's okay. Putting in a 30 second timeout there for a roaming user (esp. mobile) that happens to be on a network with a stinky DNS is going to be noticeably punitive for very little benefit.

Waiting greater than 5 seconds will result in a small increase in HELO host queries that resolve. If that's valuable to you, bump up the timeout. I don't see that being valuable for most cases.

I have added a DENYSOFT that will be returned if the lookup times out and reject=true.