Thank you!

Stefan. 

Hi everybody,

I have the  problem that I get timeout errors when sending messages to a counterparty server. The other server's admin tells me the problem must lie with my server (since the counterparty is the local Technical University, I tend to put some weight on this guy's opinion). I give an example below. In this example, the mail went through eventually. My problem is that this is not always the case. Okay, let me give you some details on my configuration. I actually use Exchange 2003 as my mailserver and use Mercury only as a smarthost to actually send the messages. When I send a message to a distribution group in Exchange where some of the recipients are contacts forwarding to the tugraz.at domain, the mails don't go through. If on the other hand I send a message to the tugraz.at-address directly, or I send it to the Exchange contact directly, they do get through...

I'm at the end of my wisdom by now and hope you guys can help me out!

Cheers,
Stefan.

Example:

--- 

T 20100129 080928 4b628888 Begin processing job MO000002 from myuser@mydomain.com
W 20100129 080930 4b628888 Error connecting to primary server '129.27.254.25'.
T 20100129 080937 4b628888 Established ESMTP connection to 129.27.124.69
T 20100129 080937 4b628888 MAIL FROM:<myuser@mydomain.com> SIZE=4178
T 20100129 080937 4b628888 250 2.1.0 <myuser@mydomain.com>... Sender ok
T 20100129 080937 4b628888 RCPT TO:<destinationuser@tugraz.at>
T 20100129 080937 4b628888 250 2.1.5 <destinationuser@tugraz.at>... Recipient ok
T 20100129 080943 4b628888 Connection closed normally.
T 20100129 080943 4b628888 Job MO000002 processing complete.

---

In the session log I get the following:

---

08:09:28.609: --- Fri Jan 29 08:09:28 2010 ---
08:09:28.609: Connect to '129.27.254.25', timeout 60.
08:09:30.609: 15: Peer connect failure
08:09:30.609: --- Fri Jan 29 08:09:30 2010 ---
08:09:30.609: Connect to '129.27.124.69', timeout 60.
08:09:37.687: >> 220 mboxprod.tugraz.at ESMTP server ready at Fri, 29 Jan 2010 08:09:33 +0100 (CET)<cr><lf>
08:09:37.687: << EHLO mail.mydomain.com<cr><lf>
08:09:37.765: >> 250-mboxprod.tugraz.at Hello mail.mydomain.com [myip], pleased to meet you<cr><lf>
08:09:37.765: >> 250-ENHANCEDSTATUSCODES<cr><lf>
08:09:37.765: >> 250-PIPELINING<cr><lf>
08:09:37.765: >> 250-8BITMIME<cr><lf>
08:09:37.765: >> 250-SIZE 20971520<cr><lf>
08:09:37.765: >> 250-ETRN<cr><lf>
08:09:37.765: >> 250-DELIVERBY<cr><lf>
08:09:37.765: >> 250 HELP<cr><lf>
08:09:37.765: << MAIL FROM:<myuser@mydomain.com> SIZE=4178<cr><lf>
08:09:37.843: >> 250 2.1.0 <destinationuser@tugraz.at>... Sender ok<cr><lf>
08:09:37.843: << RCPT TO:<destinationuser@tugraz.at><cr><lf>
08:09:37.062: >> 250 2.1.5 <destinationuser@tugraz.at>... Recipient ok<cr><lf>
08:09:37.062: << DATA<cr><lf>

--- 

An MX-lookup tells me:

--- 

 Z:\>nslookup

Standardserver:  myserver.local
Address:  192.168.1.1

> set type=mx
> tugraz.at

Server:  myserver.local
Address:  192.168.1.1

Nicht-autorisierende Antwort:
tugraz.at       MX preference = 20, mail exchanger = mail.tugraz.at
tugraz.at       MX preference = 0, mail exchanger = mx0.tugraz.at

mail.tugraz.at  internet address = 129.27.124.69
mx0.tugraz.at   internet address = 129.27.254.25

---

The connection to the primary mail handler for tugraz.at immediately fails. A connection is made to the secondary mail handler, which completes normally. Why the connection to mx0.tugraz.at failed is of course not possible to say, could be some temporary problem at their end.

However, if you at times experience timeout problems, you should probably increase the timeout value for MercuryE. Try setting it to 300 seconds instead of 60.

/Rolf

Hi Rolf,

Unfortunately, the problem is not intermittent or temporary but constant (since weeks). Furthermore - and this I find puzzling - when I watch the Mercury window while sending such a message, the connection fails immediately. That is, Mercury doesn't try for 60 seconds (I also tried 300) but gives up on the attempt immediately. Any idea why this might be?

Cheers,
Stefan. 

As I said there is no way of knowing why they immediately close down the connection. It could be that they have blacklisted your IP address, that their server has a hardware problem, that there are way too many connections to their server or something like that. Networking wise you have reached their server, but instead of starting a SMTP session the connection is immediately closed down at their end. As this is a technical university you are connecting to there is a good chance that there is some competent person around that could examine their log files and find out the reason for the problem.

/Rolf 

The interesting thing is that this only happens when I send to a whole mailing list, that is, when Mercury has to send out some 20 mails in one go. When I send mails individually, it works fine...

Okay, I think I've tracked down part of the problem - but I'm still looking for a solution! 

The university I'm trying to send mail to has addresses ending on @tugraz.at and addresses ending on @sbox.tugraz.at. The MX records look as follows:

---
Z:\>nslookup
...
> set type=mx
> tugraz.at
...
tugraz.at       MX preference = 20, mail exchanger = mail.tugraz.at
tugraz.at       MX preference = 0, mail exchanger = mx0.tugraz.at
mail.tugraz.at  internet address = 129.27.124.69
mx0.tugraz.at   internet address = 129.27.254.25

> sbox.tugraz.at
...
sbox.tugraz.at  MX preference = 0, mail exchanger = mx0.tugraz.at
sbox.tugraz.at  MX preference = 20, mail exchanger = sbox.tugraz.at
mx0.tugraz.at   internet address = 129.27.254.25
sbox.tugraz.at  internet address = 129.27.124.68
--- 

Now the problem is the following - if I send a message to one tugraz.at-address, everything works fine. In the log I find that - for whatever reason - the address 129.27.254.25 could not be contacted and that Mercury falls back to the alternate address, which works fine. However, when I send a message to a group of addresses which contain both @sbox.tugraz.at *and* @tugraz.at-addresses, this doesn't work, because when Mercury fails to connect to 129.27.254.25 it sends all three messages to 129.27.124.68, which is the alternate MX for sbox.tugraz.at, but *not* for tugraz.at.

Is there any way to solve this problem?

Best regards,
Stefan. 

I've referred this to the beta tester list for comments.

/Rolf