[quote user="Rolf Lindby"]

Maybe some strange IPv4 / IPv6 issue? Again, would you consider trying v4.80 and see if that makes a difference? If so I can provide a download link for the current beta.

[/quote]

Yes, I'm willing to try the beta, depending on how stable it is - this is my email link to the world after all.

I'm using Mercury V4.74 and its MercuryE SMTP client to send mail out. I've been doing this for many years with no problems. Lately I've been seeing intermittent (once per week or so) instances of outbound email that are stuck in the outbound queue. The MercuryE log shows the single line

Begin processing job MO000078 from xxxx@mydomain.com

Nothing else is logged for this job. I turned session logging ON and waited for another "stuck email" event, but the log file for the stuck session was empty. In addition, tcpview shows that whenever an email is stuck, Mercury has a UDP socket open, which I have never seen before and indicates to me a DNS issue. The DNS timeout for MercuryE is 90 seconds, with 10 DNS retries so if DNS were not responding I would expect something to happen after about 15 minutes, but the mail remains in the queue indefinitely. While this email is stuck, processing of other outbound emails continues normally. If I restart Mercury, the stuck email is delivered within seconds.

I haven't seen something like that happen except maybe if there has been an issue with some antivirus software. Did you specify a name server in MercuryE configuration, or does Mercury use the default name servers from Windows?

I did think some anti-virus or firewall could be a problem, so I temporarily disabled them both and still saw the same problem. I did not give Mercury separate DNS servers, it uses the ones provided by Windows. These servers themselves are most likely not the issue as they are run by a solid organization. Furthermore, yesterday an email destined to gmail.com became stuck, and during the four hours it was stuck, other outbound emails to gmail.com were delivered with no problem.

Even if the DNS server were not replying, since this is UDP, there is no connection established. Therefore Mercury should just wait for a reply and eventually time out if none is received. Yet is seems to keep on waiting indefinitely.

If this indeed is some rare low-level networking issue affecting DNS request on UDP we could perhaps start by checking if we get the same behavior with v4.80 of Mercury. A lot of networking components have been replaced in v.4.80 as part of the move from old Borland C to current MS Visual C.

Some more background might be useful as well. What version of Windows is used on the server? Have any OS patches been applied recently? Any changes in the network, like switches or routers that have been replaced or updated?  

[quote user="subelman"]I did not give Mercury separate DNS servers, it uses the ones provided by Windows. These servers themselves are most likely not the issue as they are run by a solid organization.[/quote]

I have heard that some Mercury users experience these types of issues when relying on Windows DNS services.  Can you enter the same DNS servers into MercuryE and see if that makes any difference?

It seems non-intuitive that there would be a difference, but others have reported that it solved their delivery problems.

[quote]Even if the DNS server were not replying, since this is UDP, there is no connection established. Therefore Mercury should just wait for a reply and eventually time out if none is received. Yet is seems to keep on waiting indefinitely.[/quote]

Agreed :(

OS is Windows XP SP3.  No patches have been applied since before the issue started showing up, and no changes in the network. Last week all routers and switches were restarted (we had a power failure) and yesterday we had another email hang.

I just entered the DNS servers in the MercuryE configuration. Now we'll have to wait and see, since my problem is intermittent.

I wonder if the reason for the non-intuitive behavior you report could be that when you don't specify DNS servers then MercuryE uses the Windows Sockets API for DNS resolution and if you do specify DNS servers then MercuryE just uses UDP and a separate implementation of DNS lookups.  This seems plausible because the Windows API only supports timeouts on DNS lookups in special cases,and MercuryE has a configuration parameter for timeouts on DNS lookups.

[quote user="Rolf Lindby"]

If this indeed is some rare low-level networking issue affecting DNS request on UDP we could perhaps start by checking if we get the same behavior with v4.80 of Mercury. A lot of networking components have been replaced in v.4.80 as part of the move from old Borland C to current MS Visual C.

Some more background might be useful as well. What version of Windows is used on the server? Have any OS patches been applied recently? Any changes in the network, like switches or routers that have been replaced or updated?  

[/quote]

I checked logs going back to January 2012, and the problem has been there all along - I just never noticed. This means that the problem has persisted across:

1) two different ISPs with completely different technologies (DSL vs direct fiber optic connection)

2) Changes in the DNS servers, imposed by the different ISPs

3) Two different geographical locations - we moved in February 2013

4) Three different routers - one upgrade to a faster WiFi and a replacement when that second router failed

5) Two different machines - I upgraded the hardware in June 2013. Both computers use Windows XP SP3.

6) Multiple OS patches as Microsoft pushed them out.

7) One upgrade from the previous version of Mercury to the current one.

I have also reconfigured MercuryE to explicitly use the DNS servers rather than getting them from the OS. The problem has happened in both configurations.

I also noticed that most (but not all) of the emails that get stuck are for recipients @gmail.com which is not an obscure domain that would have trouble getting resolved. Our server is very low volume, the number of outbound emails is 20-30 per day. Inbound is about 200-300 per day (mostly spam) so there is no bandwidth issue.

Maybe some strange IPv4 / IPv6 issue? Again, would you consider trying v4.80 and see if that makes a difference? If so I can provide a download link for the current beta.