Exchange greylisting and I can’t send email to these domains

I was getting calls from one account running Exchange 2003 that at random times that they could not send email to one domain. I looked at logs and I see nothing helpful. My account found ways around the issue, maybe faxing or alternate email accounts. One day I found this article by Michael which solved that account’s problem. At least I have not heard anyone complain in a while. The deadly greylisting where the mail server does not answer a sending email server’s command immediately. The idea is to prevent spammers from doing their evil. http://theessentialexchange.com/blogs/michael/archive/2007/11/16/exchange-2003-sp2-and-greylisting.aspx glitchretry is what I modified. http://technet.microsoft.com/en-us/library/aa998772(EXCHG.65).aspx

I got a call from another account running Exchange 2007 that they cannot send and the guy who administers the recipient server says the server is perfect. So I open up Microsoft’s article on telnet to Exchange.  http://support.microsoft.com/kb/153119

I type the commands and the rcpt to:validuser@domain.com does not respond. I bang the enter key again and look off. I get an invalid command when I get back to looking at my telnet screen. I start over with the telnet stuff but this time I use the other enter key. It takes 2 minutes to get a response to rcpt to”validuser@domain.com. Well that refreshes my mind so I am off to find Michael’s article which I did not bookmark. I then searched for glitchretry Exchange 2007 and got this article. http://technet.microsoft.com/en-us/library/aa998043(EXCHG.80).aspx

Hopefully this gets things working. Talking with my account contact she says that a lot of folks at different organizations are complaining that they cannot send to the trouble company. I suspect some Exchange administrator was being clever doing greylisting but did not tell his valid senders how to fix what he “broke.”

 Do not trust my copy and paste. It goofed up but here is the section I was working with.

Configuring the Queue Glitch Retry Interval

The queue glitch retry interval specifies the interval between each connection attempt that is specified by the QueueGlitchRetryCount parameter. The default queue glitch retry interval is 1 minute. Typically, you don’t have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections.

  1. Open the following file by using Notepad: C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config.

  2. Modify the following line in the <appSettings> section:

    <add key=”QueueGlitchRetryInterval” value=”<hh:mm:ss>” />

    
    

    For example, to change the queue glitch retry count to 30 seconds, modify the QueueGlitchRetryCount parameter as follows:

    <add key=”QueueGlitchRetryInterval” value=”00:00:30″ />

    
    

  3. Save and close the EdgeTransport.exe.config file.

  4. Restart the Microsoft Exchange Transport service.

To specify an age value, enter the value as a time span, as follows: hh:mm:ss, where h = hours, m = minutes, and s = seconds.

 

So that stuff did not really help. I looked at the Exchange logs. Specifically I went in to Exchange Management Console and under Server Configuration/Hub Transport at the top right box  I right clicked on my server name and properties. In log settings I checked Enable Connectivity logging noting where the log is. A bunch of oks and I restarted the Microsoft Exchange Transport. I looked at the log and the problem domain was showing dns errors.

I did an ipconfig/flushdns which did nothing. I looked up the domain using www.mxtoolbox.com I pinged the server listed. Quick solution was I added www.opendns.com server numbers of 208.67.220.220 and 208.67.222.222 in the DNS management console. right click server name and properties. There is some issue with edns probes that I need to figure out but I need to get some hardware delivered to an account. Oh, setting the server to use opendns servers got that mail flowing.

Leave a Reply

Your email address will not be published. Required fields are marked *