timeout while talking to the remote server

Use this forum if you have installed hMailServer and want to ask a question related to a production release of hMailServer. Before posting, please read the troubleshooting guide. A large part of all reported issues are already described in detail here.
Post Reply
mikew
New user
New user
Posts: 13
Joined: 2007-05-06 11:43

timeout while talking to the remote server

Post by mikew » 2009-03-05 20:03

Hi,

I've got a strange behavior when relaying to my provider's SMTP server with hMailserver 5.0-B236. I never had (or at least did not realize for over 2 years) this issue with the previously installed 4.4 versions.

I have thin upstream (~128 kBit/s) and when I try to send large mails (12 MBytes in one example) hMailserver thinks the delivery failed due to a timeout. However the recipient received the mail correctly (checksums of attachment verified).

This also happens with much larger mails. So the 12 MBytes example seems not just to be a "border case".

Hence, hMailserver tries to send 5 times, as configured in its SMTP delivery settings. The receiver ends up with 5 complete mails. And the sender gets an error message with
"Remote server replied: There was a timeout while talking to the remote server."

I suspect that with version 5 a bug has been created in the detection of timeout conditions. Could it be that hMail just marks any SMTP client connections lasting longer than, let's say, 10 minutes as timed out even if the remote server did not close the connection?!

Of course I can provide logs if that is helpful. Just tell me which ones to activate. The server is running on Win XP Pro.
Last edited by mikew on 2009-03-06 11:48, edited 1 time in total.

mikew
New user
New user
Posts: 13
Joined: 2007-05-06 11:43

Re: timeout while talking to the remote server

Post by mikew » 2009-03-06 10:53

I had a short look at the publicly available source code for Version 4.4.

If I understand it correctly, hMailServer sets a fixed timeout of 10 minutes for "SMTPClientConnection" (where hMail talks to another SMTP server) the same way as it does for its server connections.

When SMTP data is sent to the provider server it could well be (I did not walk to deeply into the forced/optional buffer flushes), that only one single Socket::_Send() is called, which resets the timeout. Therefore, the timeout is never reset again for the entire transmission of the data.

After this 10 minutes the task checking the timeout conditions of all open sockets will find this SMTP sending socket and "terminate" it softly. That is, the socket will finish its transmission (even with a nice "QUIT") and will however be treated as failed.

That would perfectly explain the phenomenon from my opening post. Martin, am I right?

I hope no reader got lost in the programming jungle above ;-)

--

Possible Solution:

In my opinion, it does not make sense to set a 10 minute timeout on connections to other servers. The remote server should be the only instance enforcing a timeout. I'd propose to set the timeout value for this kind of connections "yery large" (hours, even days?) or even provide a configuration value for this.

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: timeout while talking to the remote server

Post by ^DooM^ » 2009-03-06 12:30

The problem with that is if you only have three delivery threads (default) running and a user sends out 10 large emails to a company and for whatever reason the receiving server dies those three threads will be locked for a long time thus rendering your mailserver useless until it hits the hard limit set. How would you propose to get around that situation assuming that the user could not increase delivery threads due to restricted CPU and network usage on a shared server?
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

mikew
New user
New user
Posts: 13
Joined: 2007-05-06 11:43

Re: timeout while talking to the remote server

Post by mikew » 2009-03-06 13:12

^DooM^ wrote:The problem with that is if you only have three delivery threads (default) running and a user sends out 10 large emails to a company and for whatever reason the receiving server dies those three threads will be locked for a long time thus rendering your mailserver useless until it hits the hard limit set.
Wouldn't that raise a TCP socket error!?
How would you propose to get around that situation assuming that the user could not increase delivery threads due to restricted CPU and network usage on a shared server?
Because of the socket errors I doubt that the behaviour you described would be observable. We could try this: Let two hMails play server and client and kill the server. If you are right, the client should not release the delivery threads unless it hits the 10 minute timeout.

Since Martin did not comment yet, I am still convinced that the "timeout" (only hMail assumes a timeout; the remote server is quite happy so far) comes from triggering the activity counter only once before submitting large buffers to the underlying sockets.

Even if you were right, a fixed timeout can still only present a compromise for all users. One size does not fit all. What's even worse: The observed behavior leads to a flooding of recipients with large mails (including all bad consequences: bandwith consumption, recipient mail loss due to size limits, etc.). I tend to prefer your theoretical unavailibility (all delivery threads blocked) in this case... :?

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: timeout while talking to the remote server

Post by martin » 2009-03-06 19:01

> Since Martin did not comment yet, I am still convinced

I'm assuming that was a joke.

Apart from that, I believe you maybe correct. I've reported it here:
http://www.hmailserver.com/devnet/?page ... ssueid=175

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: timeout while talking to the remote server

Post by martin » 2009-03-06 19:30

I've fixed this for v5.1.

Post Reply