Why slow SMTP connection when POP connection is fast? Is it something in Redhat?
We have an app which is trying to send mail to an SMTP server via a direct TCP connection. It's really slow. To emulate this we try connecting via telnet:
telnet 10.44.0.1 25the initial response:
Trying 10.44.0.1...is really fast but there is a 2 or 3 second delay before we get the:
220 myserver.mydomain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2653.13) readywhich allows us to do the sending. (OK. OK. real apologies that this is an MS-Exchange server but I can assure you that that isn't the fault and if you look carefully you will see version 5.5 which is a hint that we are about to migrate to a more sensible mail server from a different supplier...)
If we telnet to pop:
telnet 10.44.0.1 110the response:
Trying 10.44.0.1...is instantaneous.
Now we have multiple boxes that we can test this with. RedHat 7.3 doesn't have this problem (ie we get an instantaeous complete response on port 25) but AS2.1 to ES4 does.
We are not running identd. Our hosts entries are correct. We aren't running iptables.
We don't get this problem on Debian boxes. We don't get this problem on Windows boxes (sorry!) or Macs.
Can I know what services you have running on your redhat machines?
Another thing is are there any cronjobs?
May be the problem is with other memory hungry apps and demons.
(Just a guess though)
There are a few cronjobs running on this machine but we see the same issues regardless of whether they co-incide with cronjobs or not.
And its not memory issues because not only do we have oodles of memory available (there's 16GB on the box) and we have the same problem with a totally empty box running nothing except for RHAS2.1 in runlevel 3, no cronjobs, no special services....
Thanks for the suggestions though!
Do you have the same behaviour if you go first on pop and then on smtp?
It doesn't matter if you do POP first then SMTP or SMTP first then POP or if you just do SMTP (which is what we want to do). We ran the POP test purely because it is a service on the target mail server that was also available so that we could proove that it isn't the network that is causing the problem...
Thanks for the suggestion!
|All times are GMT -5. The time now is 11:37 PM.|